Context Broker Patterns captures the recurring structures that appear when context has to move cleanly across services, tools, and application logic.
As we’ve learned the hard way through the Artemis Lab portfolio, context handling is usually improvised—even when it determines your system’s fundamental reliability. If you simply point an LLM at an API and say “good luck,” you are not doing software engineering; you are gambling with syntax.
To stop gambling, we document repeatable patterns for structured context exchange. Here are three core patterns we’ve implemented across the artemis_owl portals (specifically the steering and kestrel-scoop workspaces) to keep agents from improvising their way into a data breach.
Pattern 1: The Trust Gateway (Policy Injection)
The Problem: An AI agent decides it needs to execute a tool (like spinning up a database). If you hardcode the permission logic into the agent’s prompt (“Please don’t provision expensive cluster sizes”), the agent will politely ignore you the moment it gets distracted.
The Broker Pattern: Instead of trusting the agent, we use a Gateway. All tool execution requests from the agent are intercepted by a standalone policy engine (like Open Policy Agent). We map the agent’s contextual state into a structured JSON payload, hand it to the Gateway, and have the Gateway make a strict Allow/Deny decision based on version-controlled Rego policies.
If you want to see this running in the wild, look at the Enterprise DecisionOps Control Plane in the steering repo. It decouples the AI’s “intent” from the enterprise’s “authorization,” forcing the agent to operate within the speed limit.
Pattern 2: The Evidence Append Loop (Traceability)
The Problem: Autonomous systems do things while you are sleeping. When you wake up, an auditor asks why a production cluster was modified at 3 AM. If your only answer is “the LLM thought it was a good idea,” the audit will not go well.
The Broker Pattern: The context broker must emit side-effects.
When the Trust Gateway authorizes an action, it doesn’t just execute the tool. It fires an immutable decision_trace event into a Kafka stream, and appends the final execution result as an evidence event. We cross-wire these events with OpenTelemetry (OTel) traces.
This means every time a context boundary is crossed, the broker is actively building a cryptographically signed Audit Packet. You don’t have to piece together what the AI was thinking; the broker already zipped up the proof and handed it to you.
Pattern 3: The Context Hydrator (Just-In-Time Context)
The Problem: You have a 128k token window, which sounds infinite until you try to stuff your entire enterprise codebase into it. If you give an agent too much generic context, it hallucinates. If you give it too little, it asks you to do the work yourself.
The Broker Pattern: The broker intercepts the incoming task and automatically “hydrates” it with exact operational boundaries before it hits the model. Using the Model Context Protocol (MCP), the broker fetches only the specific RAG embeddings, file schemas, or environment variables relevant to the immediate query. By structuring this hydration dynamically, the prompt payload stays lean, token costs don’t require taking on venture capital, and the agent stays strictly focused on the localized task.
This repository of patterns serves as a vocabulary and design substrate for our continued prototyping across the Artemis architecture.