AI Insights

Context is the lever. Determinism is not on it.

Three of the four claims about context engineering hold up in the published evidence. Determinism does not, and it is the one most likely to end up in a contract.

  • Context engineering improves task performance when input length and tool surface are controlled
  • Grounding cuts hallucination sharply, but does not eliminate it
  • Determinism is a serving-stack property, not a context property
  • Token efficiency matters only after quality, recall, and replayability
By Pradeep Chandran13 min read
Abstract decision node splitting into a governed green branch and an uncontrolled magenta branch on a navy canvas.

Testing the claim that context engineering drives agent performance, cuts hallucination, and produces deterministic results.

Three of the four claims hold up in the published evidence. One does not, and it is the one most likely to end up in a contract. This note separates them and says where the literature is thin. Every figure below is attributed and dated. Where a number reaches us through a secondary write-up rather than the primary source, we say so.

Written for executives deciding how much of an agent programme should be spent on context architecture, evaluation and serving controls.

The four claims, scored

Strongly supported

Task performance

Multiple controlled studies show accuracy falling with input length and with tool-catalogue size, independent of model capability.

Supported, bounded

Hallucination

Grounding cuts hallucination sharply from an ungrounded baseline. It does not reach zero, and agent loops re-amplify what survives.

Not supported

Determinism

Output variance at temperature zero originates in the serving stack, below the layer context engineering operates on. No amount of context design removes it.

Supported, inverted

Token efficiency

Real savings are documented, but caching has made fewer tokens the wrong default. Efficiency is a by-product of good curation, not its objective.

What the term covers

Anthropic published its working definition on 29 September 2025: context engineering is the set of strategies for curating and maintaining the optimal set of tokens during inference, including everything that lands in the window outside the prompt itself. Its framing of the engineering problem is optimising the utility of those tokens against the model's inherent constraints. Source

The scope in practice is wider than a prompt: system instructions, retrieved documents, conversation history, tool definitions, and whatever the agent has written to long-term memory between sessions. A February 2026 methodology survey found the same definition converging across Anthropic, Google's sessions and memory work, LangChain and the prompting guides, which matters for procurement: this is a recognised discipline with shared vocabulary, not a vendor coinage. Source

The claim under test is not that context matters. It is that context is the dominant variable, ahead of model selection. On performance and cost the evidence supports that ordering. On determinism it does not, because the mechanism sits somewhere else entirely.

Length degrades accuracy on its own

Chroma's July 2025 study evaluated 18 frontier models, including GPT-4.1, the Claude 4 family, Gemini 2.5 and Qwen3, on tasks deliberately held at constant difficulty while input length grew. Performance fell anyway. Their central methodological point is that needle-in-a-haystack tests measure lexical retrieval, which models pass easily, and that passing it has produced a false sense that long context is solved. Source

The positional version of the effect is older and well replicated. Liu et al., published in TACL in 2024, found accuracy highest when the relevant passage sits at the beginning or end of the window and significantly worse in the middle, on both multi-document QA and key-value retrieval, and degrading further as the window grows, including on models sold as long-context. Source

Safety monitoring recall under a long prefill Claude Opus 4.6 with thinking, as a monitor on MonitorBench: detecting an agent subtly disabling a firewall.
Attack shown on its own 98.6%
After 800K benign tokens 88%

Across Opus 4.6, GPT 5.4 and Gemini 3.1, dangerous actions were missed 2x to 30x more often when they occurred after 800K tokens of benign activity than when presented alone. Periodic reminders through the transcript partially mitigated it. Source, May 2026

That last result is the one to carry into a board conversation. What failed was the reviewer, not the agent. The only thing that changed was how much irrelevant material came before the evidence, and evaluations that test monitors on short transcripts will overstate how well they hold up in production.

Tool catalogues are context, and they behave like it

Every tool definition is tokens the model reads before the user says anything: roughly 100 to 500 each, so five MCP servers at thirty tools apiece put tens of thousands of tokens in front of the first message. Published vendor guidance clusters between 20 and 50 tools before selection accuracy suffers, with Anthropic documenting degradation past 30 to 50 and OpenAI recommending fewer than 20 per turn.

Tool-selection accuracy against catalogue size Degradation is a cliff, not a slope. Figures below are indicative ranges, not a single benchmark run.
~50 tools 84-95%
~200 tools 41%
~740 tools 0-20%

Series as reported in a June 2026 practitioner write-up of the RAG-MCP study, which also reports retrieval over the tool registry lifting accuracy from 13.6% to 43.1% on a large catalogue while halving prompt size. We have not verified these figures against the primary paper and treat the exact values as indicative. Secondary source

Two mechanisms are at work, and only one is fixable by retrieval. A June 2026 study of a 584-tool catalogue measured routing accuracy falling 16 to 23 points, then decomposed it: even with oracle retrieval, where the correct tool is guaranteed to be visible, roughly ten points remained. That residue is confusion between near-duplicate tools, and better search does not touch it. Consolidating the catalogue does. Source

