Skip to content

Knowledge base

Governance and operations

Federated context stays safe and useful only if it is governed after launch. An orchestrator assembles just the context a task needs, access control filters data at the source instead of trusting the model, and event-driven re-indexing, versioning and named owners keep context from going stale.

Written by

Updated:

Agentic Engineering 5

Our position. We hold that for what must never happen, you limit what the agent can reach at all (opens in a new tab) instead of filtering what it asks for. Context is owned like code: reviewed, versioned and tested against actual agent behaviour (opens in a new tab), because it drifts.

How do you assemble, secure, and maintain context in production?

Together, the platform components form a cognitive architecture: a framework for how the system processes, stores, and retrieves information in a way that mirrors human cognition (Cognee - Cognitive Architectures for AI Agents (CoALA): Explained (opens in a new tab)). Operating it means assembling context per task, securing access, and keeping context fresh over its lifecycle.

Dynamic Context Assembly: Orchestration Patterns for AI Agents

With a rich ecosystem of Context Products available, the agent’s task is no longer simple retrieval but dynamic orchestration. Context engineering is the discipline of intelligently selecting, filtering, compressing, and structuring the right context for a specific task to be passed to an LLM (Context Engineering in LLM-Based Agents (opens in a new tab)). This process is managed by an orchestration layer, which could be part of the agent’s own logic or a dedicated intermediary service.

The orchestration workflow can be conceptualized as an ECL (Extract, Cognify, Load) pipeline, a pattern for building dynamic memory for agents:

  1. Extract (Intent Analysis & Federated Retrieval): The orchestrator first analyzes the user’s prompt to understand the intent and determine the required context types. For example, a prompt like “Refactor the UserService to use our new logging library and ensure it meets our performance standards” requires multiple context types: Technical Context (the source code of UserService, the API of the new logging library) and Domain Context (the performance standards documentation). It then queries the Context Catalog to discover the relevant contextProductIDs. Finally, it makes concurrent requests—ideally via a standardized protocol like MCP—to retrieve the data for each identified Context Product from the appropriate backend systems.
  2. Cognify (Prompt Synthesis): The retrieved context pieces are assembled into a final prompt. This is a critical step that involves more than simple concatenation. The orchestrator must manage the total token count, potentially by summarizing less critical information or compressing redundant text, to fit within the LLM’s context window (Reddit - 6 Techniques You Should Know to Manage Context Lengths in LLM Apps (opens in a new tab)). The information is structured with clear headings to help the LLM distinguish between different context sources (e.g., “Source Code:”, “Relevant Documentation:”, “API Specification:”).
  3. Load (LLM Interaction): The final, context-rich prompt is loaded into the LLM for processing.

Advanced Orchestration Patterns

For more advanced use cases, more sophisticated orchestration patterns can be employed:

  • Difficulty-Aware Orchestration: Simple, routine queries might trigger a standard RAG pipeline. However, if the orchestrator estimates a query to be highly complex, it can dynamically compose a more sophisticated workflow, such as initiating a multi-agent debate or triggering a deep, multi-hop GraphRAG query to gather more comprehensive context (arXiv - Difficulty-Aware Agent Orchestration in LLM-Powered Workflows (opens in a new tab)).
  • Multi-Agent Workflows: For creative and complex tasks like generating a new software component, a single agent may be insufficient. Frameworks like Archon demonstrate a multi-agent approach where different agents collaborate (Decentralised-AI - Archon - AI Agent Builder (opens in a new tab)). A “planner” agent first outlines the task, a “coder” agent writes the initial implementation using the available Technical Context, and one or more “refiner” agents iteratively improve the code based on feedback and testing. This separation of concerns mirrors a human development team and can produce significantly more robust results.

Securing the Fabric: Federated Access Control

In any enterprise system, security is paramount. Relying on an LLM’s instruction-following ability to enforce access control (e.g., “Do not reveal financial data”) is fundamentally insecure, as LLMs are susceptible to prompt injection attacks (LaunchDarkly - AI application development best practices: From prototype to production (opens in a new tab)). A robust security model must enforce access control at the data layer, ensuring the LLM is never exposed to information the user is not authorized to see.

A Role-Based Access Control (RBAC) model implemented within the RAG pipeline provides this necessary security guarantee (Ping Identity - Understanding RBAC, PBAC, and ABAC: Access Control Explained (opens in a new tab)). Federated retrieval can also enforce policy-based controls at the source (MIT (opens in a new tab)). The implementation is as follows:

  1. Authentication and Role Identification: When a user interacts with an agent, their request to the LLM Gateway is authenticated. The gateway, integrating with the enterprise’s Identity and Access Management (IAM) system, identifies the user’s role(s) (e.g., engineer, sales, admin).
  2. Context-Aware Retrieval: The user’s role information is passed along with every context retrieval request.
  3. Filtering at the Source: The underlying retrieval systems are responsible for enforcing the access control. The accessControlTags metadata stored with each Context Product and its underlying data chunks is used for filtering. For example, a request from a user with the sales role for “Q4 performance” would cause the search engine to automatically append a filter AND (role:sales OR role:public) to its query, ensuring that engineering-only performance metrics are never returned (Building a Role-Based RAG System: Implementing Secure Document Access with Retrieval-Augmented Generation (opens in a new tab)).

This architecture ensures that security is enforced by deterministic filtering rules within the data stores, not by the probabilistic behavior of an LLM. The access control metadata within the Context Catalog thus becomes a cornerstone of the platform’s security and governance model.

