Lesson: What happens in three seconds: the path your prompt takes

Friday morning. Aisha is at her desk at home, the AI tool open in a browser tab, the cursor blinking in the chat box. The sticky note she put on her laptop on Wednesday is still there: check what’s in the tab before you paste. She has her seed paragraph from yesterday’s reading folded in her notebook. She knows what she is protecting and from whom.

There is one thing the seed paragraph did not give her. Before she types anything real into the box, she wants to know where the text is actually going. Not in the abstract. In the concrete. From the keystroke to the reply, what happens?

By the end of this lesson you will be able to trace that path in your own words. It is a short path. It takes about three seconds. Once you have walked it once, you will have a mental picture you can apply to any AI tool, on any day, before any paste.

What “three seconds” means

When Aisha clicks Send, three things will happen in roughly that order: the text leaves her computer, the model produces a reply, and the reply comes back. The whole round trip usually lands in two to four seconds for a short message. Longer messages, or longer replies, take longer. The shape of the trip is the same; only the time scales with the length.

We are going to slow that round trip down. Not because three seconds is dangerous. Because three seconds passes too quickly to think about, and what passes too quickly to think about gets treated as if it does not happen at all. Aisha can act differently if she can see the path. So can you.

The chain, in plain English

Here is the path a short message takes from Aisha’s keyboard to the model and back. Read it once at full speed; we will then slow it down step by step.

Her fingers press keys. The text appears in the chat box on her screen.
She clicks Send. The browser packages the message and sends it across the network.
The message reaches the AI company’s front door, a piece of infrastructure called a CDN.
From the front door, the message is passed to the model service inside the AI company.
The model reads the message and starts generating a reply.
The reply streams back through the same chain, in reverse.
The reply appears in Aisha’s chat box, usually one piece at a time.

Seven steps. Three seconds. We will walk each one.

Step 1: Keys to chat box

The most ordinary part of the path. Aisha’s fingers press keys on her laptop’s keyboard. The operating system sends each keystroke to whatever window has focus, which in her case is the browser tab holding the AI tool. The browser shows each character in the chat box as she types.

Nothing has left her computer yet. The text is in her browser, which is a program running on her laptop. If she closed the tab right now without clicking Send, the text would be gone and no one outside her laptop would know it had ever existed.

What this means for you. The moment before you click Send is the last moment when only your machine knows what you typed. Until you click, you are still inside your own boundary. That is why the sticky-note rule from lesson 1.2 (check what’s in the tab before you paste) is so cheap and so useful. Reading the tab is a free check. Clicking Send is the act that ends “only my computer knows.”

Step 2: From your browser onto the network

When Aisha clicks Send, her browser does something invisible to her. It takes the text, wraps it inside a network message, and hands that message to her computer’s network stack. The network stack passes it to her home wireless router. The router passes it to her internet provider. The internet provider routes it out onto the public internet.

This is the part of the trip that uses the word “network.” Networks are the chains of wires, radio links, and routing devices that move messages between computers. The path her message takes through those chains is not under her control. There are many possible routes, and the route a particular message takes depends on which links are open and which paths the routers choose at that moment.

For her message, the route does not need to be exact. What matters is that the message leaves her laptop, leaves her home, leaves her city, and arrives at the front door of the AI company that runs the tool.

What this means for you. Once your message has crossed onto the public internet, it is no longer something only the people on your network can see in transit. Modern AI tools use encryption (the kind a padlock icon next to the URL signals) so the message contents are not readable by random parties along the way. But the fact that you sent a message at that time, from that address, to that destination is observable by parts of the network that route it. The trace of who-talked-to-whom-and-when is called metadata. Encryption protects the contents; it does not erase the trace. The cheap check Aisha can run before any high-stakes paste: glance at the URL bar. Is the padlock icon present? Is the domain spelled exactly as expected, with no extra characters or lookalike letters? Two seconds, and it catches the cases where the trip itself is compromised before the destination question even matters.

Step 3: The front door (the CDN)

