The Context Economics of Agents: Why Every 2025 Advance Was the Same Move

Anthropic published a number in November 2025 that is easy to misread as a compression result: one agent workflow dropped from 150,000 tokens to 2,000, a saving of 98.7% (Anthropic, Code execution with MCP, 4 November 2025). Nothing was compressed. The 148,000 tokens were not summarised, embedded, or quantised. They were never put in the window.

That distinction is the whole argument of this post. Somewhere between the end of 2024 and the end of 2025, the binding constraint on agent systems stopped being how well the model reasons and became how the system decides what the model is allowed to see. Four techniques arrived from four directions to address it, and read side by side they are not four ideas. They are one idea applied at four layers.

Why this matters: Agent capability now scales with what you keep out of the context window, not with what you put in it. Every architecture decision in this post trades context for something else (latency, security surface, token spend, debuggability), and getting the trade wrong produces a system that is simultaneously more expensive and less accurate than the single-prompt version it replaced.

TL;DR

• Four 2025 advances (Agent Skills, code execution with MCP, compaction and note-taking, orchestrator-worker subagents) implement one pattern at four layers: load capability lazily, keep the result out of the window.
• Tool definitions alone can force an agent to process "hundreds of thousands of tokens before reading a request." Code execution turns tool count from a prompt-size problem into a filesystem-listing problem.
• Anthropic's multi-agent research system beat single-agent Claude Opus 4 by 90.2% on their internal research eval, and used roughly 15x the tokens of a chat interaction. Token usage alone explains 80% of BrowseComp variance.
• Cognition published Don't Build Multi-Agents the day before Anthropic published its multi-agent results. Both are right; the boundary is whether subtasks write to a shared artefact.
• A subagent that spends 50,000 tokens exploring returns 1,000 to 2,000 tokens. That compression is unmatched by any summarisation prompt because the discarded material never entered the orchestrator's window.
• Compaction is not free: a compacted window is a new prefix, so it invalidates the KV cache and pays a full prefill on the next turn.
• The layers interact, mostly badly. Code execution enlarges the security surface, subagents multiply spend, compaction breaks caching, and skills add a supply-chain problem.

At a Glance

flowchart LR
    R[User request] --> W["Context window<br/>the scarce resource"]
    S["Skills<br/>name + description only"] -. level 2 on demand .-> W
    T["Tool APIs<br/>on a filesystem"] -. definition on demand .-> W
    H["History<br/>compacted or noted"] -. decisions only .-> W
    E["Subagent exploration<br/>tens of thousands of tokens"] -. 1-2k summary .-> W
    W --> O[Model call]
    O --> A[Action]
    classDef blue fill:#1e40af,stroke:#3b82f6,stroke-width:1px,color:#fff
    classDef purple fill:#6d28d9,stroke:#a78bfa,stroke-width:1px,color:#fff
    classDef teal fill:#0e7490,stroke:#22d3ee,stroke-width:1px,color:#fff
    classDef emerald fill:#047857,stroke:#34d399,stroke-width:1px,color:#fff
    class R,S,T,H,E blue
    class W purple
    class O teal
    class A emerald

Four sources of context, four dotted edges. Every dotted edge is a deferral: something large sits on the left, something small crosses into the window.

Before the Window Was the Budget

The first agent loops did not have this problem because they did not have enough capability to hit it. ReAct interleaved reasoning traces with actions against a knowledge base, using a handful of tools (Yao et al., 2022, arXiv:2210.03629). With three tools and short observations, the window is not the constraint; the model's ability to plan is.

Function calling made tools a first-class API primitive in mid-2023 and the count started climbing. The Model Context Protocol, announced 25 November 2024, made it climb much faster by removing the per-integration cost: one protocol, any compliant server, and the M×N integration problem collapses into M+N (Anthropic, 2024). By December 2025 there were more than 10,000 active public MCP servers (MCP blog, 9 December 2025).

That success created the problem this post is about. A protocol that makes connecting the two-hundredth tool as cheap as the second guarantees that someone will connect the two-hundredth tool, and every one of those definitions sat in the prompt.

