# Mergeable by default: Building the context engine to save time and tokens

Peter Werry & Brandon, Unblocked | AI Engineer Europe 2026 | 1:41:25

Source: https://www.youtube.com/watch?v=5ID22ACI7IM
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/mergeable-by-default-building-the-context-engine-to-save-time-and-tokens
Published: 2026-05-03
Tags: agents, context-engineering, rag

## TL;DR
- A context engine gives agents the organizational history, decisions, expertise, and permissions they need for a task.
- Naive RAG, connected MCP servers, and larger context windows do not make an agent understand why a system works the way it does.
- In one task, adding the context engine reduced execution time from 2.5 hours to 25 minutes and token use from 21 million to 10 million.

## Summary
Peter Werry describes context engineering as supplying an agent with exactly the information needed for a task, including organizational practices, past decisions, expert knowledge, and access restrictions. He argues that document search and MCP connections provide access without understanding. Agents can stop after finding a plausible answer, miss important history in Slack or incident reports, and repeat approaches that the team already rejected. Unblocked's approach combines procedural knowledge graphs, vector retrieval, runtime tools, distilled memories, expert profiles, conflict handling, and user-specific relevance. Werry is candid about early mistakes, including prioritizing access over understanding, hiding unresolved conflicts, and caching old answers. He presents engineering planning, review, triage, incident management, ticket enrichment, and support as practical uses. The second part is a workshop in which attendees build a local social graph from repository history to identify teams and code experts.

## Key ideas
### Context engineering gives agents the experience that engineers build over time
[01:21](https://www.youtube.com/watch?v=5ID22ACI7IM&t=81s)
Werry starts with an agent at "ground zero," with no knowledge of the codebase or organization. The agent normally searches the repository before working, while a human supplies missing background and corrects mistakes. Engineers build useful context through code exploration, mentors, incidents, outages, and the reasons behind past decisions. That experience teaches them what questions to ask and where to look when something goes wrong. A context engine should give agents that accumulated understanding, while leaving out information that does not matter for the current task.

### Humans become the bottleneck when they manage many agents
[05:45](https://www.youtube.com/watch?v=5ID22ACI7IM&t=345s)
As teams move from curated context toward parallel and background agents, people spend more time switching between tasks and keeping each agent oriented. Werry says autonomous agents cannot work effectively without a system that understands how the code and organization operate, including the motivations behind historical changes. Without this context, an agent can enter a "doom loop," repeatedly making corrections, or finish a task in YOLO mode with a solution that is entirely wrong.

### Access to data does not give an agent an understanding of its relationships
[08:49](https://www.youtube.com/watch?v=5ID22ACI7IM&t=529s)
Teams often try to supply organizational knowledge through a RAG system or a collection of MCP servers. Werry says this gives an agent access to information without explaining how the information relates, how it came to exist, or why it is still valid. A context engine has to connect sources such as code, pull requests, documents, planning tools, and conversations. It also has to understand decisions and practices that are not expressed as direct links between records.

### Search can stop at the first plausible answer and miss the important history
[13:43](https://www.youtube.com/watch?v=5ID22ACI7IM&t=823s)
Werry uses "satisfaction of search," a term from radiology, to describe an agent finding something that appears to explain a problem and then stopping. In engineering, the missing evidence may be in an old Slack conversation, an incident report, or a rejected earlier approach. Code that compiles is only the baseline. A useful agent also needs the user's intent, knowledge of what the team tried and rejected, and the history that explains why the current code looks as it does.

### A context engine must resolve conflicts and admit when it cannot
[15:29](https://www.youtube.com/watch?v=5ID22ACI7IM&t=929s)
The system Werry describes tracks a person's team, collaborators, experts, permissions, and the decisions behind the current code. It weighs conflicting sources instead of assuming that the newest document or the main branch is always correct. Current code can explain where the system has been, while a planned change may explain where it needs to go. When the engine cannot resolve a conflict, it should expose that uncertainty to the agent and learn from the user's correction.

### Personal relevance reduces retrieval noise
[21:12](https://www.youtube.com/watch?v=5ID22ACI7IM&t=1272s)
Werry recommends tailoring retrieval to the person and task. One signal is the repositories where someone contributes most often, measured through pull requests. A retrieval system can search those focused repositories deeply, search the rest of the codebase more broadly, and bias selection toward the areas where the person is likely to work. This prevents large organizations with many repositories from filling an agent's context with technically relevant material from unrelated teams.

### Expert profiles help agents choose where to look next
[1:00:39](https://www.youtube.com/watch?v=5ID22ACI7IM&t=3639s)
The social graph is more than a directory of experts. Werry explains that the context engine distills what people have worked on, where they sit in the organization, and the decisions expressed in their Slack conversations and pull-request comments. An agent working in an unfamiliar code area can receive the relevant expert's accumulated knowledge as a starting point. That expert context helps direct later semantic search, memory retrieval, and other steps in the agent's loop.

### The largest gains come from planning and preventing correction loops
[25:43](https://www.youtube.com/watch?v=5ID22ACI7IM&t=1543s)
Werry says planning is where context engines provide the biggest benefit, followed by review. They can also enrich tickets, triage production issues, connect incidents with monitoring signals and past discussions, and answer engineering support questions. In the cited task, an agent without the context engine took 2.5 hours and used 21 million tokens. With it, the task took 25 minutes and used 10 million tokens. The difference came largely from avoiding repeated corrections after a wrong first attempt.

## Notable quotes
- "Context engineering is kind of the art of supplying all the context that you need and most importantly, none of the context that you don't need in a highly optimized way." (02:02)
- "Access doesn't equal understanding." (08:29)
- "A context engine understands who you are, what team you work on, who you work with, who the experts are in your organization, and what the decisions were that led up to the current iteration of your code base." (15:29)
- "The more high-quality correct, high signal context you have up front, the better every single thing the agent's going to do until it says it's done." (32:26)

## Tools & references mentioned
- Unblocked
- Brandon
- Basem El-Dath
- Cursor
- MCP
- Mythos
- Gemini
- Slack
- Microsoft Teams
- Notion
- Confluence
- Claude
- Claude Code
- GitHub
- Sentry
- Datadog
- Sourcegraph
- GraphRAG
- Andrej Karpathy
- Copilot
- VS Code
- Codex
- Composio
- Boris Cherny

## Who should watch
- You are building agent workflows that repeatedly search across code, tickets, Slack, and documentation before producing a change.
- Your agents can access company data but still miss past decisions, repeat rejected approaches, or need several rounds of human correction.
- You need to reason about permissions, expert knowledge, or organizational history before connecting autonomous agents to engineering work.

## Related talks

- [How to Generate Mergeable Code with a Context Engine](https://aietalks.com/talks/how-to-generate-mergeable-code-with-a-context-engine) (Peter Werry, Unblocked, 18:36)
- [Context Engineering: Connecting the Dots with Graphs](https://aietalks.com/talks/context-engineering-connecting-the-dots-with-graphs) (Stephen Chin, Neo4j, 26:50)
- [Context Engineering in 2026](https://aietalks.com/talks/context-engineering-in-2026) (Louis-François Bouchard, Omar Solano & Samridhi Vaid, Towards AI, 1:03:26)
- [Building Agents Is Trivial Now, Context Is the Next Frontier](https://aietalks.com/talks/building-agents-is-trivial-now-context-is-the-next-frontier) (Jeff Ng, Unblocked, 13:22)
- [How We Solved Context Management in Agents](https://aietalks.com/talks/how-we-solved-context-management-in-agents) (Sally-Ann Delucia, Arize, 16:17)