Skip to content

PATTERN Cited by 3 sources

Unified retrieval tool

Unified retrieval tool is the pattern of replacing N source-specific retrieval tools (one per app, one per index, one per schema) with one tool backed by a pre-built index that spans all those sources. From the agent's perspective, retrieval is a single interface; from the system's perspective, the aggregation + ranking happens offline so the model never has to pick between Confluence, Google Docs, Jira, …

Intent

Solve the compound problem of:

Mechanism

  1. Build a unified index spanning every source you want the agent to retrieve from (Dash: their "universal search index", systems/dash-search-index).
  2. Pre-rank at index time using whatever signals matter in your domain (Dash: a concepts/knowledge-graph over people + activity + content).
  3. Expose one retrieval tool (dash_search-class) to the agent. The tool's docstring + params stay short; the agent's decision reduces to "should I search?" rather than "which retrieval tool?".
  4. Handle multi-source aggregation server-side. The agent sees a single ranked result list; which source each hit came from is a property of the hit, not the tool.

Why it helps

  • Context budget. One tool description resident in context instead of N.
  • Accuracy. Fewer retrieval options means the model almost never picks wrong (concepts/tool-selection-accuracy).
  • Reasoning clarity. The agent's plan is simpler — "search, then act on results" — so the planner's context stays focused on the user's task, not on retrieval choreography.
  • Consistent ranking. Cross-source ordering is controlled by one ranker, not by agent-side merge heuristics.
  • MCP-friendly. One tool exported over MCP gets you the same leverage for third-party agents (Dash ships this as systems/dash-mcp-server for Claude / Cursor / Goose).

Tradeoffs

  • Index build cost. You now own a real search system — ingestion pipelines, freshness, ACLs, relevance eval, graph maintenance. This is much more work than wrapping per-app APIs.
  • Relevance-eval pressure. If the single ranker is bad, every query is bad. Per-app retrieval at least failed independently.
  • Source-heterogeneity asymmetry. Some sources have richer metadata than others; a unified ranker has to handle missing/asymmetric signals gracefully.
  • Access-control complexity. The unified index must enforce every source system's ACLs correctly; one leak affects all queries.

When to reach for it

  • You expose an agent over a user's fragmented data surface (several apps, each with its own retrieval API).
  • You already build or are willing to build a search index — cost-effective only when retrieval is load-bearing to your product.
  • patterns/tool-surface-minimization alone isn't enough: "flexible tools" still leaves N retrieval surfaces; you need index-side consolidation.

Known instances

  • Dash — originating case; backed by Dash Search. Same tool exported outward as Dropbox's MCP server — one tool for Claude / Cursor / Goose that searches across the user's connected apps (Source: sources/2025-11-17-dropbox-how-dash-uses-context-engineering-for-smarter-ai). The 2026-01-28 companion talk gives this pattern its colloquial Dash name: "super tool." "We've got our index, and we can wrap that around a tool. Let's call it a super tool. And so instead of 5-10 different retrieval tools, we just have one. This helps a ton with cleaning things up overall." (Source: sources/2026-01-28-dropbox-knowledge-graphs-mcp-dspy-dash) Also names this as the first of four fixes Dash applied to make MCP work at scale (the other three: knowledge-graph bundles for token-efficient results, store tool results locally rather than in the context window, and classifier-routed sub-agents).
  • Cloudflare AI Search (2026-04-16) — namespace-level realisation. The support-agent worked example exposes one search_knowledge_base tool to the LLM; under the hood it calls env.SUPPORT_KB.search({ query, ai_search_options: { instance_ids: ["product-knowledge", "customer-<id>"] } }), fanning across shared + per-customer indexes in one call (patterns/cross-index-unified-retrieval). The agent doesn't see (or have to pick between) "search product docs" + "search my past" — it sees one tool. Different decomposition from Dash (which pre-builds one unified index) but same thesis at the agent-tool surface: one tool, not N. Pairs with patterns/runtime-provisioned-per-tenant-search-index — Cloudflare solves the per-tenant isolation by decomposing into many instances + fan-out, Dash solves it by unifying into one index with tenant-aware ranking. Both deliver the same agent- visible shape.
Last updated · 200 distilled / 1,178 read