timeline
    title From tool scarcity to context scarcity
    2022 : ReAct interleaves reasoning and acting over a few tools
    2023 : Function calling makes tools an API primitive; tool counts start rising
    2024 : MCP standardises tool access in November; M x N integrations collapse to M + N
    2025 : June - Anthropic reports 90.2% multi-agent gain; Cognition argues against multi-agents the day before
         : September - Anthropic names context engineering and the compaction, notes, subagent trio
         : October - Agent Skills ship progressive disclosure for instructions
         : November - Code execution with MCP cuts one workflow from 150k to 2k tokens
         : December - MCP donated to the Agentic AI Foundation with 10,000+ public servers

The pattern in that timeline is worth stating explicitly. The 2022 to 2024 entries are about acquiring capability. Every 2025 entry is about withholding it until needed.

[IMAGE: Two stacked area charts sharing an x-axis of 2022 to 2026. Top: "tools reachable per agent", rising from single digits to thousands. Bottom: "tokens of tool definition resident in the prompt", rising in step until late 2025 then dropping sharply. Caption: "The two curves tracked each other until the field decoupled them."]

The Four Layers of Deferral

Each layer holds a different kind of thing outside the window, and each pays a different price for the privilege.

Layer 1: instructions, via Agent Skills

An agent that knows four specialised procedures pays for all four on every request if they live in the system prompt. Agent Skills, announced 16 October 2025, make capability a directory instead: a SKILL.md file plus scripts, templates and reference documents.

The loading is layered (Anthropic, Equipping agents for the real world with Agent Skills):

1. At startup the agent pre-loads only the name and description of every installed skill into its system prompt.
2. If it judges a skill relevant, it reads the full SKILL.md.
3. SKILL.md may reference bundled files, which the agent navigates and discovers only as needed.

The economics: a hundred available skills cost roughly the size of an index, not a library. The load-bearing part is the description, because level 1 is the only information the agent has when deciding whether to pay for level 2. Selection here is the model's judgement, not a ranked similarity search, so there is no relevance score to inspect when it picks wrong.

The cost is a supply chain. A skill is instructions plus code the agent may execute with the agent's own credentials, and progressive disclosure means the interesting content may sit at level 3, invisible until a specific branch loads it.

Layer 2: tools, via code execution

Direct tool calling imposes two bills. The first is the definitions, resident from token zero; Anthropic's phrasing is that agents can end up "processing hundreds of thousands of tokens before reading a request." The second is subtler and usually larger: every intermediate result round-trips through the model. Fetch a two-hour meeting transcript to copy into a CRM and it enters the window once as a tool result and leaves once as a tool argument, which Anthropic puts at roughly 50,000 extra tokens for that single document.

The alternative is to present each MCP server as a code API on a filesystem and let the agent write a program:

const transcript = await gdrive.getDocument({ documentId: id });
const pricing = transcript.text
  .split("\n")
  .filter(line => /pricing|discount|renewal/i.test(line));
await salesforce.updateRecord({ id: account, notes: pricing.join("\n") });
console.log(pricing.length + " pricing mentions logged for " + account);

The transcript never enters the window. One line of output does.

Five things follow, and they are not all the same kind of win. Progressive disclosure of tool definitions, filtering of results before the model reads them, and control flow expressed as loops rather than as one model round trip per iteration are all cost reductions. State persistence in the sandbox is a convenience. Privacy-preserving intermediate values are a capability change: data can move between systems, tokenised or redacted, without the model ever seeing it, which makes a workflow possible rather than merely cheaper.

The price is stated plainly in the same article: running model-generated code "requires a secure execution environment with appropriate sandboxing, resource limits, and monitoring", adding "operational overhead and security considerations that direct tool calls avoid." Direct tool calling has an enumerable action space, because every possible call is a tool an operator registered. Code execution has an action space bounded only by the sandbox. That is a strictly harder security question.

Layer 3: history, via compaction and notes

Anthropic named the discipline in September 2025 and gave it three techniques (Effective context engineering for AI agents, 29 September 2025).

Compaction summarises a conversation approaching the limit and reinitialises a new window from the summary. The Claude Code policy is specific about what survives: the model "preserves architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs", continuing with the compressed context plus the five most recently accessed files.

