The InfoQ presentation The Right 300 Tokens Beat 100k Noisy Ones: The Architecture of Context Engineering argues that many coding-agent failures are not model problems at all, but context problems. In the talk, Baruch Sadogursky and Patrick Debois show how stuffed prompts, poor retrieval, black-box memory and “vibe” evaluations can derail agentic workflows — and how a more disciplined approach to context engineering can improve results dramatically.
Why coding agents fail when context gets bloated
The presenters opened with a simple demo: feed a coding agent a large CLAUDE.md packed with project knowledge, then ask it to add error handling to an endpoint. The result looked plausible at first, but the test still failed, returning a 500 instead of the expected 404. Their point was not that the model was unusable, but that piling everything into one prompt creates contradictions and overload.
Debois explained that the model’s context window includes far more than the user’s latest request. The system prompt, the chat history, the agent’s own replies and any pasted logs all count. Even small interactions eventually crowd out useful information, and the agent can lose track of details buried near the end of the window.
The stuffed prompt problem in context engineering
One of the main themes of the talk was the difference between prompt engineering and context engineering. Prompt engineering focuses on crafting the right instruction; context engineering treats the entire surrounding information set as an architecture problem.
That distinction matters because the failure mode is often not a bad prompt, but too much irrelevant, stale or conflicting information. Sadogursky and Debois repeatedly returned to the same lesson: the agent does better when it receives the smallest useful slice of context, not a giant pile of everything the team has ever written.
Skills as lazy-loaded context
The first fix they highlighted was the move from stuffed prompts to skills. Instead of placing all documentation in a single always-loaded file, skills are loaded only when trigger words or descriptions indicate they are relevant. In the demo, that meant a skill for error handling could be activated only when needed, rather than injected into every interaction.
That lazy-loading approach reduces noise and helps avoid conflicting instructions. The speakers also stressed that the skill description is critical: the agent uses that description to decide whether to load the skill, so “copy-paste the title and move on” is not enough.
Why versioned artifacts beat random markdown files
The talk also pushed back on the idea that context files are just text files. Sadogursky argued that once a skill is shared, distributed, reused and updated, it behaves more like an artifact than a source file. In that sense, it belongs closer to package management than to ad hoc documentation.
They made the same argument for versioning and distribution. If a team needs to know whether a skill is current, private or meant for an entire organization, then treating it like a managed artifact is more practical than stuffing it into GitHub and hoping people know what to do with it.
- Version the context artifact so users know which behavior they are getting.
- Package it for reuse across projects, teams or agents.
- Keep the instructions and best practices aligned as the artifact evolves.
Right tool, right channel: RAG, web search and rules
The second major antipattern was choosing the wrong retrieval path. The presenters demonstrated a RAG setup that found documentation with a high relevance score, then still picked the wrong version of a library. Their point was blunt: similarity is not the same as correctness.
They compared several context channels, including database search, web search, versioned documentation and rules. RAG can help when the corpus is well curated, but it can also miss the right chunk or surface the wrong version. Web search is useful for current information, but can be noisy or outdated. Rules, meanwhile, are always-on guidance that can be appended by the IDE or agent.
MCP is plumbing, not the strategy
Much of that tooling can be exposed through Model Context Protocol, but the speakers were careful to frame MCP as a connector rather than a magic solution. MCP can carry semantic search, grep-style lookup or other retrieval methods. The real question is not whether MCP exists, but which kind of context should be delivered through it.
They also noted a practical downside: tool descriptions themselves can bloat context. If every MCP tool comes with a long description, the agent can blow through its window even faster than before.
The goldfish agent and the problem with hidden memory
The third antipattern was what the presenters called the “goldfish agent”: one that forgets too quickly, while relying on memory systems the user cannot inspect. They pointed to built-in memory and compaction as black boxes. A session may summarize or discard context automatically, but the user does not always know what was kept or why.
To counter that, they proposed writing key decisions into explicit memory artifacts. In the demo, architectural decisions were stored in a .memory/decisions file with a clear schema. Rules then told the agent to save decisions there and reload them later when a new session needed the background.
That approach makes the memory visible, inspectable and repeatable. It also reduces dependence on opaque compaction logic that may remove the very detail a later prompt needs.
Why evals matter more than vibes
The final section of the talk moved from generation to evaluation. The presenters described “vibe checks” — the informal habit of judging whether an agent seems better after a change — and contrasted that with actual evals. In their view, AI systems need structured evaluation just as much as they need structured prompts.
They described using an LLM-as-a-judge approach, where one model scores outputs against a rubric. That introduces its own overhead, because teams now have to design both the generation prompt and the evaluator prompt. But it also creates a feedback loop that is far more reliable than gut feel.
The payoff: 35% to 98%
The clearest result in the presentation came from their pidge notification library example. Without context, the agent achieved 35% correctness, largely because the library was custom and the model had little basis for understanding it. With skills, docs and rules packaged together as a context artifact, correctness rose to 98%.
That gap was the presentation’s strongest argument. The speakers were not claiming that context engineering replaces model quality, but that good models still need good context boundaries, retrieval and evaluation. In their framing, the right 300 tokens can matter more than 100,000 noisy ones.
What software teams should take from the talk
The presentation’s takeaway is that context is not a dumping ground. It is a system design problem, with reusable components, explicit retrieval paths and testable outcomes. For software architects and engineering leaders, that means thinking about agent behavior the way they already think about application architecture.
- Keep prompts small and targeted.
- Load context lazily when it is relevant.
- Package best practices as versioned artifacts.
- Use the right retrieval method for the job.
- Make memory explicit when possible.
- Back changes with evals, not vibes.
Seen that way, context engineering is less about clever prompting and more about designing a system that can consistently find, load and use the right information at the right time.
Source: Original report
Was this helpful?
Explore more: AI Automation Services More Software Development Tech News
Last Modified: August 16, 2026 at 1:53 am
3 views