Managing the Lifecycle: Addressing Context Staleness and Evolution

A context platform is not a static data lake; it is a living ecosystem. The information within it is constantly changing as code is committed, documents are updated, and business processes evolve. Managing this lifecycle is crucial to prevent context staleness, where agents provide outdated or incorrect answers based on stale information (Scalable RAG Architectures: How Context Length, Model Choice, and Business Needs Drive Latency (opens in a new tab)).

Strategies for maintaining context freshness include:

  • Event-Driven Ingestion: The most effective approach is to use event-driven pipelines. Webhooks from source systems, such as a Git post-commit hook or a Confluence page-update event, can automatically trigger the re-indexing pipeline for the specific Context Product that has changed. This ensures low-latency updates.
  • Scheduled Re-indexing: For systems that do not support webhooks, periodic polling and re-indexing (e.g., nightly) can be used to ensure a baseline level of freshness.
  • Versioning and Caching: All Context Products in the catalog should be versioned. This allows for stable, reproducible agent behavior. The LLM Gateway can implement a caching layer, using the freshness metadata (e.g., TTL) from the catalog to determine how long to cache a piece of context, balancing performance against the need for the latest information.

Atlan’s founder separates company context into business facts, procedural know-how, and decision norms. In her vendor field report, isolated task agents carried separate memories, drifted apart, and trapped context inside each agent framework. Her replacement is a shared repository where domain owners maintain reusable skills for general-purpose agents. That adds an ownership boundary to the freshness mechanisms above: local teams edit context, while shared profiles record each skill’s dependencies, maintainer, approver, and contributors. Because a context change can break downstream skills, dependency edges need the same review and version controls as code (WTF Is the Context Layer? (opens in a new tab), July 2026, vendor).

Agent traces supply a second freshness signal. A specialized harness reconstructs candidate context changes and sends each one to a maintainer for approval or rejection. This converts production failures and edge cases into governed updates instead of private agent memory. For an initial company brain, the talk recommends reconstructing relationships across business systems before adding retrieval through MCP, SQL, vectors, or hybrid assembly. These are Atlan’s practitioner claims, not controlled outcome evidence (WTF Is the Context Layer? (opens in a new tab), July 2026, vendor).

Finally, the architecture must thoughtfully balance the use of RAG with the capabilities of emerging long-context LLMs. These are not mutually exclusive approaches but complementary tools in the orchestrator’s arsenal. RAG excels in scenarios where knowledge is highly dynamic and changes frequently, as it retrieves the latest information at query time. Long-context models are better suited for scenarios where the knowledge is relatively static and foundational (e.g., a large technical manual or a set of company policies), as the entire corpus can be preloaded into the context window, eliminating retrieval latency (Scalable RAG Architectures: How Context Length, Model Choice, and Business Needs Drive Latency (opens in a new tab)). A sophisticated orchestrator can dynamically choose the best strategy based on the freshness requirements of the requested Context Product.

Conclusion and Strategic Roadmap

By adopting the “Context as a Product” paradigm and implementing a multi-layered cognitive architecture supported by a central LLM Gateway, a Context Catalog, and standardized protocols like MCP, an organization can build a scalable, governable, and highly capable AI ecosystem. The recommended polyglot approach to context storage—leveraging enterprise search, knowledge graphs, and advanced memory platforms—ensures that agents have access to the right tool for any given task. The ultimate goal of this architecture is to create a “cognitive context layer”—an intelligent system that can autonomously understand user intent, discover and retrieve the necessary context from a federated marketplace, and synthesize it into a coherent, secure, and accurate input for an LLM.

A phased implementation is recommended to manage complexity and deliver value incrementally.

Phase 1: Foundation

  • Objective: Establish the core platform and demonstrate initial value.
  • Key Activities:
    • Deploy an LLM Gateway (e.g., using LiteLLM) with basic observability and cost tracking.
    • Develop the initial version of the Context Catalog service with the defined metadata schema and API.
    • Build the first ingestion pipeline for a high-value, low-complexity source like Confluence documentation.
    • Onboard a pilot team with a simple RAG-based agent to validate the platform.

Phase 2: Scale and Federate

  • Objective: Expand the ecosystem and empower domain teams to contribute.
  • Key Activities:
    • Formalize the “Context Product Owner” role within the organization and provide training.
    • Develop SDKs and CI/CD templates to make it easy for other teams to create and publish their own Context Products, potentially standardizing on MCP for access.
    • Implement the advanced code context pipeline, including AST parsing and the creation of a Code Knowledge Graph.
    • Integrate the RBAC security model with the enterprise IAM system.
    • Onboard several new business and technical domains onto the platform.

Phase 3: Agentic Automation

  • Objective: Enable advanced, autonomous agentic workflows.
  • Key Activities:
    • Develop the sophisticated orchestration logic, allowing agents to dynamically discover and combine context from multiple products.
    • Implement advanced retrieval patterns like GraphRAG and integrate a dedicated long-term memory platform like Zep for conversational agents.
    • Introduce the Git-Context-Controller (GCC) pattern for agents performing long-running, multi-step coding tasks.
    • Enable Meta-Agents (Agenteers): Support the development of agents, inspired by frameworks like Archon, that can autonomously build new agents using the platform’s context products (Decentralised-AI - Archon - AI Agent Builder (opens in a new tab)).
    • Explore difficulty-aware routing and hybrid RAG/long-context strategies to optimize performance and cost at scale.

Appendix: Context Artifact Checklist

A working inventory of the artifacts that feed the layers above, grouped by domain.

Resources

Context operations