The selection rule generalises. Compress hard on anything the agent can re-derive; compress not at all on anything it cannot. A file's contents are worth ten tokens as a pointer and four thousand as text. The reason a decision was made is thirty tokens that prevent a hundred turns of rediscovery.

Structured note-taking writes state to persistent files outside the window. The example given is Claude playing Pokémon, maintaining precise tallies across thousands of game steps, tracking states like "for the last 1,234 steps I've been training my Pokémon in Route 1" without being prompted to keep a memory.

Both have a cost that rarely appears in the discussion: a compacted window is a new prefix. The KV cache accumulated over the old conversation is gone, the next turn pays a full prefill on the summary, and every subsequent turn loses cache hits it would otherwise have had. Compaction triggered often on a long session can cost more in prefill than it saved in tokens.

Layer 4: exploration, via subagents

The fourth deferral is the largest and the most contested. A subagent runs its own loop in its own window and returns a summary. Anthropic's figure: a subagent "might explore extensively, using tens of thousands of tokens or more, but returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens)."

No summarisation prompt achieves that ratio, because the discarded material never entered the orchestrator's window. This is context isolation wearing compression's clothes.

flowchart TB
    subgraph direct["Direct tool calling"]
        D1[Model] -->|call| D2[Tool]
        D2 -->|full result| D1
        D1 -->|full result as argument| D3[Second tool]
    end
    subgraph deferred["Deferred execution"]
        E1[Model] -->|writes program| E2[Sandbox]
        E2 --> E3[Tool A]
        E2 --> E4[Tool B]
        E2 -->|printed summary only| E1
    end
    classDef purple fill:#6d28d9,stroke:#a78bfa,stroke-width:1px,color:#fff
    classDef slate fill:#334155,stroke:#64748b,stroke-width:1px,color:#e2e8f0
    classDef teal fill:#0e7490,stroke:#22d3ee,stroke-width:1px,color:#fff
    class D1,E1 purple
    class D2,D3,E3,E4 slate
    class E2 teal

Seeing It in Motion

The order of operations matters more than the box diagram suggests, particularly for who pays what.

sequenceDiagram
    participant U as User
    participant O as Orchestrator
    participant S as Skill index
    participant X as Sandbox
    participant W as Worker agent
    U->>O: Task
    O->>S: Match on name and description
    S-->>O: Load one SKILL.md
    O->>X: Write and run program
    X->>X: Fetch, filter, transform
    X-->>O: 1 line of output
    O->>W: Delegate independent lookup
    Note over W: Explores in its own window,<br/>tens of thousands of tokens
    W-->>O: 1500 token summary
    O-->>U: Answer

Every arrow pointing back at the orchestrator is deliberately thin. That is the design.

For a long-running agent the same picture has a time axis, and the interesting states are the ones where the run is not executing anything at all.

stateDiagram-v2
    [*] --> Planning
    Planning --> Executing
    Executing --> Executing: tool call
    Executing --> Compacting: window near limit
    Compacting --> Executing: new prefix, cache cold
    Executing --> Awaiting: approval required
    Awaiting --> Executing: resume from checkpoint
    Executing --> Failed: crash or API error
    Failed --> Executing: resume from checkpoint
    Executing --> [*]: done

Compacting, Awaiting and Failed all resume by rebuilding a window from persisted state. That is why durable execution and context management are the same engineering problem seen from two sides: a checkpoint that stores the compacted window rather than the raw history makes a bad compaction permanent.

[IMAGE: Horizontal timeline of one 40-step agent run, with a stacked bar at each step showing window composition (system prompt, tool definitions, history, current tool result). Mark the compaction boundary at step 26 where the bar collapses and a new prefill cost spike is annotated below the axis. Caption: "The window empties at step 26 and the latency graph spikes at step 27. Both are the same event."]

By the Numbers

Sources: Anthropic engineering, multi-agent research system, context engineering, MCP blog, Kwa et al., METR. Every figure above is a vendor-reported or author-reported measurement on their own evaluation, not an independent benchmark. The 90.2% in particular is an internal research eval, and the 4x and 15x multipliers are stated as approximations.

A Concrete Example

Task: "For every account with a call recorded in the last 30 days, find the calls where pricing was discussed and add a note to the Salesforce record."

