Why More Context Can Produce Worse Decisions

Part I: Why More Context Can Produce Worse Decisions

A route optimizer, more than 1.4 million rejected states, and the difference between an agent that answers and a system that can be debugged

What this article covers

• Why a larger context window cannot define ownership between modules.
• How preserved refusals exposed the real cause inside roughly 1.6 million rejected route states.
• Why one module should answer one question and have a valid way to refuse.
• When multiple agents help, and when coordination costs make them worse.

For a week, we kept looking at the economics.

The application was supposed to collect potential vehicle orders from a commercial load board, store the evidence locally, combine compatible orders, build possible routes, and test those routes against price, gross revenue, revenue per mile, trailer capacity, pickup sequence, delivery sequence, and a list of operating constraints.

The program ran. The database contained results. The session still reported an error.

So we inspected the code, changed a calculation, assembled another version, ran it again, found another problem, and repeated the whole thing. The individual pieces of code were usually fine. The system was not. A module would produce a valid result, another module would interpret the state differently, and the final status would tell us that nothing useful had happened.

We were not using cheap models or low reasoning settings either. That did not save us.

The project and platform are intentionally unnamed here. Some operational figures are rounded to protect the underlying system. The sequence of events and the engineering mechanism are unchanged.

The problem was architectural.

The expensive model still sees the wrong problem

There is a strong temptation when building with AI agents. You have a project and a list of changes, so you put everything into one large prompt. Fix the database logic, change the ranking, update the route builder, revise the economics, run the tests, prepare a new release.

Why split it into modules, separate commits, local tests, handoffs, and another release cycle? The agent can read the repository. Let it work.

And it does work. It writes good code, finds syntax errors, repairs tests, changes files quickly. Then the project reaches the part where one correct decision depends on another correct decision made somewhere else.

That is where the trouble starts.

In an early design, more than 8,000 lines mixed SQL, search, ranking, economics, and session lifecycle. Every serious defect in the history of the project lived in that area. This was not because the file was large by some cursed threshold. It was because it contained several different decisions with several different definitions of success.

An agent working there had too much permission and too much context. It could see the order, the route, the economics, the search state, the database, the final target. That sounds useful. In practice, it encouraged the agent to make decisions outside the question it was supposed to answer.

Once that happens, a result becomes difficult to reproduce. Did the order disappear because its evidence was unreadable, because the trailer could not carry it, because the route was unprofitable, because the search had already filled the trailer, or because the agent saw all of those facts and made one reasonable guess?

"Reasonable" is a terrible failure code.

Long context is capacity, not attention you can trust

The research is getting clearer on this point. A large context window lets a model receive more tokens. It does not guarantee that the model will use every relevant token with equal precision.

The 2023 study Lost in the Middle found that language models often performed best when relevant information appeared near the beginning or end of a long input, and worse when it appeared in the middle. The effect appeared even in models designed for long contexts.

RULER, published in 2024, went beyond simple needle retrieval. It tested retrieval, multi-hop tracing, aggregation, and question answering across increasing context lengths. Models that looked nearly perfect on a basic needle test degraded as the inputs became longer, the distractors became harder, or several pieces of evidence had to be combined.

NoLiMa, an ICML 2025 paper, removed the easy lexical match between a question and the evidence. Twelve long-context models were tested. At 32,000 tokens, ten fell below half of their strong short-context baseline. GPT-4o went from 99.3 percent in the short setting to 69.7 percent at 32,000 tokens.

Then a 2025 preprint, Context Length Alone Hurts LLM Performance Despite Perfect Retrieval, tested five open and closed models on math, question answering, and coding. Performance fell by 13.9 to 85 percent as input length grew, even when the correct evidence had already been retrieved. The authors also replaced irrelevant content with whitespace, masked it, or placed the evidence directly before the question. The degradation remained.

These papers do not prove that less knowledge makes a model more intelligent. They support a narrower and more useful claim: the amount of text a model can accept is larger than the amount of text it can reliably use for every decision.

That difference is where agent engineering begins.

One module, one question

We changed the project around a simple rule:

One module answers one question. If the question cannot be written in one sentence, it is probably two modules.

The order acceptance module asks: is this card readable and physically admissible?

The economics module asks: does the assembled route pass the rate threshold?

Both modules touch the same orders. They do not own the same decision.

This distinction matters. In one captured run, the acceptance module recorded outcomes for more than 15,000 cards in a sealed evidence database. The rounded breakdown was:

about 14,000  accepted
about    700  vehicle description not visible
about    500  unsupported vehicle class
about    250  nonpreferred duplicate
about    140  unsupported vehicle description
about    100  vehicle type not visible
about     60  unresolved location
about a dozen  inconsistent evidence
about a dozen  vehicle count exceeded capacity
fewer than ten  missing vehicle count

It accepts an order paying roughly $350 for almost 900 miles. That is about $0.40 per mile, and it looks awful by itself. The acceptance module does not care. Profit depends on what travels with that vehicle, and this module is not allowed to know what the trailer will carry later.

The boundary is clean because the module can pass an unprofitable order and still be correct.

Now take vehicle count. The count can appear in a semantic title, a slash-separated list, an explicit 2 Vehicles prefix, or a separate line. The module compares those sources. If they disagree, it returns partial. It is forbidden to decide which source feels more believable.

This is the difference between a bounded agent and a project-wide agent. The bounded agent has a defined place where it can say, "I do not know." The project-wide agent tends to produce an answer because the system has not given it a valid refusal state.