Most large AI tools sit behind a service called a CDN, which stands for Content Delivery Network. A CDN is a network of servers placed at many physical locations around the world. When Aisha’s browser asks for the AI tool, the CDN picks the location closest to her and routes her request through it. This is how the AI tool feels fast even though the company’s headquarters might be a thousand miles away.

The CDN is the first piece of the AI company’s infrastructure her message touches. It is the network layer the model service sits behind: its job is routing, abuse protection, and traffic management. Architecturally, the CDN is the first place inside the vendor’s perimeter where your message is decrypted and inspected. The encrypted channel that protected the message from Aisha’s laptop ends here; the trip onward to the model service runs on the vendor’s internal network.

That phrase (the first place inside the vendor’s perimeter where your message is decrypted and inspected) is the load-bearing one. It means the CDN could observe the contents. What it actually does with that ability is a policy choice, not an architectural fact. Most CDN configurations log only the wrapper around the message (the request metadata): a timestamp, the rough geographic region, the size of the message, sometimes the type of browser making the request. Logging the contents themselves is a separate decision the vendor either has made or has not; the CDN’s architectural ability to do so is independent of whether they do.

For Aisha, the practical consequence: a record of the request exists. The minimum that record contains is metadata. Whether it contains more depends on what the vendor has chosen to log. Phase 3 of this track categorizes the threats this distinction surfaces (what is retained, by whom, for how long, and to what end); Phase 4 teaches the rubric for reading a vendor’s actual commitments against the architectural floor.

What this means for you. Every system that handles plaintext is a system that could observe or store contents. The CDN is the first such system inside the vendor’s perimeter. Knowing this means: when you read a vendor’s policy and see a line about retention or logging, you can tell whether the vendor is making an architectural claim (the data cannot be retained at this layer by design) or a policy claim (we have committed not to retain it, but the layer could). The two are different protections. The next time you read a “we do not log message contents” line in a policy, read the vendor’s policy to see what is logged at this layer and for how long; the policy is the commitment, the architecture is the floor.

Step 4: Inside the AI company

From the CDN, the message is passed inward to what we will call the model service. The model service is the part of the AI company’s infrastructure that actually runs the model. Not the model itself. The model lives on specialized hardware (computers built for the math the model does). The model service is the software that takes a message, hands it to the model, watches the model produce a reply, and sends the reply back out.

Inside the model service, the message is now plaintext. Plaintext is the opposite of encrypted: it is the actual readable words. Encryption protected the message in transit between Aisha’s laptop and the CDN. Once the message is inside the model service, the company’s own systems can read it. That is not a flaw; the model needs to read the message to reply to it. It is the structural reality of working with a hosted AI tool.

What the model service does with the plaintext beyond handing it to the model is the part the company’s privacy policy describes. Different vendors handle this differently. Some store it for a fixed period and then delete. Some use it to improve the model unless the user opts out. Some keep it indefinitely. Phase 3 of this track gives Aisha a four-category vocabulary for the kinds of choices a vendor can make about her data (the categories themselves: vendor retention, training-data inclusion, breach exposure, and government access). Phase 4 then teaches the rubric for evaluating any specific vendor’s stated commitments against those categories. The shape of what is available to be stored or used is the work of this lesson: once the message is inside the model service in plaintext, the vendor’s choices about what to do with it become real choices.

What this means for you. “End-to-end encryption” is a phrase you may have heard about messaging apps like Signal. With those apps, no one between you and the person you are messaging can read your messages, including the company that runs the app. With an AI tool, that property does not hold, because the model itself is the recipient and the model needs to read your message to reply. The encryption on AI tools protects the trip from your laptop to the company. Inside the company, the message is plaintext to the systems that handle it. This is not a vendor failing; it is what a cloud-based AI tool is. Before pasting anything sensitive, Aisha can run one cheap check: scan the vendor’s privacy page for the words that distinguish architectural protections from policy protections. Words like on-device, never leaves, or cannot retain point to architecture (the system cannot do the bad thing by design). Words like we do not train on, we do not sell, or we will delete after N days are policy commitments (the system could, the vendor commits not to). Both matter; the first holds even if the vendor changes its policy later. Phase 5 of this track returns to architectural alternatives as the main topic.

