Introduction

This article analyzes the “Dynamic Context Discovery” technology published by the Cursor Engineering Blog, revealing the paradigm shift from “static context injection” to “dynamic context discovery” and its fundamental impact on AI coding agent design.

Core Argument

Files are not an endpoint, but a conduit. The dynamic context discovery model of Cursor demonstrates that writing tool outputs, historical records, and MCP tool lists to the file system rather than directly injecting them into context improves token efficiency by 46.9%, while also enhancing agent response quality. This is not merely an optimization technique, but a fundamental answer to where context management should be addressed.

The Dilemma of the Old Paradigm: Static Context Injection

In traditional architectures, the management strategy for the Context Window is injective: injecting all potentially relevant information into the context, including:

• Full transcripts of historical conversations
• Complete descriptions of all MCP tools
• Indexes and summaries of the current codebase
• Terminal output logs

This strategy works well for short-term tasks but exposes two fundamental contradictions in long-term tasks:

Token Capacity vs. Information Completeness. The combined information from codebase indexes, tool descriptions, and conversation history far exceeds the capacity of the Context Window. The “injective” strategy either leads to information truncation or forces summarization, which is lossy compression that can lose critical details.

Context Relevance vs. Context Completeness. Each step executed by the agent requires different context. Injecting all potentially relevant context in one step means the agent has to sift through a lot of irrelevant information in each step, which is a significant waste of cognitive resources.

The official text points out this issue:

“Third-party tools (i.e., shell commands or MCP calls) don’t natively get this same treatment. 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.”

New Paradigm: Dynamic Context Discovery

The core idea of dynamic context discovery is: do not inject all information into the system prompt, but provide only references to files, allowing the agent to decide what context it needs.

Design Principles

1. Minimal Static Injection: The system prompt contains only the most basic information (tool name, main description), not the complete content.
2. On-Demand Pull: The agent actively reads files through tool calls instead of waiting for context to be passively injected.
3. File System as a Pipeline: Tool outputs are written to files, and the agent accesses them on demand through tail/grep/read, rather than loading everything into context at once.

Implementations in Five Scenarios

1. Long Tool Responses → Files

Shell commands and MCP call outputs are often lengthy. The traditional approach is to directly inject them into context, leading to context bloat, or truncate them, resulting in information loss.

Cursor’s solution:

Tool output → Write to file → Agent uses tail to view the end → Reads more as needed

This way, the agent does not need to process the entire raw output after each tool call; it only needs to handle the file path and the tail results, reducing unnecessary summarization triggers.

2. Conversation History → File References

When the context window reaches its limit, triggering summarization, the agent’s knowledge may suffer loss (since summarization is lossy). The agent may forget key details of the task.

Cursor’s solution: After summarization, provide the agent with references to historical files instead of forcing it to reconstruct information from the compressed context:

“If the agent knows that it needs more details that are missing from the summary, it can search through the history to recover them.”

This means summarization is no longer irreversible context loss, but a combination of “summary + file pointer” that allows the agent to proactively recover complete context.

3. Agent Skills → On-Demand File Loading

Cursor supports the Agent Skills standard. Skills are defined files that tell the agent how to perform tasks in specific domains.

Cursor’s solution: The complete content of skills is not directly injected; instead:

• Skill names and brief descriptions are injected as static context.
• The complete definition of the skill (file) is stored in the file system.
• The agent actively searches for relevant skills as needed using tools (grep / Semantic Search).

4. MCP Tools → On-Demand Synchronization

This is one of the critical scenarios. MCP servers typically contain numerous tools, and their descriptions can be lengthy. The combined descriptions from multiple MCP servers can severely occupy context space.

Cursor’s solution: Synchronize MCP tool descriptions to a folder, with tool descriptions existing as files in the file system. The agent only receives static prompts with tool names. When the agent needs a tool, it checks the folder itself.

Measured Effect:

“In an A/B test, we found that in runs that called an MCP tool, this strategy reduced total agent tokens by 46.9% (statistically significant, with high variance based on the number of MCPs installed).”

This 46.9% reduction in tokens is meaningful (reducing unnecessary information) rather than resulting from truncation loss.

5. Terminal Sessions → Files

Cursor synchronizes integrated terminal outputs to the local file system. Benefits include:

• The agent can directly grep specific log outputs instead of processing the entire terminal history.
• If a user asks, “Why did the command fail?”, the agent can directly read the relevant parts of the log file.
• Logs from long-term tasks do not occupy context but are accessed on demand.

Why Files Are a Better Abstraction

Cursor chooses the file system over an abstract tool search API for three key reasons:

1. Files Retain Information Structure