Assume 12 accounts, one call each, transcripts averaging 18,000 tokens, and an agent connected to 9 MCP servers exposing 140 tools whose definitions total 96,000 tokens. All figures below are illustrative arithmetic on those stated assumptions, not measurements.

Configuration A: direct tool calling.

1. Tool definitions load: 96,000 tokens before the request is read.
2. listCalls returns 12 call IDs: ~400 tokens.
3. For each call, getTranscript returns 18,000 tokens into the window. After 5 calls: 96,000 + 400 + 90,000 = 186,400 tokens.
4. Each updateRecord call passes the extracted lines back as an argument: ~600 tokens each.
5. At call 7 the window passes 200,000 tokens. The run either truncates, compacts, or fails.

Total if it completed: roughly 96,000 + 400 + (12 × 18,000) + (12 × 600) ≈ 319,600 tokens, of which 216,000 is transcript text the model reads once and uses for a regex-shaped filter.

Configuration B: code execution.

1. Agent lists servers/: ~150 tokens.
2. Reads three tool definitions it needs (listCalls, getTranscript, updateRecord): ~1,300 tokens.
3. Writes a 14-line program: ~400 tokens generated.
4. The sandbox runs the loop. All 216,000 tokens of transcript are read by the program, never by the model.
5. Program prints one line per account: 12 × ~25 tokens = 300 tokens.

Total through the model: roughly 150 + 1,300 + 400 + 300 ≈ 2,150 tokens. The ratio to configuration A is about 149:1, which is the same order as the 98.7% Anthropic reports, arrived at from independent assumptions.

Configuration C: subagents.

Spawn 12 workers, one per account. Each reads its transcript (18,000 tokens) in its own window and returns a 120-token verdict. Orchestrator cost: 12 × 120 = 1,440 tokens, comparable to B. System-wide cost: 12 × ~20,000 = 240,000 tokens, roughly 100x configuration B.

The lesson is not that subagents are wasteful. It is that B and C look identical from the orchestrator's window and differ by two orders of magnitude in spend, so the orchestrator's context size is not a proxy for cost. Choose C when the per-item work needs judgement (does this call discuss pricing in a way a regex would miss?) and B when it does not.

[IMAGE: Grouped bar chart with three configurations on the x-axis and two bars each: "tokens through the orchestrator" and "tokens across the whole system", on a log y-axis. Configuration B and C have nearly identical left bars and left bars differing by 100x on the right. Caption: "Two architectures, the same orchestrator context, a hundredfold difference in bill."]

Where It Breaks

Compaction and caching pull in opposite directions

Every serving optimisation of the last three years rewards a stable prefix. Prompt caching, prefix-aware routing, and radix-tree cache reuse all depend on the front of the window not changing. Compaction changes the entire front of the window by design. An agent tuned for cache hit rate and an agent tuned for window occupancy are being tuned against each other, and nobody publishes the joint optimum because it depends on the session length distribution.

The action space stops being enumerable

Under direct tool calling, an auditor can answer "what could this agent have done?" by listing registered tools. Under code execution the answer is "anything the sandbox permits", and sandbox escape is a mature attacker discipline with decades of prior art. The mitigation is not novel (network egress rules, filesystem scoping, resource limits, syscall filtering) but it is infrastructure that most agent deployments do not have, and the token savings are usually what motivates adopting it before the security work is done.

Subagents disagree without knowing it

Cognition's objection is the most substantive counterargument in this space and it is not about cost (Yan, Don't Build Multi-Agents, 12 June 2025). Their two principles: "Share context, and share full agent traces, not just individual messages", and "Actions carry implicit decisions, and conflicting decisions carry bad results." The example is a Flappy Bird clone where one subagent renders a Super Mario-style background while another builds a bird with mismatched physics; no downstream agent can reconcile them, because neither one's reasoning was ever visible to the other.

Anthropic's own guidance draws the same boundary from the other side: domains "that require all agents to share the same context or involve many dependencies between agents are not a good fit", explicitly including most coding tasks.

The synthesis: subagents are safe on read-only, independent, individually verifiable subtasks and unsafe on anything that writes to a shared artefact, because a write encodes a decision and isolated context means the decision is never shared.

