Case packet

Neutral case identifier: case-e46581928a37b0

The possible directed relationship from Artifact A to Artifact B is under review.

Artifact A

The chat-history model trades context efficiency for implementation simplicity

The chat-history model became the default architecture for LLM applications because it is the cheapest way to preserve state without deciding in advance what the state should be. Append the next message, keep the full trace, let the model re-read everything. This buys implementation simplicity, auditability, and exploratory flexibility in one move.

That advantage is real. When the right handoff artifact is not yet known, preserving the transcript avoids premature compression. Builders do not need to define schemas, return types, or selection policies before they understand the task. Chat is a strong exploratory default.

But the property that makes chat easy to build makes it expensive to run under bounded context. The accumulated transcript is organized by time, not relevance. False starts, corrections, pleasantries, and intermediate reasoning that served its purpose three turns ago all survive into later calls. Each downstream step must re-interpret prior interaction rather than consume an artifact shaped for its own needs.

This is why mature orchestration drifts away from pure chat history even when systems begin there. Once builders understand what later stages actually need, they introduce compressed handoff artifacts, explicit return values, scoped sub-agents, or per-call prompt assembly — mechanisms that recover the context efficiency raw transcript inheritance wastes.

The contrast is not "chat is bad" versus "structured orchestration is good." It is between two optimization targets:

  • Chat history optimizes for builder convenience and maximum information preservation
  • Bounded-context orchestration optimizes for selective loading, explicit interfaces, and task-shaped artifacts

Those targets coincide early in a design, when preserving everything is safer than guessing wrong. They diverge when the bottleneck shifts from "how do I avoid losing information?" to "how do I stop re-reading the wrong information?"

The downstream claim that [session history should not be the default next context] follows from this analysis but is narrower: it argues that storage and next-context loading should be separate decisions. This note explains why they were conflated in the first place — chat won because it was easy to implement, not because it was the best architecture under context scarcity.

Relevant Notes:

Artifact B

Context efficiency is the central design concern in agent systems

In traditional systems, the scarce resources are compute, memory, storage, and bandwidth; algorithmic complexity is the dominant cost model. In agent systems, the scarce resource is context — the finite window of tokens the agent can attend to. Context differs from these in being undifferentiated: a CPU tiers registers, cache, RAM, disk, and network, whereas an LLM has one context window in which instructions, task, knowledge, and reasoning all compete for the same space.

Context is scarce for two distinct reasons, and they are different kinds of cost:

  • Feasibility — the per-window face. Within a single inference call the model's competence degrades as the window fills, by [soft degradation rather than a hard token limit]. This is a capability ceiling: past it the task becomes impossible or degrades past usefulness, at any price. It is the lowest-degree-of-freedom face — the attention budget is unitary within a call, cannot be tiered at the attention level, and cannot be enlarged without architectural change. This face also carries to the decomposed case: [under sub-agent decomposition, feasibility is the heaviest fork's net load].
  • Cost — the aggregate face. Every token processed costs money and latency, summed across all calls. This is an economic penalty — continuous rather than binary. Here context behaves like an ordinary resource: you can tier it, batch it, cache it, or simply spend more.

These rank: feasibility binds first. You can buy more tokens; you cannot buy a bigger usable window. A feasibility violation is a hard constraint — the work cannot be done — whereas a cost overrun is a soft penalty on work that can. So "context efficiency is the central design concern" is at root a claim about the binding feasibility face; aggregate cost is real but secondary. Treating the binding face first is an application of [solve low-degree-of-freedom subproblems first to avoid blocking better designs] — optimize the tightest constraint before others, or later choices are forced into low-quality tradeoffs.

Anthropic's engineering team has converged on the same framing, defining context engineering as "strategies for curating and maintaining the optimal set of tokens during LLM inference" and describing context as "a critical but finite resource" with an attention budget that "every token depletes" ([Anthropic, 2025]). Independent practitioner evidence comes from OpenAI's Codex team: shipping 1M lines of agent-generated code required a 100-line AGENTS.md acting as a router with pointers to deeper docs — "a map, not a manual." The bottleneck was not model capability but the structure of the environment, of which context structure is a central component ([Lopopolo, 2026]). Raschka reaches the same conclusion from coding-agent components: apparent model quality is largely context quality ([Raschka, 2026]).

If context is the fundamental scarce resource, the natural computational model is [symbolic scheduling over bounded LLM calls]: exact bookkeeping lives in code, while bounded context is reserved for semantic judgment. Whatever the model, context efficiency should be evaluated at design time, not retrofitted — where sub-agent boundaries go, what loads when, and what gets frontloaded determine it structurally.

Sources: - Anthropic (2025). [Effective context engineering for AI agents]. - Lopopolo (2026). [Harness engineering: leveraging Codex in an agent-first world] — independent practitioner convergence on context-as-scarce-resource from a 1M LOC agent-generated codebase. - Raschka (2026). [Components of A Coding Agent] — independent practitioner convergence: "a lot of apparent 'model quality' is really context quality."

Relevant Notes:

Under-review context phrase

bounded context makes selective loading a first-class architectural concern