Deterministic Harnesses, Probabilistic Models: A Context Engineering Playbook for Development Teams

ItInsightsWorld · SoftwareDevelopment desk · By James Hartley, IT Insights

When an AI-assisted feature starts misbehaving with no model swap and no deploy to blame, the fault rarely sits inside the model. It sits in the code that decides what the model is allowed to see. That was the thesis of a short session delivered this week at AGNTCon, titled Context Fails & Fixes and framed as an informal State of Context Engineering: where the practice came from, where it moved, and where it is still moving. Nothing about the shift made the problem smaller — it moved the problem from probabilistic model calls into deterministic code, and every such move invents fresh ways for context to break.

The deck circulated afterwards opens modestly: thanks for joining today, and a two-step agenda — look at the failures first, then at the fixes that trail them.

Why this class of bug is not temporary

One slide announced a forthcoming title, The Context Engineering Handbook, and used it as a stress test for the whole discipline. When the project was first discussed with the team at O’Reilly back in June 2025, the publisher asked the fair, blunt version of the question every engineering lead asks about AI tooling: “How do we know this won’t become obsolete in a few weeks?” Textbooks in this field rot unusually fast.

The reply on stage was candid uncertainty plus a single bet. Unambiguous instructions about what to do and what not to do, delivered consistently and without noise, will stay an AI problem however capable the models get. We already share offices with sentient coworkers and partners who pass the Turing test, the ones we jokingly label AGI — and getting an idea cleanly from one head to another is still unreliable work.

Context engineering stays hard in distinctive ways, precisely because models are not people. Pick whatever anthropomorphizing verb you like for how a model interprets things; what matters for a delivery team is that construction, optimization and training each generate a specific set of failure modes. Treat that list as a requirements document, not as research trivia.

The long-context detour, in one page

Rewind to the end of 2024 and the peak of the “RAG is dead” mood. The bet was that a window big enough to swallow the internet plus every relevant document would make selection, retrieval and agentic scaffolding unnecessary — and the problem solved.

Builders chased length and delivered a jump from ~128,000-token context window models to million-token context window models, starting with Gemini 1.5.

Literature for Gemini 1.5 Pro led with the million-token window and dangled a 10-million-token context window model supposedly just around the corner from the lab.

The edge did not hold. Llama 4 Scout showed up with a 10-million-token window that turned out to be difficult at inference time, Scout never really caught on, and another Llama never appeared. Still, a million tokens was good enough for teams to accept.

The working brief of that season fit on a sticky note: dump everything into context and let the model sort it out.

Extra context bought extra room for extra problems. Long windows are not a cure; they are a bigger surface for defects.

Four failure modes every team eventually ships

Earlier reporting on this subject isolated four key failure modes. Restated as symptoms you will see in a code review or an incident channel, they look like this:

• Context poisoning — something that never belonged in the window arrives (a hallucination, a bad fact) and the model cannot walk past it. Your agent keeps re-planning around one false premise.
• Context distraction — the window grows so long that the model starts preferring it over its base knowledge. The output quietly tracks whatever you pasted last instead of what the task needs.
• Context confusion — facts unrelated to the problem slip in and steer the answer in ways nobody fully understands. The model forms assumptions about who you are and answers to those instead of the request. Pernicious, and easy to miss.
• Context clash — tool calls, skills and other information inside your harness begin contradicting each other and working against you in unexpected ways.

A concrete configuration choice was offered as the demo for confusion: memory switched on in ChatGPT or Claude. One thread is a work conversation, the next is a school project with a kid; the assistant takes notes on both, blends them, and the confusion compounds. Switching it off is a settings decision, not a philosophy.

The go-to illustration of poisoning comes from a handheld game. The 1996 original Game Boy release, the first Pokémon Red, shipped in black and white. In 2004, Nintendo issued Pokémon FireRed for the Game Boy Advance — effectively the same game with better colors and audio, plus one quiet change. In both Pokémon Reds you clear a security guard by handing him something to drink (a bribe, and quite the practical lesson for children): the original guard asks for lemonade, the FireRed guard asks for iced tea.

That single wording change broke an agent. The Gemini 2.5 technical report described researchers running Pokémon as an agent benchmark, because it is a reasonably controlled environment that does not move fast. Repeatedly, Gemini 2.5 decided it needed tea while playing the older game: the FireRed tea task was baked into its weights, so it poisoned its own context and spent hours hunting for tea to hand over. Once tea entered the to-do list, nothing dislodged it.

Distraction has a cleaner experimental trail. Ask a room of engineers who write code whether they ever let the window run to a million tokens and fill it: roughly half the hands go up. The speaker's own ceiling is nearer 200,000 or 300,000 — glance at the counter, see it is at 250,000, read that as a big job coming, reset, and start clean.

The paper Do as I Say, Not as I Do, by Carolina Camassa and Derek Shiller, shows the mechanism. The model receives one standing rule — “I want you to translate every question into Russian as your answer to each of my questions” — and then a stream of examples that violate it, questions answered in French. Those examples are not new instructions; they are only chat history. Then a real question is asked.