The cheapest reported intervention is subtraction. GitHub Copilot cutting its tool set from 40 to 13 is reported to have gained 400ms of latency and 2 to 5 percentage points of accuracy at once, which is the shape of result you expect when the constraint is attention rather than capability. Secondary source

Hallucination: a large reduction, not an elimination

Grounding works, and the size of the effect is why the claim is popular. A 2026 study of drug-related question answering reports hallucination falling from 47.8% to 12.3% once retrieval was added, a 74% relative reduction on a 150-question set. It is a preprint on a narrow domain, so read the direction of travel rather than the decimal. Source

The ceiling is better documented than the floor. A 2026 systematisation of agentic retrieval notes that retrieval-augmented legal research tools exhibited hallucination rates up to 33%, contradicting vendor claims, and identifies the three conditions under which grounding fails: retrieved passages that are topically relevant but factually insufficient, documents that conflict with each other, and the lost-in-the-middle effect burying the passage that mattered. Source

In agentic settings the risk compounds. A hallucinated intermediate claim becomes context for the next retrieval and the next reasoning step, so a single error propagates and reinforces across iterations. Grounding a single call is a solved-enough problem. Keeping a fifty-step trajectory grounded isn't, and that's where context architecture earns its keep.

Mechanistically, correct retrieval is not sufficient. Work presented at ICLR found models still contradict accurate retrieved content when internal knowledge circuits overweight parametric memory and the heads responsible for copying external content fail to carry it through. Context engineering raises the probability that the right evidence is present and legible. It does not compel the model to use it. Source

Where the hypothesis fails: determinism

Determinism is not a context property. Thinking Machines Lab showed in September 2025 that temperature-zero inference is not reproducible for a reason that has nothing to do with what is in the window: reduction kernels behave differently depending on batch size, and batch size depends on who else is hitting the server at that moment. Sampling 1,000 completions at temperature zero from Qwen3-235B produced 80 distinct outputs, first diverging at token 103. Source

80 Distinct outputs from 1,000 identical temperature-zero requests
61.5% Throughput cost of the first batch-invariant kernels
34.4% Same guarantee after SGLang added CUDA graphs

The problem is solvable, but at a layer no context strategy reaches. Batch-invariant kernels for RMSNorm, matrix multiplication and attention produced bit-identical outputs across 1,000 repeated runs on Qwen3-8B at roughly a 61.5% throughput cost; the SGLang team later cut that overhead to about 34.35% by combining them with CUDA graphs. Both figures are reported in a June 2026 review of reproducible builds. Source

Two further constraints bear on anyone writing determinism into a specification. The variance is not cosmetic: researchers have documented accuracy swings of up to 9% and multi-thousand-token differences in reasoning length from nothing more than a change in GPU count or batch size. And on hosted frontier APIs the control may not exist at all, since current frontier models may not accept a temperature parameter. If you need bit-level reproducibility, you need a pinned, self-hosted, batch-invariant stack, and you pay for it in throughput.

What context engineering can deliver is the adjacent property, and it is the one worth specifying: reproducible inputs. Identical, versioned, auditable context for a given task, so that when an output differs you can prove the difference came from the model and not from your pipeline. Call that determinism in a contract and you will fail an audit. Call it bounded variance with a replayable input record and you can defend it.

Token efficiency, and why it should rank last

The savings are real. A June 2026 paper on self-compacting agents, where the model decides when to summarise rather than firing on a token threshold, reports beating a no-summarisation baseline by up to 18.1 points on maths and 5 to 9 points on agentic search across six benchmarks and seven models, at 30 to 70 percent lower cost per question. Notice the ordering. Quality moved first and the cost followed. Source

Caching has since inverted the naive version of the advice. Because a prefix the provider has already processed is billed at a fraction of list price, roughly 90% off on Gemini and about fifty times cheaper on DeepSeek's cached rate, resending a long history can cost less than rewriting it. An August 2026 evaluation on a production AI tutor found keeping the full history beat every summarisation preset tested on cost, latency and recall simultaneously, because summarising invalidates the cached prefix and you pay full price to recompute what you were trying to save. Source

The most useful finding in that evaluation is a warning about measurement. Compacting presets answered from windows of 95K to 195K tokens and lost planted facts, while the full-history preset answered from 363K to 879K and never missed. A blind judge scored the compacting preset 97 to 99 percent for answer quality while its actual memory recall sat at 58 percent, and rated it good 100 percent of the time on the very turns where the fact had demonstrably been lost. Quality scores will not surface this failure. Only a recall probe will.

This is why token count is the wrong headline metric, and why the hypothesis is right to rank it below the rest. The defensible unit is cost per successfully completed task across the whole run, not price per request or the size of the final call.

What to do with this

