Dynamic context discovery

algorithm blog-dynamic-context-discovery
context-engineeringagent-harnesstoken-efficiencyMCPfile-abstraction

Dynamic context discovery — L2 #

§1 TL;DR #

Cursor replaces static context injection with "dynamic context discovery": tool outputs, chat history, MCP tools, skills, and terminal sessions are all materialized as files on disk, letting the agent pull only what it needs via grep/read. A/B testing shows 46.9% token reduction for MCP-heavy sessions.

§2 Q1 / Q2 / Q3 #

Q1 · 痛点 #

Coding agents suffer from a context allocation problem: the agent harness must decide what to place in the finite context window before the task is known. Static inclusion creates three failure modes:

  1. Bloat — long tool responses (shell output, MCP JSON) consume thousands of tokens that the agent never references.
  2. Truncation data loss — the common mitigation (cut long outputs) discards potentially critical information (e.g., the error at the bottom of a stack trace).
  3. Summarization degradation — when context fills up, lossy summarization erases details the agent may need later but can no longer recover.
  4. MCP tool explosion — each MCP server injects its full tool schema into the prompt; multiple servers compound the overhead even though most tools go unused per turn.
  5. The problem is analogous to eager vs. lazy evaluation: static context is eager (pay the full cost upfront), while the workload is sparse (only a fraction of available context is task-relevant).

    Q2 · 方法 #

    Core mechanism: unify all ancillary context behind a single abstraction — files on the local filesystem — and let the agent decide what to read, when.

    The algorithm has five instantiations, all sharing the same lazy-load pattern:

    #Context sourceStatic (before)Dynamic (after)
    1Long tool output (shell, MCP)Full JSON/text in context, or truncatedWritten to file; agent gets path + uses tail/read on demand
    2Chat history at summarizationSummary only; details lostHistory written to file; agent searches it if summary is insufficient
    3Agent SkillsAll skill text in system promptName+description in prompt; skill file read on demand via grep/semantic search
    4MCP tool descriptionsAll tool schemas injected per serverTool names only in prompt; descriptions synced to per-server folders, read on demand
    5Terminal sessionsUser copy-pastes outputTerminal output synced to files; agent greps for relevant sections

    Design choices:

    • Per-server folders (not a flat search index) for MCP — preserves logical grouping so the agent sees a server's tools as a cohesive unit.
    • Standard file tools (rg, tail, read, jq) rather than a custom retrieval API — models already know how to use these.
    • The harness is tuned per frontier model, but the dynamic context pattern is model-agnostic.

    核心技术壁垒: The insight that files are the correct granularity for lazy context — not a search index, not a new protocol, but the filesystem itself as a universal lazy-loading interface that every LLM already knows how to navigate. The power is in the absence of new abstraction: no custom API means no adoption barrier for new models and no new failure modes to debug.

    Q3 · 结果 #

    • 46.9% token reduction in agent runs that called MCP tools (A/B tested, statistically significant, high variance depending on number of MCP servers installed).
    • Fewer unnecessary summarizations when approaching context limits (qualitative).
    • Improved response quality by reducing contradictory or confusing context (qualitative).
    • New capability: MCP server status (e.g., re-authentication needed) surfaced to the agent proactively — previously these tools silently disappeared from the agent's awareness.

    §3 Key insight diagram #

    flowchart LR subgraph STATIC["Static context (before)"] direction TB SP["System prompt"] SP --> ToolSchemas["All MCP tool schemas"] SP --> SkillText["All skill definitions"] SP --> FullOutput["Full tool output"] SP --> TermPaste["Pasted terminal logs"] ToolSchemas & SkillText & FullOutput & TermPaste --> CW1["Context window
    ⚠️ bloated"] end subgraph DYNAMIC["Dynamic context discovery (after)"] direction TB SP2["System prompt
    (minimal: names only)"] SP2 --> CW2["Context window
    ✓ lean"] FS["Filesystem"] FS --> F1["tool-output.txt"] FS --> F2["chat-history.jsonl"] FS --> F3["skills/*.md"] FS --> F4["mcp/server-name/*.json"] FS --> F5["terminals/*.txt"] CW2 -.->|"agent reads
    on demand"| FS end STATIC -->|"replaced by"| DYNAMIC

    The key structural shift: context sources move from the prompt (left) to the filesystem (right). The agent's context window holds only minimal metadata; full content is fetched lazily via standard file tools when the agent determines it is needed.

    §4 Evidence assessment #

    Evidence typeStrengthDetail
    A/B test (MCP tokens)Strong46.9% reduction, reported as statistically significant; high variance acknowledged
    Quality improvementAnecdotalClaimed reduction in confusing/contradictory context; no metric provided
    Summarization benefitAnecdotalFewer unnecessary summarizations; no quantitative comparison
    MCP status surfacingAnecdotalDescribed as a new capability; no user study
    Design choice (folders vs. flat index)Engineering judgmentJustified qualitatively (logical grouping); no A/B test of alternatives

    Overall: one solid quantitative result (MCP token reduction) backed by production A/B testing; the remaining four applications rest on engineering reasoning and qualitative observation. No formal proofs, ablation studies, or benchmark comparisons — expected for a product blog post, not a research paper.

    无形式化作者证明 — 仅实证. The blog offers no formal model of the token savings or quality tradeoffs; a formal treatment would define a context allocation policy $\pi$ that maximizes task success rate subject to a token budget $B$, and prove that the lazy policy dominates eager allocation under sparsity assumptions on tool relevance.

    §5 Practical takeaway #

    1. Default to lazy context loading in agent harnesses. Static context should be the minimum needed for the agent to discover more (names, short descriptions, file paths) — not the content itself. This is the single most actionable pattern from the blog.
      1. Use the filesystem as the universal agent memory layer. Files are model-agnostic, searchable with tools models already know (grep, tail, jq), and require no new protocol. When building MCP integrations, sync tool descriptions to per-server directories rather than injecting all schemas into the prompt.
        1. Treat summarization as recoverable, not final. When compressing context at the window limit, persist the full history as a searchable file. This turns lossy compression into a two-tier system: fast summary in-context + full history on-disk for agent-initiated recovery.