The summary drops what the orchestrator did not know to ask for

A subagent optimises its summary against the instruction it received. Information that would have changed the orchestrator's plan (a contradiction between two sources, a cheaper path found and rejected, an assumption that turned out false) is the most likely thing to be omitted, and the orchestrator has no trace with which to recover it.

Skill descriptions collide silently

Two skills whose descriptions overlap produce non-deterministic selection that is not stable across model versions. There is no error, no log line, and no relevance score. The only signal is that the agent occasionally does the task the wrong way.

Error compounds across every boundary

Agents are stateful and errors compound; a subagent that misreads its instruction burns its whole budget on the wrong interpretation and returns a confident, wrong summary. Compaction has the same property across time: each compaction summarises a context that already contains a summary, so three boundaries in, the agent works from a summary of a summary of a summary with no surviving source to check against.

Retries multiply at two layers

An agent runtime that resumes automatically on failure will faithfully retry the step that crashed the process. The agent can also decide to retry from inside its own reasoning. Neither layer knows about the other's counter, so a bounded runtime retry policy still permits an unbounded model-driven one.

Alternative Designs

The single-threaded row is Cognition's recommendation, and it is worth stating in their terms rather than as a strawman: for lengthy tasks that risk context overflow they propose introducing "a new LLM model whose key purpose is to compress a history of actions & conversation into key details, events, and decisions", potentially fine-tuned for the domain. That is a claim that general summarisation is not good enough, which is a much stronger and more falsifiable position than "compaction is hard".

How It Is Used in Practice

Production agent stacks in 2026 tend to run all four layers, and the interesting engineering is in the interfaces between them.

Coding agents lean on layers 1 and 3 and largely refuse layer 4 for edits: skills for repo-specific conventions, compaction for long sessions, subagents only for read-only exploration such as searching for where a symbol is defined. This maps exactly onto the shared-artefact rule.

Research and analysis agents invert it, leaning hard on layer 4 because their subtasks are naturally read-only. This is where the 15x token multiplier is worth paying, and it is the setting Anthropic measured.

Enterprise integration agents care most about layer 2, and often for the reason that is not about cost. The ability to move records between two systems without the contents entering the model's context is a data-residency and PII argument that a compliance team can act on, and it wins budget that a token-savings argument does not.

Across all three, the operational lesson is that the four layers need shared instrumentation. Tokens through the orchestrator, tokens across the system, cache hit rate, compaction frequency and per-step attempt counts are five numbers that look independent and are not. The worked example above exists to show that two of them can move in opposite directions while the system gets worse.

[IMAGE: System diagram of a production agent stack: skill registry feeding an orchestrator; orchestrator connected to a sandbox runtime and to a worker pool; a checkpoint store beneath both; a KV cache and gateway layer to the left. Annotate each edge with the metric that should be monitored across it. Caption: "Five metrics, one system. Optimising any of them alone degrades at least one other."]

Insights Worth Remembering

1. Compression and isolation are not the same thing, and isolation wins. A summarisation prompt operating on 50,000 tokens in the window has already paid for those tokens. A subagent that never let them into the orchestrator's window paid nothing. The dominant technique in each of the four layers is the one that avoids the read, not the one that shortens it.

2. The orchestrator's context size is not a proxy for cost. Configurations B and C in the worked example look identical from the orchestrator and differ by roughly 100x in system-wide spend. Any dashboard that shows only main-loop tokens will report the expensive architecture as the cheap one.

3. Tool result size is a bigger problem than tool count. Definition bloat is the visible cost and it is bounded by how many tools you registered. Result round-tripping is unbounded, scales with the data, and doubles because a result usually becomes an argument.

4. The description field is the most consequential line in an agent system. For skills it decides whether the procedure ever loads. For A2A Agent Cards it decides whether the peer is ever selected. In both cases selection is the model's judgement rather than a scored retrieval, so there is nothing to tune afterwards.

5. Every deferral moves work somewhere with weaker guarantees. Instructions move to a supply chain, tools move to a sandbox, history moves to a summariser, exploration moves to an agent with no shared trace. The window gets smaller and the number of places a failure can hide gets larger.