Step 5: The model thinks

The model reads the message. It generates a reply. We are not going to teach how it does that here; track 5 of Clawdemy (AI Foundations) covers the mechanics in depth. What matters for Aisha right now is that the model’s reply is produced by computation on the AI company’s hardware, not on her laptop. The reply is built one piece at a time, and the company’s systems can observe the reply as it is built.

This step is also where the model’s context window matters, even though we will not formalize that idea until lesson 2.3. For now: the model can only respond to what it has been given for this particular conversation. If Aisha did not paste her seed paragraph into the chat, the model does not know her seed paragraph. If she did paste it, the model has it for this conversation. What the company does with that data after the conversation ends is the policy question. What the model can see during the conversation is the architectural question we are walking now.

What this means for you. The model is not a person. It does not “remember” you across conversations unless the vendor has built a memory feature on top of the model. What you share in one conversation is what is available to be processed in that conversation, and it is also what is available to be stored, reviewed, or used afterward according to the vendor’s policy. The mental picture to carry: the model service is a workshop. What you hand to the workshop is processed inside the workshop. What happens to it after processing depends on whose workshop it is. The concrete check Aisha can run today: open the AI tool’s settings and look for anything called Memory, Custom Instructions, Personalization, or similar. If memory is on, anything she teaches the tool once may carry forward into other conversations she did not intend to bridge. Turning it off (or learning where to clear it) is a one-time five-minute setting change that scopes future conversations to the conversation itself.

Step 6: The reply comes back

Once the model has generated a reply, the model service sends it back out. The reply travels the same chain in reverse: model service to CDN, CDN onto the public internet, across the internet to Aisha’s home, through her network to her browser, into the chat box on her screen.

A detail Aisha will notice: most modern AI tools do not wait for the entire reply to be ready before sending it back. They stream the reply, which means they send it one piece at a time as the model generates it. That is why the reply often appears word by word in the chat box rather than all at once. The streaming is a user-experience choice, not a privacy choice; the reply still travels the same path, just in small pieces instead of one large piece.

What this means for you. The trip back is the same trip forward, in reverse. The same systems that handle your message handle the reply. The reply also touches the CDN’s logging. The reply is also plaintext inside the model service. The asymmetry between “what you sent” and “what came back” is a matter of content, not of where the content traveled. The practical implication: if the model’s reply contains something you would not want logged (a generated draft email with a sensitive name, a code snippet with a private API key the model echoed back, a summary that surfaces something you typed earlier in the session), the same logging and retention apply to the reply as to your message. If a reply ever surprises you with content you would prefer not stored, do not assume the surprise stays between you and the screen.

Step 7: The reply appears

The reply lands in Aisha’s chat box. She reads it. She decides what to do next. If she sends another message, the cycle repeats. If she closes the tab, her side of the conversation ends; the company’s side of the conversation (the logs, the stored conversation, whatever else the policy describes) continues to exist according to the vendor’s terms.

Two words from one vendor’s policy, as a worked example

When Aisha reads a vendor’s privacy policy for the first time, she will encounter vocabulary the policy uses to refer to her messages and the model’s replies. Every vendor has to refer to those two things; what they call them varies.

One major AI provider, in their public privacy policy, uses the words Inputs and Outputs:

You are able to interact with our Services in a variety of formats, including but not limited to chat, coding, and agentic sessions (“Prompts” or “Inputs”), which generate responses and actions (“Outputs”) based on your Inputs.

In that vendor’s policy, Inputs are the user’s messages. Outputs are the model’s replies. When the policy says something like “we may use your Inputs and Outputs to train our models and improve our Services,” the words map directly to what just walked through this lesson: the message you sent, and the reply that came back.