Measure your own safe budget

Degradation curves differ by model and by task. Advertised window size and usable window size are separate properties. Establish the point where your workload degrades, on your evaluation set, and treat it as a budget.

Audit the tool surface first

It is the cheapest intervention with the best-documented return. Remove near-duplicates before adding retrieval over the registry, since retrieval does not fix confusion between tools that overlap.

Probe for recall, not scores

Plant facts early in a session and test for them later. A judge scoring answer quality will report health while the agent is quietly answering from a context that has lost the point.

Compact on a boundary, not a counter

A threshold fires mid-derivation and discards partial results the agent then pays to rebuild. Compact when a sub-task closes. With caching in play, check whether you need to compact at all.

Record context, replay runs

Version every input the agent saw, so a disputed output can be re-run against the same context. This is the honest substitute for determinism, and it is achievable on hosted APIs.

Buy determinism separately

If a regulator requires bit-level reproducibility, it is a serving decision: pinned versions, self-hosted, batch-invariant kernels, roughly a third of throughput given up. Do not let a context roadmap carry that promise.

Limits of this evidence

Three gaps matter here. First, most degradation studies are controlled benchmarks rather than production agents, and the two don't map cleanly. Second, several of the sharpest numbers in the practitioner literature, including the tool-count series and the Copilot result above, reach us through secondary write-ups rather than reproducible primary reports; they are directionally consistent with each other, which is weaker than replication. Third, almost nothing published isolates context engineering from model choice with a controlled comparison, so the claim that context outranks model selection is inference from convergent evidence rather than a measured result.

What is firmly established: degradation with input length across every frontier model tested, positional sensitivity within the window, non-linear collapse of tool selection with catalogue size, hallucination reduction from grounding with a non-zero floor, and the serving-level origin of output variance.

Sources

  1. Anthropic, Effective context engineering for AI agents, 29 September 2025. anthropic.com
  2. Hong, Troynikov and Huber, Context Rot: How Increasing Input Tokens Impacts LLM Performance, Chroma Research, July 2025. trychroma.com
  3. Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni and Liang, Lost in the Middle: How Language Models Use Long Contexts, TACL vol. 12, 2024, pp. 157-173. MIT Press
  4. Classifier Context Rot: Monitor Performance Degrades with Context Length, arXiv 2605.12366, May 2026. arxiv.org
  5. SoK: Agentic Retrieval-Augmented Generation, arXiv 2603.07379, 2026. arxiv.org
  6. ReDeEP: Detecting Hallucination in Retrieval-Augmented Generation via Mechanistic Interpretability, ICLR. openreview.net
  7. Retrieval-Augmented Generation for Reducing Hallucinations in Drug-Related Question Answering, Research Square preprint, 2026. researchsquare.com
  8. He and Thinking Machines Lab, Defeating Nondeterminism in LLM Inference, September 2025. thinkingmachines.ai
  9. Reproducibility is the New Copyleft, arXiv 2606.03019, June 2026, reporting the batch-invariant kernel overhead figures. arxiv.org
  10. Causal Agent Replay, arXiv 2606.08275, 2026, on provider nondeterminism and replay fidelity. arxiv.org
  11. Crosley, Context Compaction Is a Decision, Not a Threshold, June 2026, summarising Self-Compacting Language Model Agents. blakecrosley.com
  12. Bouchard, Context Engineering in 2026: Why We Stopped Compacting Our Agent's Context, August 2026. louisbouchard.ai
  13. How Many Tools Can an AI Agent Handle, July 2026, on the 584-tool routing study and the confusion gap. nerdleveltech.com
  14. Secondary, unverified against primary sources: MCP context bloat analysis, June 2026 albato.com and the Tool RAG write-up, June 2026 webscraft.org
  15. Context Engineering: A Practitioner Methodology for Structured Human-AI Collaboration, arXiv 2604.04258, 2026. arxiv.org

Build grounded agents

Build agents that reason inside your business logic

See how lowtouch.ai turns enterprise rules, policies, and semantic context into governed agents running inside your appliance.

About the Author

Pradeep Chandran

Pradeep Chandran

Lead - Agentic AI & DevOps

Pradeep Chandran is a seasoned technology leader and a key contributor at lowtouch.ai, a platform dedicated to empowering enterprises with no-code AI solutions. With a strong background in software engineering, cloud architecture, and AI-driven automation, he is committed to helping businesses streamline operations and achieve scalability through innovative technology. At lowtouch.ai, Pradeep focuses on designing and implementing intelligent agents that automate workflows, enhance operational efficiency, and ensure data privacy. His expertise lies in bridging the gap between complex IT systems and user-friendly solutions, enabling organizations to adopt AI seamlessly. Passionate about driving digital transformation, Pradeep is dedicated to creating tools that are intuitive, secure, and tailored to meet the unique needs of enterprises.

LinkedIn →