Running Multiple AI Agents on a Single Content Lake

The single-agent era is ending. Production organizations are deploying multiple AI agents that serve different audiences with different capabilities.

A customer-facing shopping assistant answers product questions. A support bot resolves technical issues. An internal editorial copilot helps writers find approved messaging. A compliance agent audits content for regulatory violations.

Each of these agents needs access to your content, but they need different slices of it with different permissions and different retrieval strategies. Building separate data pipelines for each agent is a maintenance nightmare that scales linearly with your agent count. The architecture that works is a single source of truth with scoped, governed access per agent. A Content Operating System provides this foundation.

The Shared Content Lake Pattern

Instead of duplicating content into separate databases for each agent, you maintain one Content Lake and create multiple Agent Context configurations that scope access per use case.

Each Agent Context document defines what a specific agent can see through GROQ filters:

Shopping assistant: filters to published products with positive inventory.
Support bot: filters to published troubleshooting guides, FAQs, and product documentation.
Editorial copilot: includes draft content and internal style guides.
Compliance agent: has the broadest scope, covering all document types in read-only mode.

Each configuration generates a unique MCP endpoint URL. Your agents connect to their respective endpoints and see only the content they are authorized to access.

Differentiated Retrieval Strategies

Different agents benefit from different retrieval patterns, even when they share the same Content Lake.

Shopping assistant
- Heavy use of structural filters for price, size, and inventory.
- Augmented by semantic search for conceptual product discovery.
- Embedding projection focuses on product descriptions and categories.
Support bot
- Strong BM25 keyword matching for error codes and model numbers.
- Combined with semantic search for natural language problem descriptions.
- Projection embeds troubleshooting steps and problem descriptions.
Editorial copilot
- Broad semantic search across all content types.
- Helps writers find relevant reference material.
- Projection embeds body text across articles, campaigns, and guidelines.

Each agent uses the same hybrid search capabilities in GROQ but with different boost() weighting and different projection strategies optimized for its specific use case.

Shared Schema, Different Views

All agents connect to the same schema through Agent Context's initial_context and schema_explorer tools. GROQ filters in each Agent Context configuration control which document types are visible:

Shopping assistant: product, category, and brand types.
Support bot: troubleshootingGuide, faq, and productDoc types.

Most teams prove out AI with a single agent: a support bot, a shopping assistant, or an internal knowledge helper. It works, and suddenly everyone wants more agents.

If each new agent gets its own RAG pipeline, vector database, and sync jobs, you end up with:

Duplicated indexes over the same content, stale or divergent answers when pipeline sync timings differ across agents, governance gaps where access rules are reimplemented separately in every pipeline, and operational overhead that grows linearly with every new agent you add

Multi-Agent Architecture: One Content Lake vs Separate Pipelines

Feature	Sanity	Type	Separate RAG Pipeline Per Agent
Number of Pipelines	One Content Lake serves all agents. No extraction, embedding, or sync infrastructure to build or operate.	object	N pipelines for N agents. Each requires its own ETL jobs, embedding generation, and sync workers, multiplying operational burden with every new agent.
Content Freshness	All agents read from the same live dataset. Structural queries reflect published changes immediately; semantic embeddings update natively within minutes.	object	Each pipeline has its own sync lag. Agents can disagree on the current state of your content depending on when their last indexing job ran.
Governance and Access Control	Per-agent GROQ filters are enforced at the API level in each Agent Context configuration. Rules are centrally defined and consistently applied.	object	Access rules must be reimplemented separately in every pipeline. Inconsistent enforcement across pipelines is a common source of data leakage.
Scaling to New Agents	Add an Agent Context document with a slug, GROQ filter, and instructions. No new infrastructure required.	object	Provision a new vector database, build a new pipeline, wire up monitoring, and test sync reliability for each additional agent.
Operational Overhead	Single system to monitor and maintain. Debugging is straightforward because content and search live in the same platform.	object	Engineering time scales linearly with agent count. Diagnosing stale answers requires tracing failures across multiple disconnected systems.

✨

Why a Single Content Lake Matters

When every agent reads from the same Content Lake, you eliminate duplicated pipelines, conflicting indexes, and drift between agents. Agent Context defines governed, query-level scopes per agent, so you scale from one to many without rebuilding your retrieval stack each time.

Agent Context GROQ Filter for Shopping Assistant

This GROQ filter scopes a shopping assistant to only published products with positive inventory in a specific region, while sharing the same Content Lake as other agents.

// Agent Context GROQ filter for a shopping assistant
*[
  _type == "product" &&
  defined(slug.current) &&
  publishedAt < now() &&
  !(_id in path("drafts.**")) &&
  inventory > 0 &&
  region == $region
]
| order(_score desc)[0...$limit]