How Dash uses context engineering for smarter AI

From retrieval to action: the context problem

Dropbox’s Dash initially looked like a conventional enterprise search product: a RAG pipeline combining semantic and keyword search over indexed documents. That worked for answering factual questions. But as users pushed Dash beyond retrieval—asking it to interpret content, summarize it, and act on it—Dropbox engineers found that retrieval alone was insufficient. A query like “open the editor and write an executive summary of the projects that I own” requires planning and tool use, not just search.

That shift turned Dash from a search system into an agentic AI, and introduced a new engineering challenge: deciding what information and tools the model actually needs to reason effectively. This is what has come to be called context engineering—structuring, filtering, and delivering the right context at the right time. The authors discovered that supplying the model with only the most relevant context, rather than more of it, consistently produces better outcomes.

Too many tools, too little focus

As Dash added capabilities such as contextual search and assisted editing, a counterintuitive pattern emerged: more tools led to slower and less accurate decisions. Each external function the model can call—search, look-up, summarization—expands the model’s decision space and consumes context window tokens. The problem was not broken tools but an excess of good ones. Dash was experiencing analysis paralysis.

The Model Context Protocol (MCP) helps standardize how tools are described, specifying what each tool does and its inputs. But MCP servers introduced their own limitations in practice. Every tool adds descriptions and parameters that must fit inside the context window, consuming tokens that affect cost and performance. Longer-running jobs saw noticeable accuracy degradation—a pattern consistent with what has been popularized as context rot.

Dropbox’s response was to rethink context with three strategies:

• Limit the number of tool definitions in the context
• Filter context to only what’s relevant
• Introduce specialized agents for tasks requiring deeper reasoning

The principle: better context leads to better outcomes—the right information, at the right time, in the right form.

One retrieval tool instead of dozens

The first insight was that offering the model too many retrieval options degraded results. Dash connects to many customer apps, each with its own retrieval tools like search, find by ID, or find by name. A single request might require consulting Confluence for documentation, Google Docs for meeting notes, and Jira for project status.

Experiments with these per-app tools showed the model often had to call all of them—and didn’t do so reliably.

The solution was consolidation: replace all retrieval options with a single, purpose-built tool backed by the Dash universal search index. Rather than expecting the model to learn and choose between dozens of APIs, one interface handles retrieval across all services. One consistent retrieval path makes the model’s reasoning clearer, its plans more efficient, and its context use more focused.

These lessons carried into the Dash MCP server, which exposes Dash retrieval to MCP-compatible applications like Claude, Cursor, and Goose through a single tool. Lean tool descriptions keep context window space focused on the user’s request rather than on tool documentation.

Relevance filtering through a knowledge graph

The second insight concerned the results themselves. Pulling data from multiple APIs does not guarantee that everything retrieved is useful. Dash needed a way to rank and filter so only the most relevant information reached the model.

The Dash index combines data from multiple sources into one unified index. On top of that, a knowledge graph maps relationships between people, activity, and content across those sources, helping rank results according to what matters for each query and user. The model only sees content the platform has already determined as relevant, making every piece of context meaningful. Building the index and graph ahead of time lets Dash focus on retrieval at runtime rather than reconstructing context, improving speed and efficiency.

The key lesson, the authors write, is that everything retrieved shapes the model’s reasoning. Sending only essential information improves both performance and the quality of the whole agentic flow.

When a tool becomes an agent

The third discovery was that some tools are so complex the model needs a disproportionate amount of instruction to use them correctly. Dash’s search tool is one such case. Query construction—understanding intent, mapping it to index fields, rewriting queries for semantic matching, and handling misspellings and synonyms—proved difficult on its own. As the tool grew more capable, its usage documentation consumed growing portions of the context window, leaving less room for reasoning about the actual task.

Dropbox’s solution was to move search into its own agent. The main planning agent decides when a search is needed and delegates query construction to a specialized agent with its own focused prompt. The main agent can then center on planning and execution while the search agent handles retrieval details. When a tool needs too much explanation to be used effectively, the pattern suggests converting it into a dedicated agent.

Leaner contexts, smarter models

Context engineering for agentic systems remains an emerging discipline. Dropbox acknowledges that its three strategies—retrieval consolidation, relevant context filtering, and specialized task agents—work for its use cases but are still being iterated on. The Dash index has proven a useful resource for managing relevant context and a foundation for using other tools effectively.

Context is expensive in several dimensions: cost, speed, and the attention budget available for reasoning. The team’s experience is that leaner contexts not only conserve resources but also make the model perform better.

Going forward, the team is applying these lessons to other parts of Dash’s context, including user and company profiles and short- and long-term memory. They expect further performance gains, especially as experimentation moves toward smaller, faster models.

The discussion focused on retrieval-based tools, but action-oriented tools exhibit similar constraints. MCP is a robust protocol, but scaling effectively requires reducing tool proliferation, investing in specialized agents, and letting LLMs generate code-based tools where appropriate—an approach consistent with consolidating retrieval into the Dash system, a design covered in a previous Dropbox post and one other companies are pursuing with a similar mindset.