AI Tools Field GuideWhat you are actually sending
Every time you press send, the model receives one long passage: instructions you never wrote, tool definitions, your files, the conversation so far, and at the end your message. Most "why did it do that?" questions answer themselves once you can picture that bundle.
One request, as the model receives it
All of it, top to bottom, goes to the model as one text. It reads everything and continues from the end.
When the page fills, something has to give. Most tools compact: the oldest conversation and tool results are replaced by a short summary, and detail is lost on someone else's judgment of what mattered.
- System rulesThe vendor, sometimes the DepartmentRole, tone, refusals, format and safety rules. You never see them, and they are sent every turn.
- AGENT.md, GPT or project instructionsWhoever built the helper you are inThe standing instructions and persona: a form someone filled in, or a markdown file such as AGENT.md.
- USER.md and memoryYou, and the harness on your behalfWho you are, your preferences, and saved snippets from earlier chats, re-sent silently.
- Skills (.md files)The builder, or youProcedures loaded because the task matched them. The one-line description of every skill is always present; the full text joins when one is used.
- Tool definitionsThe harnessA description of every tool the model may call: search, connectors, file reading. They cost tokens whether or not a tool is used.
- Tool calls and their resultsThe model and the toolsEvery search it ran and everything the search returned, every file it opened. This is what bloats a long agent session fastest.
- Uploaded and project filesYou, or your teamThe documents you attached and the project's files, whole or as retrieved passages.
- Conversation so farYou and the modelEvery earlier turn, yours and its, resent in full on every new turn.
- Your messageYouThe only part you typed this turn.
- Room for the replyReservedThe answer has to fit in the same window, so the harness keeps space for it.
The request is a bundle, and you wrote the smallest part
When you press send, the product does not send your sentence. It assembles one long passage and asks the model to continue it. Reading from the top, that passage contains:
| Layer | Who wrote it | What it does |
|---|---|---|
| System instructions | The vendor, and sometimes the Department or your organization | Sets the model's role, tone, refusals, format rules and safety behavior. You never see it. |
| Assistant or agent instructions | Whoever built the custom GPT, Gem, agent or project you are in | Standing instructions, examples, a persona. Often a markdown file or a form someone filled in. |
| Skill and reference files | The assistant's builder, or you | Procedures and reference material loaded because the task matched them. |
| Tool definitions | The harness | A description of every tool the model may call: search, code, file reading, connectors. Each costs tokens whether used or not. |
| Uploaded and project files | You, or your team | The document you attached, and any files kept in the project. Some harnesses send whole files; some retrieve passages. |
| Memory | The harness, from earlier chats | Saved snippets about you, re-sent silently. |
| Conversation history | You and the model | Every earlier turn in this chat, both sides, sent again in full each time. |
| Your message | You | The last and usually shortest part. |
The model sees all of it as one text. It has no way to know which line came from a vendor, a builder, a document or you, except from position and wording.
That single fact explains prompt injection. It explains why an assistant "ignores" you when its builder's instruction contradicts yours. And it explains why the same model behaves differently on two platforms: the bundle is different.
Why the platform behaves differently from the raw model
People compare "ChatGPT" to "Gemini" as if they were comparing engines. Mostly they are comparing bundles.
| Difference in the bundle | What you notice |
|---|---|
| A long preamble about official correspondence | It writes more formally |
| A code tool the model can call | Arithmetic comes out right more often |
| Three reference files in a project | It answers about your command; a bare chat cannot |
| A search tool | The knowledge cutoff stops mattering for current facts |
When a tool behaves differently from the version you used at home, look at the bundle before you blame the model. The harness is the product works through that.
Every turn resends everything
The history row is the one that grows. The model is memoryless between calls, so the harness re-sends the whole conversation each turn.
| Turn | What is sent |
|---|---|
| 1 | Preamble, files, your first message |
| 2 | All of the above, the first reply, your second message |
| 20 | All of the above, turns two to nineteen, your twentieth message |
Two consequences follow. The request gets bigger and slower as the chat goes on, and the window eventually fills. And an instruction from turn two is still there on turn twenty, still being read, even if you changed your mind since.
If you corrected yourself halfway through, the model sees both versions and has to guess which wins. A fresh chat with a clean brief is often better than a long one with a history of reversals.
Tokens: a rough word count
| Token amount | Approximate words |
|---|---|
| A token | About three quarters of a word |
| 1,000 tokens | About 750 words |
Context windows are model-specific: each vendor documents the limit per model; assume tens of thousands of words, not unlimited. Tokens and the context window explains what a token is and what happens when the window fills.
Plan for the window filling
A long task grows in steps you can see coming. The starting material is the preamble and instructions. Then you attach the instruction you are rewriting. Then drafts and corrections accumulate. Then you attach a second file to compare.
Each step is reasonable; together they crowd out the space for the reply and the parts that matter. Treat a long task as stages. Keep source, decisions and open questions together, and check the next request includes what that stage needs, not superseded drafts.
Before and after a shorter brief
When the window fills, the harness has to drop something. Most products summarize the older turns into a short brief and keep the recent ones. That is compaction, and it is lossy.
The brief keeps what the summarizer thought mattered, which is not always what you thought mattered. The correction from turn four may survive as "user prefers formal tone," or not at all. You can do the same deliberately and better: write the brief yourself.
| Keep in your brief | Check before continuing |
|---|---|
| Current goal | Does it still describe the job? |
| Source material | Can you reopen the relevant section? |
| Decisions | Are the latest corrections included? |
| Open questions | Is anything unresolved being treated as settled? |
A staff example
| What happened | The fix |
|---|---|
| An N1 shop spends an afternoon in one chat on a manning brief: three files, a dozen drafts, and a switch from paragraphs to a table when the XO asked. By the end the model keeps producing paragraphs. The old instruction is still in the history and the compaction summary said only "produce a manning brief." | A new chat, the final source file, and a five-line brief saying what the output is, who it is for, and the table format. The first draft in the new chat was right. Two minutes. |
What to do with this
Next time a long chat starts drifting, do not argue with it. Start a fresh one with the source and a written brief. Then read Tokens and the context window for what the limit is and how to live inside it.