Context: What Goes Into a Request

You type one sentence into a chat box and press send. The request that reaches the model carries far more than that sentence.

The previous lesson defined context as everything the model is given in one request, and the context window as the limit on its size. This lesson opens the bundle and lists what is inside. There are eight parts. You write only two of them.

Every part is turned into tokens, and the model has to read all of them before it answers. More context means more to process, which can make answers slower and more expensive. After this lesson you can list the parts of a request, say who adds each one, and explain why an agent with many tools has less room for your conversation.

An everyday picture for the whole lesson: you ask a colleague a quick question, but first you hand them a folder with the meeting notes, the email thread, and the company rules. They have to go through the whole folder before answering your one-line question.

1. An attachment becomes part of the input

In the app, an attachment looks like a separate thing: a small file icon next to your message. For the model, there is no separate channel for files. Everything is merged into one long input that the model reads from top to bottom.

What you did:

typed:
  Summarise this for Thursday.

attached:
  quarterly-notes.md

What the model received:

Summarise this for Thursday.

--- quarterly-notes.md ---
Kickoff moves to the 14th.
Budget sign-off still open.
Room B is double-booked.

The app copies the contents of the file straight into the input, usually under a label such as --- quarterly-notes.md ---, right next to your typed message. To the model there is no "file". There is only more input.

So a 20-page document you attach becomes 20 pages of tokens in the context window, the same as if you had pasted it in yourself.

One detail: text files are pasted in as text like this. Images and scanned pages are handled differently. They are turned into image tokens, not text. Either way, they end up in the same single input and take up space in the same window.

2. Your message is never the first thing the model reads

Before your words there is a block you never see. Between that block and your new message sits the whole conversation so far.

First, the part that is never shown on your screen:

[system]
Answer briefly. Do not guess at
numbers you have not been given.

[developer]
Project: billing. Tests in /spec.
Prefer the existing helper.

Then the whole conversation, all the way back:

[you]    How do refunds work?
[model]  You call the refund ...
[you]    And partial ones?
[model]  Same endpoint, with ...
[you]    <your new message>

Every request is built in the same order:

1. System instructions. Rules from the company that runs the model or app, such as "Answer briefly". This is the system prompt from the previous lesson.
2. Developer instructions. Extra rules from whoever built this particular tool, such as "Project: billing". In a coding tool, this is where project-specific guidance goes.
3. The conversation so far. Every earlier question and every earlier answer.
4. Your new message, at the very end.

The model has no memory between messages, so the app sends the whole conversation again each time. Text you sent an hour ago is text you are sending again now, and it uses tokens again. This is why long chats get slower and in the end reach the context window limit.

Without the history, the model could not answer. "And partial ones?" only makes sense to a reader who has seen the question about refunds before it.

3. An agent adds files to the context on its own

An agent is an AI system that can take actions, such as listing a folder or opening a file, instead of only chatting. Give an agent access to a folder and it pulls things into its own context without you attaching anything.

flowchart LR
    A["An agent<br/>running where<br/>your files are"] --> B["Folder ~/work/<br/>quarterly-notes.md<br/>budget-draft.csv<br/>team-roster.csv<br/>kickoff-14th.md<br/>old-deck.key<br/>invoice-0912.pdf"]
    B --> C["Added to the context<br/>all six file names<br/>plus two files opened in full"]

In this example the folder has six files, and you attached none of them. After the agent has looked around, its context holds:

every file name it saw:
  quarterly-notes.md  budget-draft.csv  team-roster.csv
  kickoff-14th.md     old-deck.key      invoice-0912.pdf

and two files, opened in full:
  "Kickoff moves to the 14th. Room B."
  "Roster: 6 names, 2 on leave."

Here is what happens technically. The model asks for an action, for example "open kickoff-14th.md". The software around the model performs the action. The result is placed into the context as text.

• When the agent lists a folder, every file name it sees is added to the context.
• When it opens a file, the whole contents of that file are added.
• All of it is turned into tokens, and all of it is sent again with every following request, like the conversation history.

An everyday picture: you ask an assistant to check the project folder. They come back carrying the one note you needed and also a pile of papers they picked up along the way.

4. Two more hidden blocks: memory and tools

The software also adds two blocks of its own to every request.

Memory. Some apps save facts about you or your work from earlier chats:

