Building a Collaborative Multi-Agent AI Ecosystem for Enterprise Knowledge Access

doordash · Tech · 2025 · source Agentic: yes · promotional bias: med · summary-only (no fetched source) · extracted with prompt 0.5.4 (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 access and analytics

DoorDash needed to help business teams and developers access knowledge scattered across experimentation platforms, metrics hubs, dashboards, wikis, and team communications without constant context switching.

Constraints:

• source content could not be fetched, so this extraction is summary-only
• knowledge is fragmented across many internal systems
• SQL generation must be schema-aware and validated without touching data
• answers need provenance and guardrails
• users work in Slack and Cursor rather than a single analytics UI

Architecture

The summary describes an internal DoorDash agentic AI platform that evolved from deterministic workflows to single agents, hierarchical deep agents, and exploratory agent swarms. Core services include hybrid vector search with RRF re-ranking, schema-aware SQL generation with cached examples, multi-stage zero-data query validation, LLM-as-judge evaluation, and integrations into Slack and Cursor.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  slack-cursor-surfaces[Slack Cursor surfaces] --> agentic-ai-platform[Agentic AI platform]
  agentic-ai-platform --> hybrid-search[Hybrid search]
  hybrid-search --> knowledge-sources[Knowledge sources]
  agentic-ai-platform --> sql-generation[SQL generation]
  sql-generation --> zero-data-validation[Zero-data validation]
  zero-data-validation --> llm-judge[LLM judge]

Components

Data flow

A user asks a question from Slack or Cursor. The platform retrieves context through hybrid vector search and RRF re-ranking, generates schema-aware SQL with cached examples when needed, validates queries without data access, uses LLM-as-judge evaluation for quality, and returns provenance-backed answers in the user's workflow.

Why this architecture

DoorDash's summary frames a layered architecture because enterprise knowledge access involves multiple task shapes: retrieval over many sources, data questions that need SQL, deeper research that needs hierarchical agents, and exploratory questions that may benefit from swarms. Slack and Cursor integration reduces context switching.

Models used: LLMs · LLM-as-judge · embedding model

Alternatives considered (roads not taken)

Single-agent architecture only

Rejected because: The platform evolved beyond single agents into hierarchical deep agents and swarms for more complex exploration.

Separate analytics/search UI requiring context switching

Rejected because: The platform integrates with Slack and Cursor to meet users where they already work.

Patterns

multi-agent-orchestration (agent-design)

The platform includes hierarchical deep agents and exploratory swarms beyond single-agent workflows.

hybrid-search (retrieval)

The platform uses hybrid vector search with RRF-based reranking across fragmented knowledge sources.

llm-as-judge (evaluation)

The platform uses LLM-as-judge evaluation frameworks for quality control.

guardrails-io-filtering (safety)

The summary emphasizes guardrails and provenance tracking around data access.

Tradeoffs

Agent complexity

Chose deterministic workflows, single agents, deep agents, and swarms over one fixed orchestration pattern.

Rationale: Different knowledge-access tasks require different levels of autonomy and exploration.

User surface integration

Chose Slack and Cursor integrations over forcing users into a separate AI portal.

Rationale: Meeting users in existing workflows reduces context switching.

Gotchas (what bit them)

Enterprise knowledge access suffers from fragmentation.

Root cause: Experiments, metrics, dashboards, wikis, and communications live in separate systems.

Resolution: Use a collaborative AI ecosystem with hybrid search and workflow integrations.

Generated SQL needs validation without unsafe data access.

Root cause: Business teams need data answers, but query mistakes can be risky.

Resolution: Use schema-aware SQL generation with multi-stage zero-data validation.

Evaluation

The summary identifies LLM-as-judge frameworks, zero-data SQL validation, provenance, and guardrails as the quality and safety apparatus.

Metrics: LLM-as-judge evaluation · zero-data query validation · provenance tracking · guardrail coverage

Outcomes

• The platform democratizes data access for business teams and developers.
• It reduces context switching by integrating into Slack and Cursor.

No concrete deployment volume is available from the fetched source; the extraction is summary-only.