6. Multi-agent results and anti-multi-agent results are both correct and describe different tasks. The distinguishing variable is whether subtasks write to a shared artefact. Read-only parallel research: 90.2% better. Shared-artefact construction: conflicting implicit decisions with nothing downstream able to reconcile them.

7. Compaction is a serving decision, not just a context decision. It invalidates the KV cache, so its threshold interacts with prefix caching, routing and cost per turn. Tuning it purely against window occupancy optimises one of the two variables it controls.

8. Durability and context management are one problem. Compaction, approval gates and crash recovery all resume by rebuilding a window from persisted state. Persist raw and compact for the model, or a lossy summary becomes permanent.

Open Questions

Does the 80% variance result mean architecture matters, or only that spend matters? Measured: on BrowseComp, token usage alone explains 80% of performance variance in Anthropic's analysis. Not established: whether a single agent given the same budget through longer trajectories would close the gap. Until someone runs the token-matched comparison, the multi-agent result and the spend result are confounded.

What is the right size for a compaction, and can it be learned? Cognition's position is that a purpose-trained compressor beats general summarisation for agent histories. That is testable and, as of mid-2026, not publicly tested at scale. The metric would have to be downstream task success after N compactions, not summary quality.

Can code-execution sandboxes be made auditable enough for regulated deployment? The security requirements are known and mature. What does not exist is a standard attestation that says "this agent's action space was bounded to X" in a form an auditor accepts, which is exactly what a registered tool list provided for free.

Does progressive disclosure survive adversarial skills? A skill's level-3 files are loaded only on specific branches, so review of the visible SKILL.md is not review of the skill. Whether static analysis or signing can close this without destroying the ergonomics is an open engineering question.

Where does the time-horizon curve actually bind? METR measures a 50% task-completion time horizon doubling roughly every seven months, reaching around 50 minutes for Claude 3.7 Sonnet (Kwa et al., arXiv:2503.14499). Whether that curve is driven by model capability, by context-management engineering of the kind described here, or by both in some fixed ratio is not separated by any current measurement, and it matters because the two have very different cost curves.

Sources and Further Reading

Primary engineering sources

1. Anthropic (2025). "Code execution with MCP: building more efficient agents." Published 4 November 2025. anthropic.com/engineering/code-execution-with-mcp
2. Anthropic (2025). "Effective context engineering for AI agents." Published 29 September 2025. anthropic.com/engineering/effective-context-engineering-for-ai-agents
3. Anthropic (2025). "Equipping agents for the real world with Agent Skills." Published 16 October 2025. anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
4. Anthropic (2025). "How we built our multi-agent research system." Published 13 June 2025. anthropic.com/engineering/multi-agent-research-system
5. Yan, W. (2025). "Don't Build Multi-Agents." Cognition, 12 June 2025. cognition.com/blog/dont-build-multi-agents

Protocols and governance

6. Anthropic (2024). "Introducing the Model Context Protocol." Published 25 November 2024. anthropic.com/news/model-context-protocol
7. Model Context Protocol (2025). "MCP joins the Agentic AI Foundation." Published 9 December 2025. blog.modelcontextprotocol.io
8. Google Developers Blog (2025). "Google Cloud donates A2A to Linux Foundation." Published 23 June 2025. developers.googleblog.com
9. Agent2Agent Protocol Specification. a2a-protocol.org/latest/specification

Research papers

10. Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2022). "ReAct: Synergizing Reasoning and Acting in Language Models." arXiv:2210.03629
11. Kwa, T., West, B., Becker, J., et al. (2025). "Measuring AI Ability to Complete Long Software Tasks." METR. arXiv:2503.14499
12. Chen, S., Wong, S., Chen, L., & Tian, Y. (2023). "Extending Context Window of Large Language Models via Positional Interpolation." arXiv:2306.15595

Related concepts in this library

13. Agent Skills and Progressive Disclosure
14. Code Execution as a Tool Interface
15. Orchestrator-Worker Subagent Architectures
16. Context Compaction and Handoff
17. Durable Agent Execution and Recovery
18. Agent-to-Agent Interoperability

Free to read, no ads, no sign-up. If it was useful you can buy me a coffee.