Someone on your team says the agent “needs better context.” Four people nod. They are agreeing about a word and disagreeing about the work, and nobody finds out until two of them have built the wrong thing.
I run four systems that all get called context, and they have almost nothing in common. One is a hard capacity limit. One is a 35-million-token corpus. One is a 4.7KB file I hand-edited last week. One evaporates when the session ends. Same word, four owners, four failure modes, four different afternoons of work.
Here is how I keep them apart.
Job one: context as capacity
This is context as a number. The window. It has a ceiling, you can exceed it, and when you do, something gets dropped or summarized whether you like it or not.
Capacity is the only one of the four you can measure without judgment, which is why it dominates conversation. It is also the least interesting, because being under the limit tells you nothing about whether the right things are in there.
My own number is worth stating plainly. Before I type a single word, my agent has already loaded a global instruction file, a shared cross-tool rules file, a workspace guide, a memory index, and a lessons file. Together that is about 75,000 characters, call it 19,000 tokens, spent every session on standing orders. That is my floor, not my usage.
Job two: context as corpus
This is context as a pile of things you could retrieve. Vector store, RAG index, semantic search. It is not in the window; it is the universe you draw from to fill the window.
Mine is Postgres with pgvector, embeddings served by a local model:
select sum(token_count), count(*), round(avg(token_count))
from chunks where status = 'active';
-- 35,035,979 | 159,669 | 219Thirty-five million tokens of retrievable material against a window that holds a fraction of a percent of it. The binding constraint was never storage. It is selection.
The breakdown is the part that changed how I think about this. Of those 159,669 chunks, session transcripts account for 99,259. Archived history from two prior systems adds another 51,165. The hand-curated knowledge vault — the notes I actually wrote on purpose — is 2,515 chunks, about 1.6% of the corpus. The rest is exhaust.
That ratio is not a bug I am about to fix. It is what a retrieval corpus looks like after eighteen months: mostly a record of what happened, with a thin seam of what you decided.
Job three: context as instruction
This is context as a durable file you hand-author and version. CLAUDE.md, AGENTS.md, cursor rules, system prompts checked into the repo. It loads every session, it is read by a machine but written by a person, and it goes stale silently.
The artifact:
$ ls -la ~/.codex/AGENTS.md
~/.codex/AGENTS.md -> /Users/mpt/.claude/AGENTS.core.mdOne 4.7KB file of rules — never commit secrets, never deploy without asking, batch privileged steps into one paste-able block — symlinked so that two different vendors’ coding agents read the identical text. I edit one file; Claude Code and Codex both change behavior. That is context as configuration, and it has more in common with a dotfile than with anything in jobs one or two.
Its failure mode is drift, not overflow. A stale rule is worse than a missing one, because the agent follows it confidently.
Job four: context as session state
This is what is live right now: the conversation so far, what you already tried, the decision you made twenty minutes ago and have not written down. It is the only one of the four that dies on restart.
Everyone underestimates this one until a session compacts mid-task and the agent cheerfully re-litigates something it settled an hour ago. The fix is unglamorous. Write state to disk on purpose, or accept that it is gone.
The two axes nobody separates
Capacity and curation are not the same axis, and treating them as one is where the money goes.
| Small window | Large window | |
|---|---|---|
| Curated input | Fast, cheap, works | Works, costs more than it needs to |
| Uncurated input | Overflows immediately | Fits, and quietly degrades |
The bottom-right cell is the expensive one, because everything looks fine. It fits. Nothing errors. The output is just worse in ways that do not announce themselves.
Anthropic’s engineering team makes this argument in their context-engineering post, framing the model as having an “attention budget” and defining good practice as finding “the smallest possible set of high-signal tokens.” Take the framing seriously but note the position: the company describing your window as a scarce resource also sells the window. That is a claim worth checking against someone with no such incentive.
There is one. Liu et al., published in TACL, tested how models actually use long inputs on multi-document QA and key-value retrieval. Performance was highest when the relevant information sat at the beginning or the end of the input and dropped when the model had to reach into the middle — and that held even for models explicitly built for long contexts. That is peer-reviewed, it is not selling a context window, and it says position inside the window changes the answer. Capacity is not the variable. Placement is.
The widely-cited “context rot” work points the same direction, and the lab behind it sells a vector database, so “long contexts degrade, retrieve instead” is a conclusion they profit from. It survives the objection mainly because Anthropic cites it against its own product interest.
Where this breaks
The four-way split is vocabulary, and vocabulary has a tax. On a two-person team where the same person owns all four systems, this is overhead — go build something. The split earns its keep when the four jobs have different owners, which is exactly when the argument starts.
It also breaks at the edges. Prompt caching sits across capacity and instruction. A compaction step is session state being rewritten into capacity. I am drawing lines through something continuous because the lines make meetings shorter, not because the territory has them.
The question I ask now
When someone says we need better context, I ask which one before anything else: is this a room problem, a retrieval problem, a rules-file problem, or a state problem?
Room is a budgeting question. Retrieval is a ranking and evals question. A rules file is a twenty-minute edit. State is a persistence question. Four different afternoons, four different owners, one shared noun.
I got the shape of this from Shawn Wallace, who ran the same play on the word “agent” and found three jobs hiding under it. The form travels because the industry keeps doing this: a word gets useful, then absorbs every adjacent thing anyone shipped, then stops carrying information.
Writing this post, I ran the count against my own corpus and got 159,669 active chunks. My workspace guide — the instruction file, job three, the one loaded into every session I start — said 126,000. It had been verified eight days earlier. The file whose job is to describe the corpus was wrong about the corpus, and it had been telling every agent I ran the wrong number all week.
Job three going stale about job two. I had to write the taxonomy to catch it.