The week we repaired the wrong subsystem

The best example came later in the route search.

The downstream search produced roughly 1.6 million rejected candidate states. Everyone suspected the economic model. It made sense. A trailer carrying one vehicle produced around $1.10 to $1.60 per mile, while the release threshold was around $2.25.

We worked on the economics for a week.

Then we grouped the stored refusals by reason:

more than 1.4 million  single-occupancy leg exceeded its limit
about       153,000  insufficient progress toward the target
about        22,000  too many candidates from one parent state
about         4,000  single-vehicle leg exceeded its limit
about         3,500  empty leg exceeded its limit
fewer than       10  combined route rate below minimum

Economics had rejected six candidates.

The real problem was geometry.

One confirmed run parameter limited the distance a trailer could travel with exactly one vehicle aboard to roughly 100 miles. The rule sounded sensible: do not move a half-empty trailer across the country.

But the same rule covered the drive from the first pickup to the second pickup. To load the second vehicle, the trailer has to travel part of the route with one vehicle aboard. The rule prohibited the exact maneuver that made a two-vehicle trailer useful.

A second query confirmed it. Across fewer than 200 examined states, maximum occupancy was one. The trailer never became full. The economic model could not approve a paired route because the search almost never allowed a pair to exist.

We changed a confirmed parameter from roughly 100 miles to roughly 300. No code change. On the next run, the trailer was full for about 87 percent of route miles, and the candidate moved above the release threshold.

Then it hit another rule: a loaded leg had to be roughly 100 miles, but one segment was about 60. That threshold came from an older design, before the application evaluated the economics of the complete route. Its reason had disappeared. The number remained.

After removing the obsolete constraint, the next run released a route with several orders, roughly $4,500 in revenue, and just under 2,000 miles.

One local threshold had killed almost nine out of ten candidate states. It sounded reasonable, belonged to a different operating assumption, and broke a part of the system that looked unrelated to it.

We found it because every refusal survived.

Operations taught me the same lesson earlier

I had seen this pattern before AI.

In a galvanizing plant, a large order can push production close to round-the-clock work. The problem is not only the number of parts. Different parts require different operations, the normal pace becomes uneven, workers have to intervene manually, and one blockage moves down the conveyor.

Industrial cleaning works the same way. A crew enters a site with a fixed time window. Detergent arrives late, the industrial vacuum was not cleaned, protective equipment is missing, and one small delay moves through the whole job. Delay becomes lost money.

The system rarely fails because nobody knows how to perform an individual operation. It fails at the handoff, where the state of one operation becomes the input of the next.

AI applications have the same weakness. A model can write each function correctly and still mishandle the transition between parsing, persistence, search, ranking, economics, and release. More intelligence inside one step does not repair an undefined contract between steps.

Why multiple agents sometimes help, and sometimes make everything worse

Splitting work across agents can help for two reasons. Each agent gets a cleaner context, and independent work can happen in parallel. But the task has to support that separation.

Anthropic reported that its multi-agent research system outperformed a single-agent setup by 90.2 percent on an internal research evaluation, especially on breadth-first questions that could be searched in independent directions. The same report says token usage alone explained 80 percent of performance variance on BrowseComp. More agents were useful partly because the system spent more inference and more tool calls on the problem, not because a committee became wise by magic. Anthropic's engineering report

A 2025 paper, Why Do Multi-Agent LLM Systems Fail?, analyzed 1,642 execution traces from seven multi-agent frameworks and identified 14 failure modes across system design, inter-agent alignment, verification, and termination. The authors found failure rates from 41 to 86.7 percent in the systems they examined. Changing prompts helped some cases. Changing the system topology and verification process mattered more.

The clearest quantitative warning came from Google's 2025 preprint and January 2026 research report, Towards a Science of Scaling Agent Systems. The team tested 180 configurations across four benchmarks and three model families. Centralized coordination improved a parallelizable financial reasoning task by 80.9 percent. On sequential planning, every multi-agent design made performance worse, by 39 to 70 percent. Independent agents amplified errors by 17.2 times, while a central coordinator reduced that amplification to 4.4 times.

The lesson is plain. Use multiple agents when the work has independent branches and a clear point of synthesis. Keep one reasoning chain when each decision depends tightly on the decision before it.

More agents are not an architecture.

A better statement of the idea

I started with the intuition that AI performs best in a limited environment because limited environments contain limited knowledge.

I would state it differently now.

An agent performs more reliably when its environment contains enough knowledge for one decision, explicit limits on what it may change, a valid way to refuse, and evidence that remains after failure.

The accepted order matters. The rejected order matters too. The route that passed matters. The more than 1.4 million candidates killed by one rule matter more, because they tell you where the system is lying to itself.

A bounded agent does not necessarily make fewer mistakes.

Its mistakes can be found.

Practical takeaways

1. Define the module's question in one sentence.
2. Give the module explicit acceptance, refusal, and partial states.
3. Preserve decisions and refusals in an append-only evidence log.
4. Group failures by reason before changing the subsystem that seems guilty.
5. Use a central coordinator when later stages depend tightly on earlier decisions.

In brief

• Context capacity is not trustworthy attention.
• Bounded responsibility makes failures traceable.
• Preserved refusals can be more diagnostic than successful outputs.
• More agents help only when the work can be separated and synthesized clearly.