Other vendors use different vocabulary for the same two things. Some say prompts and responses. Some say requests and outputs. Some say content in a single bucket that covers both. The vocabulary is not standardized across the industry. What is consistent is that every vendor’s policy refers to your messages and the model’s replies, under some name. The names are policy-local; the things they name are the same things Aisha just traced through the seven steps.

The reason to read one vendor’s vocabulary closely is that it makes the next vendor’s vocabulary easier to recognize, even when the words differ. Phase 4 of this track teaches a rubric that normalizes across vendors: read any vendor’s policy, identify what they call your messages and what they call the replies, and the rest of the policy becomes readable.

An architectural alternative, in one paragraph

The path described in this lesson is the typical shape for a consumer AI tool: you talk to the vendor’s web app, the vendor’s CDN logs the request, the vendor’s model service runs the model, the reply comes back. This is the most common shape because it is the easiest to ship and the easiest to use.

It is not the only shape. Some AI tools are built so that your computer talks directly to an AI provider over the vendor’s API. An API (short for Application Programming Interface) is the direct connection a vendor offers to developers and to apps, where one piece of software talks to another without going through the vendor’s chatbot website. In this shape there is no consumer-facing CDN or vendor middleware in between. Clawless, the desktop app this site’s sister project ships, is one example: when you send a message in Clawless, the message goes from your computer to the AI provider you chose, and the reply comes back. There is no Clawless server in between holding logs of your chat requests. Different architecture, different surfaces where data could be observed or stored. This is one architectural shape among several local-first approaches. It is not presented as a ranking of vendors.

The point is not that one architecture is good and the other is bad. The point is that the architecture decides which parties along the path see what. Phase 5 of this track returns to architecture as a privacy lever in its own right. For now, the thing to notice is that the seven-step path you just learned is a typical shape, not the only shape, and the shape a particular tool uses is something you can ask about.

Common pitfalls

Three patterns most readers fall into when they first learn the path.

Confusing the path with the policy. The path is what is structurally possible. The policy is what the vendor commits to doing. The path tells you that your plaintext message is, at the moment the model service handles it, available to the vendor’s systems. The policy tells you what the vendor promises to do or not do with that availability. The two are different layers, and reading them as the same thing leads to either misplaced trust (“the policy says they don’t train on it, so it never touches their systems”) or misplaced fear (“their systems see the plaintext, so the policy doesn’t matter”). Phase 3 will name the categories of vendor choice that sit on top of the path (vendor retention, training-data inclusion, breach exposure, government access). Phase 4 will then teach the rubric for reading any specific vendor’s policy against those categories. This lesson taught the path both phases sit on top of.

Confusing encryption with secrecy. Encryption protects messages in transit across the network. It does not erase metadata, it does not hide the message from the recipient (the model service in this case), and it does not prevent storage after receipt. The padlock icon in your browser is a real, useful protection. It is also a narrower protection than the word “encryption” sometimes suggests. Lesson 5.1 of this track will go deeper on encryption specifically.

Skipping the CDN. A common mental model is “my computer sends to the model.” The actual path almost always has at least one intermediary, and the CDN is the most common. Skipping it in your head means missing a layer that holds metadata about your interactions even when the vendor does not train on the contents. Knowing the CDN exists does not require knowing how it works. It requires knowing it is there.

What’s next

Lesson 2.2 walks the same path again, but instead of asking what happens at each step it asks who can see what at each step. The path you learned in this lesson is the scaffold. The parties along the path are the next layer of detail. By the end of 2.2 you will be able to point at any step of the chain and name what is observable there and by whom.

Aisha is going to leave the AI tool tab open, set her sticky-note timer for two minutes, and read a single page of the AI tool’s privacy policy before her first paste. That is the use of the mental picture she just built: not anxiety, not paralysis, but a small concrete next step that makes the policy readable. The path makes the policy make sense.

Three seconds passes. Now she can see the inside of those three seconds. Once you know what each part of the path can see, you can choose which tradeoffs to make and which to avoid.