The smallest set of high-signal tokens.
A latticework reading of Anthropic's essay on context engineering — how the discipline of curating what an AI agent sees at each turn illuminates, challenges, and extends the Farnam Street canon.
A latticework reading of Anthropic's essay on context engineering — how the discipline of curating what an AI agent sees at each turn illuminates, challenges, and extends the Farnam Street canon.
Anthropic Engineering · anthropic.com/engineering
Prompt engineering is about what you say. Context engineering is about what you show. Anthropic's September 2025 essay draws this distinction sharply and then spends several thousand words working out what it implies for building AI agents that don't degrade over time. The practical advice is useful. The latticework reading finds something more interesting underneath: context engineering is really a problem in attention allocation, which is one of the central problems in human cognition that the Farnam Street canon was built to address.
The essay introduces three levels of curation. At the static level: what goes in the system prompt, how tools are defined, which few-shot examples are selected. At the runtime level: which documents are loaded now versus fetched on demand. At the long-horizon level: how a conversation's history is compacted, noted, or delegated as a task stretches beyond a single context window. Each level has a corresponding Farnam Street model that gets either amplified or challenged by the engineering constraints Anthropic's team describes.
What follows reads the essay's three practical sections against the canon, then names two new models the engineering practice introduces.
The most direct reinforcement is of attention as a finite resource. The Farnam Street treatment of attention focuses on human cognitive bandwidth — the idea that attention is scarce and its allocation determines outcomes. Context engineering makes the same claim in a different substrate: transformer attention is literally quadratic in token count, which means that adding tokens is not free, and that a well-curated context window produces qualitatively better reasoning than a stuffed one. The engineering constraint turns the mental model into a physical law: attention costs n², and the returns on the marginal token decline as the window fills.
Minimum effective dose — the principle that the right amount of an input is the smallest amount that achieves the desired effect — is at the heart of the essay's system-prompt advice. The authors argue that system prompts should be "specific enough to guide behavior effectively, yet flexible enough to provide strong heuristics rather than brittle if-else logic." Too little → underconstrained behaviour. Too much → competing instructions, brittleness, and the cognitive overhead of a model processing irrelevant rules. The minimum effective dose is what survives that compression.
The just-in-time retrieval section reinforces inversion as a design principle. Rather than asking "what might the agent need?" and loading it all upfront, the engineering question is inverted: "what can the agent fetch on demand?" Loading a document identifier rather than the document itself is the inversion move — and it mirrors human cognition, where we don't carry every relevant memory in working memory but maintain lightweight pointers to them. The cost of retrieval is paid only when retrieval is actually required.
The standard account of more information is better — which underlies most information-gathering instincts — takes a direct hit from the context-rot finding. In typical decision-making, more data reduces uncertainty. In context engineering, more tokens past a certain density reduce performance by diluting the signal-to-noise ratio of the attention computation. The engineering practice doesn't just argue for parsimony on grounds of efficiency; it argues that excessive context actively degrades the quality of the output. More is worse. The counterintuitive inversion: curating what the agent does not see is part of the engineering work, not an afterthought.
The conventional mental model of comprehensive documentation — the instinct that thorough instructions prevent failure — bends similarly. The essay's advice on system prompts is that brittle if-else logic encoded in natural language fails in ways that flexible heuristics don't. A system prompt that tries to enumerate every case creates a document that is both long (filling valuable context) and fragile (any case the author didn't anticipate falls through). The better design is a set of principles that generalise. This is the same argument Farnam Street makes against checklists that substitute for judgment — but the essay extends it to the instructions themselves.
Finally, the essay complicates the standard account of delegation in hierarchical organisation. The naive model says: delegate clearly, monitor output, correct on deviation. Context engineering adds a constraint: each sub-agent receives a summary, not a full transcript, because full transcripts are too token-expensive. The delegation must be designed so that summaries carry enough signal. This is a non-trivial constraint that changes how you structure the original task decomposition — not just how you communicate results.
The most generalisable new model the essay introduces is Context Rot: the phenomenon by which adding more information to a bounded, attention-based system degrades the quality of its output past a certain density. The mechanism is specific to transformer architectures, but the pattern generalises: any system that processes information through bounded attention — a meeting, a document review, a committee deliberation — will exhibit some version of this. The signal-to-noise ratio of what is presented is more important than the quantity. Context rot is the name for what happens when the ratio degrades. Recognising it suggests a design principle: the goal is not completeness but density.
The second new model is Just-in-Time Retrieval as an architectural principle. The essay distinguishes between loading information into the context at the start of a task versus fetching it dynamically during execution. The JIT version is cheaper in tokens and more accurate in targeting: you fetch exactly what the current sub-task requires, rather than guessing upfront what everything might require. Generalised: any process where information requirements are heterogeneous across stages benefits from deferred loading rather than front-loaded completeness. The human analogue is the difference between reading a whole book before a meeting versus looking up the relevant chapter when the question arises.
The third is the Compaction-Continuity Trade-off. Long-horizon tasks that exceed a context window must be summarised and restarted. The summary preserves continuity but loses granularity. How much granularity you can afford to lose without disrupting the next stage of the task is a non-obvious design question. This trade-off doesn't have a standard name in the latticework, but it appears in many domains: meeting minutes that lose the nuance of a three-hour discussion; a handoff summary that drops the edge cases; a distillation that compresses the reasoning chain. The engineering practice makes the trade-off explicit and names the design objective: preserve what the next inference turn actually needs, not everything that happened.
The Farnam Street canon has always been about attention — about directing finite cognitive resources toward the highest-value inputs. Context engineering is that same problem, made explicit in a substrate where the cost function is visible. The n² attention complexity is not a metaphor; it is a measurement. The engineering practice turns "be selective about what you pay attention to" from wisdom into an architectural requirement.
Context is a critical but finite resource — the smallest set of high-signal tokens that maximize your desired outcome. — Anthropic Engineering, Sep 2025
The useful carry: whenever you are designing a process that involves information passing through a bounded processor — a model, a person, a committee — the first design question is not "what information should be available?" but "what is the minimum high-signal set that maximises the outcome?" Completeness is the wrong objective. Density is the right one. The essay says this clearly about context windows. The latticework says it should apply everywhere else too.