“We considered a tool search approach, but that would scatter tools across a flat index. Instead, we create one folder per server, keeping each server’s tools logically grouped.”

MCP tools are interrelated—tools from the same MCP server are often related. The file system organizes tools by folders, maintaining this semantic relationship rather than flattening all tools.

2. Files Support Stronger Search Capabilities

The agent can search using grep’s full parameters instead of relying on a simple search function of a flat index. The hierarchical structure of the file system allows the agent to:

• List all tools on a server (ls)
• Search through tool descriptions (grep -r)
• Understand the grouping relationships between tools

3. Files Are Primitives Familiar to the Model

LLMs have encountered numerous files and code files in their training data. This familiarity means that using files as interfaces has a lower error probability. Compared to designing a new abstract layer (like a “Tool Registry” API), using files is simpler and more stable.

The official text states:

“Files have been a simple and powerful primitive to use, and a safer choice than yet another abstraction that can’t fully account for the future.”

New Layering in Context Engineering

The dynamic context discovery model reveals a new layering in context engineering:

This layering resonates with Anthropic’s “Brain-Hands-Session Decoupling”—context management is addressed at the Harness layer rather than letting the model manage it itself.

Relation to Existing Work

Complementing Cursor App Stability: The previous analysis focused on Cursor’s App Stability engineering (OOM Reduction, Crash Watchdog), emphasizing “how to maintain process stability in long-term tasks.” Dynamic context discovery focuses on “how to maintain context quality in long-term tasks.” Together, they form the dual pillars of Cursor long-term agents: execution stability + context efficiency.

Complementing Anthropic Context Engineering: Anthropic’s context engineering emphasizes summarization, compaction, and selective memory techniques to address context capacity issues. Cursor’s dynamic context discovery solves the problem in another dimension—not by compressing context content, but by redefining how context is obtained (from injection to on-demand pulling).

Distinction Between Token Efficiency and Compression Efficiency: Dynamic context discovery is not about compression but routing—ensuring the right information reaches the right place at the right time. The 46.9% reduction in tokens does not come from compressing information but from optimizing information routing.

Evaluative Content

Limitations of This Model

Dynamic context discovery is not a silver bullet and has several key limitations:

1. Requires Agent’s Proactive Exploration Ability. If the agent does not know what context it lacks during the planning phase, it will not proactively seek it out. This is highly related to the agent’s self-reflection capability.

2. File I/O Increases Tool Call Frequency. The agent needs additional tool calls (read/tail/grep) to obtain context, which may increase the total number of tool calls and affect latency. In high-frequency tool call scenarios, this could be costly.

3. Reliance on the Underlying File System’s Reliability. If file writing fails or synchronization is delayed, the agent may receive outdated or missing context. This requires that Cursor’s file system synchronization mechanism itself is reliable.

Implications for the Industry

The core contribution of dynamic context discovery is not the “46.9% token reduction” figure, but rather redefining the approach to managing the Context Window:

The responsibility of context management shifts from the “injection end” (stuffing information in) to the “consumption end” (allowing the model to pull on demand).

The impact on agent design is fundamental. In traditional architectures, the harness is responsible for “injecting as much information as possible”; in the new paradigm, the harness is responsible for “establishing a file system pipeline, allowing the model to decide what it needs.”

The former becomes increasingly untenable as the Context Window expands (too much information to inject); the latter becomes increasingly feasible as model capabilities improve (the model can more accurately determine what it needs).

Technical Details

Engineering Implementation of File Synchronization:

• MCP tool descriptions are synchronized to a local folder (one subfolder per server).
• Terminal outputs are synchronized in real-time to the file system.
• Chat history is provided as file references after summarization.

Agent’s Context Discovery Behavior:

• The agent receives static prompts with tool names (rather than complete descriptions).
• Tool name prompts indicate to the agent “check the file when needed.”
• The agent uses grep / ls / tail and other tools to obtain complete information.

Performance Impact:

• In MCP tool calling scenarios: Token reduction of 46.9% (A/B test, statistically significant).
• The reduced tokens are “unnecessary injected redundant information,” not useful information.

Conclusion

Cursor’s dynamic context discovery model points to a more fundamental design shift: from “context as injected data” to “context as on-demand resources.” The advantages of files as context primitives include: token efficiency, structural retention, strong search support, and ease of implementation.

The core insight of this model is that the capacity issue of the Context Window is not just a compression issue but a routing issue. Ensuring the right information reaches the right place at the right time is more effective than stuffing all potentially relevant information in.

“Files have been a simple and powerful primitive to use, and a safer choice than yet another abstraction that can’t fully account for the future.” — Cursor Engineering: Dynamic Context Discovery