Federated Context Platform for Enterprise AI Agents

Our position. We hold that one big context file does not scale (opens in a new tab): context should be federated in layers that mirror the org chart, each kept by the people who already own that knowledge. Where two layers disagree, an agent can act as a neutral architecture mediator, and that is federated context governance.

The model is Conway’s Law pointed at the agents, and it borrows from data mesh. Treating data as a product gives each domain explicit ownership and quality duties (Deloitte (opens in a new tab)). A single central team cannot keep pace with change across the enterprise, so a monolithic context store becomes the bottleneck (Strategy and architecture).

The context itself falls into layers. Platform context carries shared policies and guardrails, domain context the business rules and decisions, technical context the code and architecture, and agent context the task state and memory. An LLM gateway governs model access, cost and guardrails, and a context catalog holds the metadata that makes each product discoverable. Agents ask the catalog what exists and the gateway for the content, ideally over the Model Context Protocol (opens in a new tab) (The platform layer).

Storage stays polyglot. Hybrid enterprise search beats pure vector search when precision matters, for example on an error code or a product SKU. Knowledge graphs answer multi-hop questions, and Git-style repositories give long-running agents auditable, branchable memory (Storage and retrieval architectures). Source code becomes context through AST parsing and a code knowledge graph (Engineering context products).

Governance belongs in the architecture from the first release. Access control filters data at the retrieval layer, because a prompt instruction cannot hold a security boundary against prompt injection. Event-driven re-indexing, versioned products and named maintainers keep context from going stale (Governance and operations).

Start here

• Strategy and architecture — Why enterprise agents need a context fabric and how Context as a Product shapes its architecture.
• The platform layer — The gateway and catalog services that make federated context discoverable and governable.
• Engineering context products — How raw enterprise knowledge and source code become reusable, AI-ready context products.
• Storage and retrieval architectures — How vector search, enterprise search, graphs, and Git serve different context needs.
• Governance and operations — How to assemble, secure, refresh, and operate federated context over time.

Related

• The Federated Factory at Enterprise Scale: a comparable ownership split, in three tiers, for software factories.
• Memory and Context Engineering: context work at the scale of one team and one repository.
• Context as a versioned artifact: how owned context gets tested, distributed and revised like code.
• Architecture and Design: the wider architecture questions agents raise.
• Protocol and context cost: what serving context products over MCP costs an agent’s window.

Resources

Documentation

• Model Context Protocol (opens in a new tab) - Official site and specification of the open protocol agents use to discover and retrieve context products through a shared interface.

Papers and reports

• Treating data as a product in the era of GenAI (opens in a new tab) - Deloitte paper applying data-as-a-product thinking to generative AI, giving each domain explicit ownership and quality duties.

Posts

• Federated in layers that mirror the org chart (opens in a new tab) - LinkedIn post arguing that context should be federated in layers mirroring the org chart, each kept by the knowledge’s owners.