Scored as a matrix — contradictory-example count on one axis, model on the other, cell values the share of answers that obey the rule rather than the pattern — the effect touches every model. Gemma 3 12B is following the instruction less than half the time after only a handful of bad examples. Opus 4.6, an amazing model, needs many more examples before it slips, but it slips too.

Translate that to your own workflow: twenty rounds of CSS tweaks on one component, every rejected attempt still sitting in the transcript. Those rejects are the French answers, and the model is learning from them.

Gemini 2.5 met the same wall inside Pokémon. Google was proud of the million-token window and the paper implied two million tokens were around the corner; buried in the appendix was the observation that once context grew significantly beyond 100,000 tokens, the agent started repeating actions from its history instead of synthesizing new plans. Appendix pages are still the best documentation, and marketing teams rarely read them.

More information and more errors both fit in a long window. That trade is the reason the industry stopped treating capacity as a feature.

The toolbox: six of them, and they have not changed

Strikingly, new challenges arrived while the remedy set stayed stable. These are six of them.

1. Context augmentation — RAG, skills and any other route that pulls the information relevant to the current problem into the window.
2. Tool loadout — choosing which tools and skills to expose so the model is not overloaded. The cautionary case: an enterprise team whose agents suddenly degraded, traced back to their enterprise software loading 600 skills for every engineer at startup. The remedy was filtering through a loadout function.
3. Context quarantine — subagents and peer agents that boot with a blank history but operate in the same environment.
4. Context pruning — Claude Code and Codex already do this, sometimes invisibly; early compaction strips tool results you no longer need.
5. Context offloading — pushing state into the environment, such as Markdown files or a database, for retrieval later.
6. Context summarization — what everyone calls compaction.

Over the last two release cycles those capabilities moved out of the prompt and into the harness, where they can be tested like ordinary code.

Step by step: four fixes inside one agent loop

The demonstration uses DSPy, chosen because it is an incredibly readable and effective way to build AI workflows and agents, and because it works well as a language for simply specifying behavior.

Strip an agent down and it is a while loop. A ReAct module receives a request, is asked for a response, and is handed some tools; the tools are just Python functions. Pair one big model — Claude opted for Claude Sonnet 4.5, good luck with that — with Jev as the small model, a tiny decision model making lightning-fast calls. Substitute any small LLM for Jev and the same wiring still runs. Input goes to ReAct, the accruing history is carried forward, and you have an agent in about a dozen lines, fewer if the second model is dropped.

Step 1 — Tool loadout as a function

Hand Jev the request plus one tool and ask whether that tool is needed for this task. Jev is fast enough to process them one at a time. Wrap the check in a function that iterates every tool, asks per tool, and returns the top-ranking subset. No framework required — it is plain code.

Step 2 — Quarantine as a subagent

Expose an agent as a tool that the main agent can call. Because the subagent starts with a blank history, contaminated reasoning never crosses back into the primary thread — only the result does.

Step 3 — Pruning the history

Walk the transcript turn by turn, pass each one to Jev, ask whether it is still needed, and cut it if not. Rough or elegant is your call, but mind prompt caching while you do it.

Step 4 — Compaction and summarization

Rewrite history the same way: take the old turns, produce a summary, and continue from that summary. One refinement worth stealing is deciding what matters before compacting — run Jev or another decision model as a first pass to judge relevance, then summarize only the surviving subset. One extra step, materially better summary.

Assemble the four pieces and the diff is 16 lines of changes: Four fixes, one loop. The mechanics of harness engineering are remarkably small; the vocabulary around them is not.

Renaming every eighteen months, same job

The hard part is tracking the language, which turns over constantly. A Stewart Brand line quoted on stage is a useful compass:

If you want to know where the future is being made, look for where language is being invented and lawyers are congregating.

In 2023 the job of choosing the right information to get the right response was called prompt engineering. In 2025 it was context engineering, with one difference: it was no longer just you writing the prompt, it was your system dynamically assembling the context. As more of those mechanisms left the context and became code, the label shifted again to harness engineering. The deliverable never changed — moving the work of assembling context out of probabilistic model calls and into deterministic code.

2024 → 2026: what changed in the pitch

The earlier sales pitch was capacity: make the context so large that everything fits. The current pitch is agency: teach the model to drive the harness and manage its own context. That is now the dominant pattern model builders are working toward, and the numbers describe why long-running agents became plausible.

Long-horizon targeting is universal now. The METR reports put GPT-5 at tasks around 3.4 hours on that measure and Gemini 3.1 up to 6.4 hours — with a harness, and with models getting much better at using it, which is exactly what lets them run that long. Opus 4.6 reached around 12 hours, and the conversation has moved on to agents running for days, swarms of agents, and models driving harnesses over far longer stretches.

Window	Dominant pitch	Engineering artifact	Failure modes it produced
end of 2024	Everything fits in context (“RAG is dead”)	Bigger windows: 128,000-token to million-token and 10-million-token	Poisoning, distraction, confusion, clash
2025	Assemble context in code	Six harness tools; loadout, quarantine, pruning, compaction	Caching side effects, over-summarized state
2026	The model drives the harness	Agentic models targeting long horizons	Fighting the weights, context inertia

