> Site index: [llms.txt](https://ortelian.com/llms.txt) with all pages and descriptions.

# More context makes agents worse

Source: https://ortelian.com/notes/more-context-makes-agents-worse/
Markdown: https://ortelian.com/notes/more-context-makes-agents-worse.md
Author: Laurens Nys
Published: 2026-08-17

Past a point, adding context degrades an agent. It needs the smallest sufficient view of the work, and only a model of the company can decide what that view is.

When an agent gets something wrong inside a company, the first instinct is to give it more. Paste in the docs. Index Slack. Widen the window. That instinct is wrong. Past a point, more context makes the agent worse, not better. A production agent needs the smallest view of the work that is still sufficient for the step it is on. And deciding what that view is cannot be done by retrieval. It takes a model of the company that knows which facts are current and which source wins.

## The pile gets bigger and the answer gets worse

This is not a matter of taste. Anthropic’s own guidance on context windows says accuracy and recall can degrade as the token count grows, and Chroma’s context rot research showed the same shape: focused inputs beat full inputs padded with material that is merely related. All [18 models Chroma tested](https://research.trychroma.com/context-rot) got worse as the input grew, on tasks as simple as copy and retrieve, well before the window was full. The model does not get wiser as you add tokens. It gets asked to infer the company from noise.

Take a go-to-market agent asked a plain question: what should we do with this account after yesterday’s call? The naive build loads everything it can find. The CRM record. The full transcript. Forty Slack threads that mention the company. The onboarding doc. A ticket export. The window is full and it feels thorough.

It is full of traps. The CRM says the opportunity is in discovery. The transcript says the customer will expand if one workflow ships by Q3. A Slack thread says product never approved that date. A ticket holds the real blocker under a vague title. The agent now has to work out which of these is true today, and nothing in the pile tells it.

What it needed was five things. The account. The latest accepted state of the deal. The one call. The open promise. The next action it is allowed to take. Everything else is available if it asks, and harmful if it does not.

*Diagram: Left, what the naive build loads: CRM record, full transcript, forty Slack threads, onboarding doc, ticket export and old summaries stacked almost to the top, with the CRM stage and a Slack thread contradicting each other. Right, what the step needs: five short items, the account, the latest accepted state, the one call, the open promise and the next allowed action, with everything else left queryable.*

*The same question, two views. The second is the one that gets answered right.*

## The meeting-prep agent works because it sees almost nothing

The clearest case I have is at a deep-tech company that sells into hospitals through integrators. Every morning at 9am a meeting-prep agent posts in a shared Slack channel. It takes that day’s external meetings, and only those. For each one it pulls previous calls, emails, deal history and similar companies from the CRM and the graph. That is the whole view. No product docs, no pipeline report, no Slack history, no other accounts.

The rep found the channel on his own. He now reads it before every external meeting. When he wants more, he asks a follow-up in the thread and the agent fetches it. When the output is off, he says so, and the feedback changes what comes out tomorrow.

The small view is why it is trusted. A prep note built from everything the company knows would be long, slightly wrong in places and ignored by week two. A note built from the four things that matter for this meeting gets read.

The same rule holds inside the runs. A sub-agent is spawned per account, with that account’s view and nothing else. Each run leaves a trace on the graph, so the next run starts where the last one stopped instead of re-reading the history to find its place.

## Retrieval returns what matches, not what governs

If the answer were “load less”, you could fix it with a better search. You cannot, because search does not know what is current.

At a planning-software company, a new head of sales, three weeks in, stopped all outbound and changed deal stages without telling the CFO. Nobody inside the company knew the full plan. An agent working from the CRM that week would have been working from a fiction. Work paused until the priorities were aligned.

Now ask what retrieval would have done. A query for the account’s stage returns the CRM field, a Slack message from two months earlier, a call summary that mentions the stage in passing. All of them match. All of them are ranked by similarity. None of them carries the one fact that matters: this was changed last week by someone with the authority to change it, and the rest are superseded. The text does not carry that fact. The company around the text does.

A world model holds that property. Every promoted fact carries provenance: where it came from, who put it there, when it was true and when it was recorded. A new fact supersedes the old one. Nothing overwrites in silence. So “what is the current stage” has one answer, and “who changed it, and from what” is a separate question with its own answer. Retrieval finds the evidence. The model decides which evidence wins. I have written about what that model contains in [what a world model for a company is](https://ortelian.com/notes/what-is-a-world-model-for-a-company/).

## Keep everything queryable, put only the current state in the prompt

The architecture that follows is three layers, and the order matters.

At the bottom, raw evidence: transcripts, emails, Slack, CRM history, source rows. It is stored, immutable and queryable. Nothing is thrown away. Above it, the world model: the current accepted state of every company, person and deal, each fact with its provenance and its supersession chain. At the top, the prompt for one step, which gets the current state of the objects that step is about, plus handles to go deeper. If the agent needs the transcript, it asks for the transcript. It does not start with it.

*Diagram: Three bands stacked bottom to top. Evidence, the widest: transcripts, emails, Slack, CRM history and source rows, immutable and queryable. World model: the current accepted state, each fact with provenance and supersession. One step's view, the smallest: the objects this step is about plus handles to go deeper. Arrows promote evidence into the model and select a view from it; a return arrow from the view asks the evidence for more.*

*Everything is kept, little is loaded. Evidence stays queryable, the model holds the current state, and one step sees only the objects it is about.*

The daily list at the deep-tech company is the same shape at a different scale. Their partner list was a spreadsheet of about 2,700 companies. We rebuilt the territory as a graph from government sources, hospital lists and integrator registries, and it collapsed to 64 ranked accounts. The rep’s top 50 refreshes at 7am and shows only net-new companies, so he has a fresh list by 9am. The graph holds every company it was built from. The view holds what he can act on today.

The obvious objection is that bigger windows will solve this. They will not. A window of a million tokens lets you load all forty Slack threads instead of ten. It does not tell the agent that the stage in thread twelve was superseded last Tuesday. And a company produces text faster than windows grow: every call, every email, every CRM edit adds to the pile. Bigger windows extend the problem. They do not remove it. The window is working memory for one step. The company is not working memory.

Give the agent the smallest view that is sufficient, and build the model that knows what sufficient means.

## Follow the work.

Roughly monthly. Notes only. Unsubscribe anytime.

Email address