Context Engineering for Agentic AI Systems

dropbox · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise knowledge-work AI assistant and agentic search

Dropbox needed Dash to evolve from a RAG search system into an agentic assistant that could interpret, summarize, and act on information. Adding tools and MCP-style capabilities created analysis paralysis, context-window cost, and degraded long-running accuracy because the model spent too much attention deciding how to search.

Constraints:

The assistant must connect across many customer applications and enterprise data sources.
Tool descriptions and parameters consume context-window tokens and affect cost and performance.
Retrieved context must be relevant to the user and task, not merely available.
Complex query construction needs enough instruction without crowding out the main planning task.
The system must preserve security and relevance while integrating with MCP-compatible tools.

Architecture

Dropbox restructured Dash around context precision: consolidate retrieval through a universal Dash Search index, rank/filter results with a knowledge graph, and delegate complex search/query construction to a specialized agent so the main planning agent stays focused on execution.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  dash-assistant["Dash assistant"] --> main-planning-agent["Main planning agent"]
  main-planning-agent --> universal-search-index["Universal search index"]
  universal-search-index --> knowledge-graph["Knowledge graph"]
  main-planning-agent --> specialized-search-agent["Specialized search agent"]
  specialized-search-agent --> universal-search-index
  dash-mcp-server["Dash MCP server"] --> universal-search-index
  dash-assistant --> dash-mcp-server

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Dash assistant`	User-facing AI assistant that plans, reasons, searches, summarizes, edits, and acts on workplace information.	`Main planning agent`, `Dash MCP server`
`Main planning agent`	Agent that decides what steps to take and when search is needed, while avoiding detailed query-construction burden.	`Dash assistant`, `Universal search index`, `Specialized search agent`
`Universal search index`	Single retrieval interface that searches across services instead of exposing many app-specific retrieval tools.	`Main planning agent`, `Knowledge graph`, `Dash MCP server`
`Knowledge graph`	Precomputed relationship layer connecting people, activity, and content so retrieved results can be ranked by task and user relevance.	`Universal search index`
`Specialized search agent`	Focused agent that handles query construction, rewriting, field mapping, typos, synonyms, and implicit context.	`Main planning agent`, `Universal search index`
`Dash MCP server`	MCP-compatible interface that exposes Dash retrieval to external apps like Claude, Cursor, and Goose.	`Dash assistant`, `Universal search index`

Data flow

A user request reaches the main planning agent. When retrieval is needed, the agent uses a single Dash universal search interface rather than many app-specific tools; the index and knowledge graph rank relevant content, and a specialized search agent handles complex query construction before results return to the main agent.

“Instead of expecting the model to understand and choose between dozens of APIs, we created one interface that handles retrieval across all services.”article, stated

“The main planning agent decides when a search is needed and delegates the actual query construction to a specialized agent with its own prompt.”article, stated

Why this architecture

Dash's architecture reduces the model's decision space. One retrieval interface, pre-ranked context, and delegated query construction let the main agent spend attention on the user's task rather than choosing among tools or parsing complex tool schemas.

“The key idea is simple: Giving the model one consistent way to retrieve information makes its reasoning clearer, its plans more efficient, and its context use more focused.”article, stated

“This separation allows the main agent to stay focused on planning and execution while the search agent handles the specifics of retrieval.”article, stated

Models used: LLM planning agent · Specialized search agent · MCP-compatible clients including Claude, Cursor, and Goose

Scale

Dash connects across many apps used by customers.
“Dash connects to many of the apps our customers use to get work done, and each of those apps provides its own retrieval tools”article, stated
The MCP server connects retrieval into multiple external AI apps.
“brings Dash’s retrieval to MCP-compatible apps like Claude, Cursor, and Goose with just one tool.”article, stated

Alternatives considered (roads not taken)

Expose many app-specific retrieval tools directly to the model

Rejected because: The model often had to call all tools and did not reliably choose among them, creating slower and less accurate decision-making.

“In our experiments with those other retrieval tools, we found that the model often had to call all of them, but it also didn’t do so reliably.”article, stated

Send retrieved data from several tools without a relevance layer

Rejected because: Dropbox still needed ranking and filtering so only the most relevant information reached the model.

“we still needed a way to rank and filter the results so that only the most relevant information reached the model.”article, stated

Keep complex Dash Search query construction inside the main planning agent

Rejected because: The search tool required so much instruction that it consumed context the main agent needed for planning and execution.

“Those details started to take up a significant portion of the context window, leaving less room for reasoning about the overall task.”article, stated

Patterns

`rag-retrieval` (retrieval)

Dash started as a RAG-style enterprise search system and retained retrieval as a core capability while making it more agent-aware.

“The natural progression from “what is the status of the identity project” to “open the editor and write an executive summary of the projects that I own” required Dash to evolve from a search system into an agentic AI.”article, stated

`tool-use-orchestration` (orchestration)

Dropbox collapsed many app-specific retrieval tools into one universal search tool so the agent had fewer choices and a clearer action path.

“Instead of expecting the model to understand and choose between dozens of APIs, we created one interface that handles retrieval across all services.”article, stated

`retrieval-ranking` (retrieval)

A knowledge graph ranks and filters retrieved content by user and query relevance before the model sees it.

“These relationships help rank results based on what matters most for each query and each user. As a result, the model only sees content our platform has already determined to be relevant”article, stated

`multi-agent-orchestration` (orchestration)

A specialized search agent handles complex query construction while the main planning agent stays responsible for the overall task.

“We solved this by moving search into its own agent. The main planning agent decides when a search is needed and delegates the actual query construction to a specialized agent with its own prompt.”article, stated

`query-rewriting` (retrieval)

The specialized search agent handles user-intent mapping, semantic query rewriting, typo handling, synonyms, and implicit context.

“It involves understanding user intent, mapping that intent to index fields, rewriting queries for better semantic matching, and handling edge cases such as typos, synonyms, and implicit context.”article, stated

Tradeoffs

Retrieval interface

Chose one universal search index over dozens of app-specific retrieval APIs.

Rationale: A single retrieval path reduced tool-selection burden and made plans clearer and more efficient.

“Giving the model one consistent way to retrieve information makes its reasoning clearer, its plans more efficient, and its context use more focused.”article, stated

Context filtering

Chose pre-ranked index plus knowledge graph over passing all retrieved data from multiple tools to the model.

Rationale: Filtering before generation makes every piece of context meaningful and avoids rebuilding context at runtime.

“Building the index and graph in advance means Dash can focus on retrieval at runtime instead of rebuilding context, which makes the whole process faster and more efficient.”article, stated

Complex search behavior

Chose a specialized search agent over teaching the main planning agent all search details.

Rationale: Separating search keeps the main agent focused on planning and execution while a focused prompt handles retrieval specifics.

“when a tool demands too much explanation or context to be used effectively, it’s often better to turn it into a dedicated agent with a focused prompt.”article, stated

Gotchas (what bit them)

Tool proliferation caused analysis paralysis.

Root cause: Each additional tool expanded the model's decision space, adding choices and room for confusion.

Resolution: Consolidate retrieval behind one universal search interface.

“Each new capability expanded the model’s decision space, creating more choices and room for confusion. Even well-designed tools made the model spend more time deciding how to act instead of acting.”article, stated

MCP tool definitions consumed context and degraded long-running jobs.

Root cause: Tool descriptions and parameters must fit in the context window and add context over time.

Resolution: Keep tool descriptions lean and reduce the number of exposed retrieval tools.

“Each tool we added came with its own description and parameters, which all have to fit inside the model’s context window”article, stated

“we noticed that the overall accuracy of Dash degraded for longer-running jobs. The tool calls were adding a lot of extra context.”article, stated

Complex query construction crowded out reasoning about the user's task.

Root cause: As Dash Search gained more capabilities, the main model needed more instruction just to use the search tool correctly.

Resolution: Move search into a dedicated agent with its own focused prompt.

“As the search tool grew more capable, the model needed more instruction to use it correctly. Those details started to take up a significant portion of the context window”article, stated

Evaluation

Dropbox evaluates the design through observed decision speed, accuracy, token/cost pressure, and qualitative agent-flow quality rather than reporting a formal benchmark.

Metrics: decision speed · accuracy on longer-running jobs · token consumption · cost and performance impact

“more tools often meant slower, less accurate decision making.”article, stated

“these definitions also consume a significant number of tokens, a resource that directly impacts both cost and performance.”article, stated

Outcomes

Dash retrieval became simpler for the model through a single universal search interface.
Knowledge-graph filtering made retrieved context more relevant before the model saw it.
Specialized search delegation let the main planning agent stay focused on the user's task.

The case describes retrieval across many customer apps and MCP-compatible integrations, but does not give deployment volume or latency numbers.

“By keeping descriptions lean, more of the context window stays focused on the user’s request.”article, stated

“We’ve found that leaner contexts don’t just save resources; they also make the model smarter.”article, stated