How Do Platform Engineers Build a Context Engine for AI Agents?
For Platform engineers building AI agent infrastructure · Based on Unblocked Context Engine Framework
// TL;DR
As a platform engineer tasked with building AI agent infrastructure, you need more than MCPs and vector stores. The Unblocked Context Engine Framework gives you a blueprint for building a system that ingests your org's full knowledge corpus, constructs a social graph from git history, performs exhaustive retrieval instead of naive RAG, resolves conflicts between contradicting sources, and delivers token-optimized research packets. This is the infrastructure that makes headless background agents viable—without it, every agent needs a human babysitter.
Why Does Naive RAG Fail for AI Coding Agents?
If you've set up a vector store, ingested your docs and code, and pointed your agents at it, you've built naive RAG. And you've probably noticed the agents still produce architecturally wrong code.
The root cause is satisfaction of search—a phenomenon from radiology where a searcher stops looking once they find the first plausible answer. Your agent hits the vector store, finds the first relevant chunk, and starts coding. It misses your team's factory pattern, the shared client library, and the Slack thread where the CTO clarified the correct approach.
Naive RAG gives the agent data access. It does not give it organizational understanding. That's the gap the context engine fills.
What Are the Core Technical Components of a Context Engine?
1. Unified Data Ingestion
Ingest both static sources (docs, architecture decision records, runbooks) and runtime sources (Slack/Teams conversations, PRs, tickets, deployment records). Static-only ingestion creates a stale context layer. Apply data governance rules at ingestion time.
2. Social Graph Construction
Build a graph from commit history and PR review data. Nodes represent engineers, sized by commit volume. Edges represent review and collaboration relationships. Tag nodes with service and codebase ownership. This graph is the pivot point for personalizing all retrieval. Open-source tooling can generate this procedurally from any git repo.
3. Exhaustive, Targeted Retrieval
Replace vector similarity search with structured retrieval that: (a) decomposes the agent's task into sub-queries, (b) traverses all data surfaces exhaustively, (c) applies the social graph to scope results, and (d) surfaces conflicts instead of returning the first match.
4. Conflict Resolution Layer
When sources contradict—code in main says one thing, a CTO's Slack message says another—the engine must settle it. Use social graph authority signals (seniority, role) and recency. Pass the resolution AND sources to the agent.
5. Token-Optimized Compression
Do not dump raw retrieval results into the context window. Reason across all results and compress into the smallest packet that gives the agent everything it needs.
How Should I Expose the Context Engine to Agents and Humans?
Expose it through multiple surfaces:
- MCP server for coding agent harnesses (interactive and headless)
- Slack/Teams bot for ask-engineering channels—auto-detect questions, score confidence, respond
- API endpoint for ticket enrichment and triage systems
- Incident management integration for real-time context during outages
One engine serving all surfaces multiplies your platform's leverage. Do not build separate systems for agents and humans—the same retrieval, conflict resolution, and compression logic serves both.
What Architecture Decisions Should I Avoid?
Do not cache answers. A cached answer starts going stale immediately. The same question asked 24 hours later may have a different correct answer because the codebase changed. Accept latency; serve fresh context.
Do not rely on context window size. A 1-million-token window full of unstructured data performs worse than a 5,000-token research packet. The engine must reason and compress, not dump.
Do not skip conflict resolution. When the engine silently picks one contradicting source over another, the agent produces unpredictable output. Surface conflicts, resolve them with authority signals, and explain the resolution.
Next step: Start by building the social graph from your git repos—it's the highest-leverage component and can be generated procedurally with existing open-source tools. Once you can pivot retrieval on engineer identity and codebase ownership, every other component becomes dramatically more effective.
// FREQUENTLY ASKED QUESTIONS
Can I use existing vector databases as part of the context engine?
Yes, but vector stores should be one retrieval surface among many, not the only one. The context engine must orchestrate structured queries across vector stores, graph databases (for the social graph), API calls to SaaS tools, and message history. The key is exhaustive retrieval across all surfaces—not relying on vector similarity alone, which triggers satisfaction of search.
How do I handle the latency of exhaustive retrieval without caching?
Optimize retrieval speed through better indexing, query decomposition, parallel traversal of data surfaces, and social graph scoping that narrows the search space. The social graph itself is a major latency reducer—instead of searching everything, you search the codebases and collaborator signals relevant to the specific requester and task. Accept remaining latency as the cost of accuracy.
What open-source tools can generate the social graph from git history?
Several tools can analyze git repos to extract commit authorship, PR review relationships, and file ownership patterns. Point them at your repositories to generate a graph of engineer nodes, collaboration edges, and service ownership tags. The specific tooling evolves rapidly, but the key requirement is extracting who authors what, who reviews whom, and mapping that to codebase areas.