Ships go out Thursdays
Call them "the client"
Metric units, always

The model does not remember these. The app wrote them down once and puts them back into each new request. Some apps send every saved memory every time. Others pick only the memories that seem relevant to the current message. Whatever is picked goes into the context.

Tools. Tools are actions the model is allowed to take, such as search_files, read_file, and send_email. A model cannot use a tool it has not been told about. It knows a tool exists only because a written description of that tool is in the context:

name: search_files
description: Search the project for a string
             and return matching lines.

A description is a sentence, and a sentence is context. So tool descriptions use tokens too. An agent with 50 tools carries 50 descriptions in every single request, before you have asked anything.

An everyday picture: a temporary worker gets a sticky note with your preferences (memory) and a card listing which machines they may use and how (tools). Both have to be handed over at the start of every shift.

5. Eight parts, sent together in one request

None of these parts travel separately. They are packed into a single request and sent in one go.

flowchart LR
    subgraph REQ["One request"]
        direction TB
        s1["System instructions"]
        s2["Developer instructions"]
        s3["The conversation so far"]
        s4["Your message (from you)"]
        s5["The file you attached (from you)"]
        s6["Documents it retrieved"]
        s7["Memory it saved"]
        s8["Tool definitions"]
    end
    REQ --> M["The model<br/>answers from this request<br/>and from what it learned in training"]

Only two of the eight came directly from you: your message and the file you attached. The software added the other six.

"Documents it retrieved" means text the app found for you, such as web search results or company documents that match your question.

Everything the model knows about this conversation arrives in this one bundle. The model also has general knowledge from training, stored in its parameters. Those are its only two sources. If something is not in the bundle and was not learned in training, the model does not know it. It cannot look at your screen or your files on its own.

An everyday picture: you post one large envelope to an expert. They can only answer from what is inside the envelope and from what they already know.

6. The window is the room, context is what you carry into it

The two terms from these two lessons fit together like this:

• The context window is the fixed amount of space the model can read at once, measured in tokens. For example, 200,000 tokens.
• The context is everything that is put into that space: the eight parts above.

Every part takes some of the space. System instructions, tool descriptions, memories, files, and the whole conversation history all count, not only your message.

A worked case with made-up numbers shows how the space is shared:

context window:                 200,000 tokens

system instructions:              3,000
developer instructions:           1,000
tool definitions (20 tools):      6,000
saved memory:                       500
attached report:                 25,000
conversation so far:             14,000
your new message:                    50
                                -------
used:                            49,550
left for more turns and replies: 150,450

Your message is 50 tokens out of almost 50,000. Nearly all of the context is material you did not type in this turn.

When the room is full, something has to go. Older messages may be dropped or summarised, or the app may refuse more input. An analogy: the window is a moving van of a fixed size, and context is the furniture. A big sofa (a long document) leaves less room for everything else. The analogy stops at one point. Furniture is loaded once, while context is loaded again for every request.

Interview points

• Context is everything the model receives in one request, and it has eight typical parts: system instructions, developer instructions, conversation history, the user's message, attached files, retrieved documents, saved memory, and tool definitions.
• Only the message and the attachment come from the user. The application adds the rest.
• There is one input stream. A text attachment is copied into the input next to the message, usually under a label with the file name. Images become image tokens in the same input.
• The order of a request is system instructions, developer instructions, conversation history, then the new message.
• The full conversation is sent again with every request because the model keeps no memory between requests.
• An agent adds to its own context: file names from directory listings, full file contents, and the results of other tool calls. These stay in the context for later requests.
• Memory features work by writing saved facts back into the context of new requests. The model itself does not remember.
• A model can only use tools whose definitions are in the context. Each definition uses tokens, so many tools reduce the space left for everything else.
• The model answers from two sources: the context of the current request and what it learned in training.
• The context window is the space, and the context is what fills it. When the space runs out, older content is dropped or summarised, or new input is refused.

Summary

• One request holds eight kinds of content, and you write two of them.
• Attachments are merged into the same input as your message.
• Hidden instructions come first, then the whole conversation, then your new message.
• Agents fill their own context with file names, file contents, and tool results.
• Memory and tool definitions are text that the software adds to every request.
• The model knows only what is in the request and what it learned in training.
• Every part of the context takes space in the context window.