Two new failure modes landed on us

Teaching models to drive harnesses produced, so far, two new failure modes.

The first is overfitting to the tools and environments a model was trained inside. At an MCP conference, plenty of the room has used the Playwright MCP server or something like it. Smaller models — something along the lines of Haiku or Luna — frequently botch that tool call on the first attempt, then recover and adjust parameters, because the training environment contained similar tools that looked different from Playwright, whatever Anthropic or OpenAI used while training. I call the resulting tax fighting the weights: the model does not do what you ask because you are working against what it was trained to do. It is a real problem, and not only for users — the labs and the teams building products on them contend with it too.

What weight-fighting looks like in a shipped system prompt

Inspect a slice of the Claude Code system prompt and its tool instructions. For a long time the training environments these models learned in were largely serial; they are becoming more parallel, but when those examples were pulled the biases ran toward serial behavior. So the instructions push back over and over: no, no, no, use parallelism, make multiple tool calls at the same time. Please make tool calls in parallel when they are independent — seven times in one place, four times in another, two times here, three times there.

Practical reading rule for anyone auditing an agent prompt: repetition and all-caps are a tell that somebody is fighting the weights, and that the instruction is a patch rather than a preference.

Context inertia: the bug teams blame on the vendor

The second pattern is newer — four parties landed on it just last week. The name used on stage is context inertia: a model hyper-focuses on a hypothesis, subtask, or goal sitting in its context and keeps pursuing it long after it should stop.

The converging write-ups come from several directions at once, including Microsoft Research, Shangyin Tan at UC Berkeley, and the work circulating under the name Memento. The version that lands hardest with engineers is the support-desk exchange: someone reports “My coding agent’s doing something weird. Claude’s been nerfed.” The productive follow-up is a one-line question — “How big is your context?” — and the reply is almost always “Oh, I’ve got 800,000 tokens.”

Put the two halves together and you get the failure profile: an agent that has been grinding for an hour and a half on a hypothesis it should have abandoned, in a window far past the point where it can still synthesize new plans. The counter-measure is unglamorous capacity management — reset near 200,000 tokens rather than arguing that the vendor weakened the model.

Common misconceptions worth retiring

• A bigger window means fewer mistakes. It means more room for mistakes; capacity and error surface arrive together.
• Chat history counts as learning. Rejected attempts and off-instruction examples behave like examples the model will imitate — see the Russian-versus-French matrix.
• Headline specs describe runtime behavior. The million-token marketing and the appendix note about degradation past 100,000 tokens came from the same report.
• Every bad output is a model regression. The “nerfed” complaint is usually an 800,000-token context problem.
• Anthropomorphism helps debugging. Models are not people; their construction defines which failures they can produce.
• More skills is more capability. 600 skills exposed to every engineer is a loadout bug, not a feature set.

FAQ

Q: Should we drop RAG now that windows are larger?
A: The “RAG is dead” claim from the end of 2024 assumed capacity would replace selection. Context augmentation is still the first of the six harness tools, and dumping everything in is what created poisoning and distraction.

Q: What context length should our agents target?
A: Treat the counter as a budget. Around 200,000 or 300,000 is the stated review point, 250,000 is the reset trigger, and the practical ceiling for inertia is far below 800,000 tokens.

Q: Where do we start if we have no harness at all?
A: With the smallest loop that works — a ReAct module, a few Python tools, one large model — then add loadout, quarantine, pruning and compaction in that order. The whole set was about 16 lines of changes.

Q: Why does our agent ignore an instruction it followed yesterday?
A: Either the history now contains contradictory examples that outweigh the instruction, or the model is fighting the weights, or inertia has locked it onto a stale hypothesis. Check history size before checking the model version.

Q: Are long-running agents safe to put in a sprint plan?
A: Estimate them against the reported horizons — 3.4 hours for GPT-5, 6.4 hours for Gemini 3.1, around 12 hours for Opus 4.6 — and remember those figures are measured with a harness in place.

Action recommendations for your next iteration

1. Instrument context size in every agent surface and alert on the growth curve, not just token spend.
2. Set an explicit reset budget per workflow and enforce it before compaction does it silently for you.
3. Implement a loadout function; count how many skills and tools are exposed per role and cut the 600 skills style defaults.
4. Move contaminated or exploratory subtasks into quarantined subagents with blank history.
5. Prune obsolete tool results turn by turn, and verify the pruning respects prompt caching.
6. Run a relevance pass before summarizing, so compaction preserves what the next shift needs.
7. Audit agent prompts for repeated, capitalized instructions — they mark weight-fighting patches that need per-model tests.
8. Turn off cross-thread memory on work machines so unrelated conversations cannot merge.

None of this is a reason to ship less. The engineering win is that the levers now live in code you can test, review and roll back — the window may stay probabilistic, but the shape of the work is deterministic. The SoftwareDevelopment desk at ItInsightsWorld tracks these patterns as they land in real repos; write to contact@itinsights.com if your team wants the harness checklist applied to a project in flight.