Dynamic Context Discovery: The Next Paradigm for Coding Agents

Core Argument: Cursor’s concept of “dynamic context discovery” represents a paradigm shift—from stuffing all context into a context window to allowing agents to pull context as needed. This transition addresses not only token efficiency but also the “quality of context”: less but more precise information actually enhances agent performance.

1. The Core Dilemma of the Old Paradigm: The Collapse of Static Context

Traditional context engineering is based on the assumption that more context = better agent performance. This assumption held true in 2024 when model capabilities and context windows were relatively limited. However, by 2026, things changed:

Larger context windows but no increase in information density: Models can read 200K tokens, but noise (outdated logs, irrelevant file versions, intermediate products of historical operations) can also be included.
Context bloat from third-party tools: The JSON returned by MCP calls can be larger than the core code you are editing, but agents cannot distinguish between primary and secondary information.
Irreversible loss from summarization: When the context is full, existing systems can only compress—but compression is lossy, leading to the loss of critical details and task failures.

Official Quote: “The common approach coding agents take is to truncate long shell commands or MCP results. This can lead to data loss, which could include important information you wanted in the context.” — Cursor Blog: Dynamic context discovery

Fundamental Flaw of Static Context: It assumes that all information is known for its value at the time of injection, but in reality, the value of information depends on the current stage of the task—the same test output is core context during the “writing tests” phase but noise during the “writing business logic” phase.

2. Core Mechanism of Dynamic Context Discovery

Cursor’s solution is file systemization: converting tool outputs, chat histories, and MCP tool descriptions into files, allowing agents to pull as needed using grep/tail/read.

2.1 File-based Long Tool Responses

Old Model: tool_call → JSON 200KB fully stuffed into context
New Model: tool_call → write to /tmp/tool_output_xxx.json → agent reads on demand using tail/read

Effect: Reduces unnecessary summarization triggers. Internal testing at Cursor shows that this change significantly decreases summarization calls after the context is full.

2.2 File-based References to Chat History

When the context window is full, Cursor provides the agent with a “reference to the history file” instead of forcing it to compress. If the agent finds that the summary lacks critical details, it can grep the history file to recover them.

Official Quote: “After the context window limit is reached, or the user decides to summarize manually, we give the agent a reference to the history file. If the agent knows that it needs more details that are missing from the summary, it can search through the history to recover them.” — Cursor Blog: Dynamic context discovery

Insight Behind This Design: Summarization is a subjective decision made by the system for the agent—the system deems this history “unimportant” and compresses it, but this judgment may conflict with the agent’s current task needs. Allowing the agent to decide what to pull returns decision-making power to it.

2.3 Dynamic Loading of MCP Tools

This is the most significant optimization: In A/B testing, agents using dynamic MCP loading reduced total token consumption by 46.9% when calling MCP tools.

Traditional Model: All tool definitions and descriptions from the MCP server → fully stuffed into the system prompt. Dynamic Model: Only the list of tool names + instructions to “grep when needed”.

Official Quote: “We believe it’s the responsibility of the coding agents to reduce context usage. In Cursor, we support dynamic context discovery for MCP by syncing tool descriptions to a folder.” — Cursor Blog: Dynamic context discovery

Cursor also implemented an additional design: the folder structure remains grouped by server rather than a flat index. This way, the agent sees a cohesive unit (“all tools of this server”) instead of scattered tool descriptions.

2.4 File Systemization of Terminal Sessions

Cursor synchronizes the output of integrated terminals to the local file system, allowing agents to grep specific outputs directly without needing to copy/paste. This aligns the context sources of Cursor agents and CLI-based agents (like Claude Code)—historical shell outputs are exposed through the file system, with CLI agents using static injection and Cursor using dynamic pulling.

3. Why This Transition is Effective: An Information Theory Perspective

Dynamic context discovery is effective because good context is not about “more” context, but about context with a high signal-to-noise ratio. When the agent’s context window is filled with “all potentially relevant information,” it faces an information retrieval burden—it must sift through a lot of noise to find truly relevant information. When the context window is filled with “information directly related to the current task,” the agent’s reasoning resources can be fully devoted to the task itself.

Cognitive Load Theory also supports this conclusion: giving the model fewer distractions actually enhances its ability to handle core issues—this is consistent with the phenomenon where human experts work more efficiently on a “tidy desk”.

4. Applicable Boundaries and Limitations

Dynamic context discovery is not suitable for what scenarios:

First-time cold starts: When the agent has not established a sufficient problem model and does not know what to pull, dynamic discovery may increase ineffective searches.
Tasks with extremely high real-time requirements: For example, monitoring alerts or real-time interactions, the I/O overhead of grepping files may be unacceptable.
Hidden dependencies between contexts: If the relationship between file A and file B is “understanding B requires knowing A,” but the agent sees B first, dynamic discovery may lead it into a dead end.

Limitations of File Abstraction:

Official Quote: “It’s not clear if files will be the final interface for LLM-based tools.” — Cursor Blog: Dynamic context discovery

Cursor acknowledges that files are merely a “currently simple yet powerful primitive” and may not be the final form. For instance, structured search (like vector retrieval) may be more suitable for semantically relevant context pulling than grep.

5. Engineering Practice Recommendations

How to Implement Dynamic Context Discovery in Your Agent

Minimum Viable Implementation (3 Steps):

Step 1: File-based Tool Responses
- Write all tool responses >10KB to /tmp/context/{uuid}.json
- Add to the agent system prompt: ">10KB tool outputs are stored in /tmp/context/ — use tail/read to access"

Step 2: References to Chat History Summaries
- Retain the complete history file path with each summarization
- Allow the agent to use grep to recover critical details missing from the summary

Step 3: On-demand Loading of MCP Tools
- Only include the list of tool names in the system prompt
- Provide a "lookup_mcp_tools(query)" tool for the agent to actively search for needed tools

Metrics to Detect the Effectiveness of Dynamic Context:

Frequency of summarization calls (should decrease)
Task completion rates (cross-session tasks should improve)
Distribution of the agent’s grep/read calls (should be concentrated in your expected workflows)

6. Comparison with Other Solutions

Solution	Context Organization Method	Advantages	Disadvantages
Static Context (Traditional)	All stuffed into context window	Simple, agent does not need to search actively	200K tokens limit, low signal-to-noise ratio
Dynamic Context Discovery (Cursor)	Files pulled on demand	46.9% reduction in tokens, agent makes autonomous decisions	Requires tool-level modifications, I/O overhead
Hierarchical Memory (LangChain)	Hierarchical compression + retrieval	System controls quality, interpretable	Compression loss is inevitable, retrieval quality depends on embedding models
Context Caching (OpenAI)	KV Cache reuse	Same prefix calculated only once	Only suitable for “shared prefix” scenarios, not for dynamic content

Author’s Judgment: Dynamic context discovery represents a shift in context engineering from a “system-centered” to an “agent-centered” approach. Future mainstream architectures are likely to be hybrid: static injection of “meta-context” (agent goals, constraints, available tools) and dynamic pulling of “task context” (historical operations, intermediate results, relevant files).

Related Topics:

Related Project: GS-2 — Its authoritative state in the DB is also a form of “dynamic context”: the agent’s state is preserved not by summarization compression but by external DB recovery on demand.
Related Article: Anthropic’s “Effective Harnesses” — Anthropic’s solution is a “dual-component architecture,” while Cursor’s solution is “dynamic pulling,” both pointing to the same conclusion: cross-session state cannot rely on summarization; it must depend on external storage.