Unblocked Context Engine Framework

// When should you use the Unblocked Context Engine Framework?

Use this framework when your AI coding agents are producing code that compiles but is architecturally wrong, when you are manually pointing agents to files or correcting them in doom loops, or when you are planning to move from an agentic IDE setup toward background/headless agents that must operate without human intervention.

// What do you need before building a context engine?

• code_repositoryrequired
  The codebase(s) the agent will work against — used to build the social graph and extract patterns.
• corporate_knowledge_corpusrequired
  All relevant organizational data sources: docs, Slack/Teams conversations, ticketing systems, SaaS tools, runbooks, etc.
• agent_task_or_queryrequired
  The specific task or feature request the agent needs to execute (e.g., 'make a new first-class integration to Zendesk').
• engineer_identity
  Who is asking — used by the social graph to personalize retrieval to the right codebases, PR history, and collaborators.
• data_governance_rules
  Permissions model — which data is private, which roles can see what — especially relevant at 20+ team members.

// What core principles make a context engine work?

// How do you build a context engine step by step?

1. 1

   Audit your current position on the Context Ladder

   Determine whether your team is at: (1) you are the context engine — manually prompting every session, (2) curated context layer — static markdown/config files agents read, or (3) context engine — dynamic runtime retrieval. This sets your starting point and gap.

2. 2

   Identify and ingest all data sources into a unified corpus

   Include static sources (docs, CLAUDE.md, runbooks, architecture decision records) AND runtime sources (Slack/Teams conversations, PRs, tickets, SaaS tool data). Do NOT rely only on static stores — they go stale the moment they are written. Apply your data governance rules at ingestion time to respect permissions.

3. 3

   Build a social graph of your engineering organization

   Use commit history and PR review data to map: who authors what, who reviews whom, which engineers own which services/codebases. Node size can represent commit volume; edges represent review and collaboration relationships. This graph is used as a pivot point — when a query arrives, the engine uses the requester's identity to select relevant codebases and collaborators. Open-source tooling (point at a git repo) can generate this graph procedurally.

4. 4

   Implement exhaustive, targeted retrieval — not naive RAG

   Do not use naive RAG (drop data in a store, let agent crawl it). Naive RAG triggers satisfaction of search — the agent stops at the first plausible hit. Instead, build retrieval that: (a) constructs a structured query from the agent's task, (b) traverses all relevant data surfaces exhaustively, (c) applies the social graph to scope retrieval to the right context, and (d) surfaces conflicts rather than silently picking one source.

5. 5

   Resolve conflicts explicitly before passing context to the agent

   When retrieved data contains contradictions (e.g., code in main vs. a Slack message from the CTO), the engine must settle the conflict. Use social graph authority signals (seniority, role) and recency to determine ground truth. Pass the resolution AND the sources to the agent so it understands why.

6. 6

   Deliver a token-optimized research packet to the agent before execution begins

   Compress all retrieved, conflict-resolved context into the smallest packet that gives the agent everything it needs — architectural patterns in use (e.g., factory pattern), existing services relevant to the task, who owns what, and any known constraints. Do NOT fill the context window with raw dumps. A smaller, precise packet outperforms a large noisy one.

7. 7

   Run the agent in Plan → Execute → Review mode, with context engine calls at each phase

   Phase 1 — Planning: agent calls context engine to build a correct, org-aware implementation plan. Phase 2 — Execution: agent executes plan; it can re-call the context engine mid-task for clarification. Phase 3 — Code Review: agent or human calls context engine to review output against organizational patterns. The engine is most valuable at planning and review.

8. 8

   Expose the context engine to all surfaces that need it — not just agents

   Surface the engine in: (a) coding agent harness via MCP, (b) team Slack/Teams ask-engineering channels (auto-detect questions, score confidence, respond), (c) ticket enrichment and triage, (d) incident management. One engine serving all surfaces multiplies leverage.

9. 9

   Do NOT cache answers

   Caching a correct answer is equivalent to writing docs — the moment it is written it begins to go stale. A cached answer to the same question asked 24 hours later may now be incorrect because the system changed. Accept the latency cost; do not serve stale context to agents or humans.

// What does the context engine look like in practice?

// What mistakes should you avoid when building a context engine?

• Confusing access with understanding — connecting MCPs or pipes to data sources does not give the agent organizational understanding; it only gives it the ability to retrieve data it does not know how to interpret.
• Using naive RAG as a context strategy — naive RAG triggers satisfaction of search, causing the agent to stop at the first plausible data point and miss the correct architectural pattern or existing service.
• Assuming a large context window solves the problem — even a 1-million-token context window cannot reason effectively over unstructured data dumps; it requires entities, relationships, and targeted retrieval to be useful.
• Relying solely on static context files (CLAUDE.md, agents.md) — static stores go stale and lack runtime signals; someone must maintain them, and they will always lag behind reality.
• Hiding conflicts instead of resolving them — when context sources contradict each other, letting the agent pick silently leads to unpredictable, sometimes catastrophic outputs; conflicts must be surfaced and settled explicitly.
• Caching context engine answers for latency optimization — cached answers become incorrect as the system changes; serve fresh context even at the cost of latency.
• Building the context engine only for agents — the same engine that serves background agents also delivers leverage in human-facing channels (ask-engineering, incident management, ticket triage); failing to expose it broadly wastes the investment.

// What are the key terms in the context engine framework?

Context Engine

A system that ingests an organization's full knowledge corpus (static docs, runtime data, conversations), reasons across all surfaces, resolves conflicts, applies a social graph for personalization, and delivers token-optimized context packets to agents or humans on demand.

Context Ladder

The progression of AI adoption stages: (1) You Are the Context Engine — humans manually supply all context; (2) Curated Context Layer — static files like CLAUDE.md that agents read; (3) Context Engine — dynamic, personalized, runtime-aware retrieval.

Satisfaction of Search

A phenomenon (observed in radiology) where a searcher stops looking once they find the first plausible answer, missing other critical findings. In agents, this means the agent stops retrieving context at the first relevant result, missing the correct pattern or existing service.

Social Graph

A graph of engineers, their authorship, review relationships, and codebase ownership, built from commit and PR history. Used as a pivot point by the context engine to personalize retrieval to the right codebases and collaborators for a given requester.

Curated Context Layer

The second rung of the Context Ladder — static repositories of organizational context (CLAUDE.md, architecture docs, runbooks) that agents can read. Better than nothing but limited by staleness and lack of runtime data.

Naive RAG

A retrieval approach that places a data store in front of an agent and lets it crawl for answers. Fails due to satisfaction of search and inability to reason across conflicting or distributed sources.

Token-Optimized Research Packet

The compressed, precisely targeted context output the context engine delivers to an agent before execution — containing only what the agent needs, not a raw data dump.

Targeted Retrieval

Exhaustive, structured retrieval that traverses all relevant data surfaces and uses the social graph to scope results — as opposed to naive RAG's first-hit-wins approach.

Conflict Resolution

The context engine's ability to detect when two sources contradict each other, apply authority signals (e.g., social graph seniority, recency) to determine ground truth, and pass the resolved answer plus its sources to the agent.

Babysitting

The state where a human engineer must continuously correct, redirect, and re-prompt an agent — pointing it to files, overriding wrong choices, re-feeding context after every session. The problem this framework is designed to eliminate.

Care and Feeding

The ongoing manual work of supplying an agent with organizational context it loses at the end of every session. Equivalent to babysitting.

Expert Graph

A component of the social graph that maps which engineers are the domain experts for which services, libraries, or areas of the codebase — used to route queries and inform code review.

// FREQUENTLY ASKED QUESTIONS