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

When a coding agent starts a task, how does it know which code matters, what the organization expects, and why the existing implementation looks the way it does? Usually it begins by searching the repository. Context engineering supplies the information needed to complete the task while excluding information that distracts from it. Peter Werry and Brandon approach that problem through a context engine, then build one component of it in the workshop: a graph of engineering collaboration and expertise.

The developer has traditionally performed this work manually: copy in the issue, explain the constraints, inspect the result, and redirect the agent when it misunderstands. Sometimes the correction is as basic as pointing it away from JavaScript and toward the Python source. Each correction supplies context that was missing when the agent chose its approach.

A new employee acquires the same knowledge more gradually. They explore the code, find a mentor, and eventually experience incidents and outages. Those experiences preserve more than implementation details: they explain why a team rejected an apparently reasonable approach or retained an awkward dependency. Over time, the employee learns which questions to ask and where to look. That accumulated organizational experience is what the context engine needs to make available to agents.

Werry traces this progression using an adoption curve he credits to Bassem Eldef. In his recollection of the early autocomplete era, context windows were roughly 8K tokens, so tools concentrated on the code immediately before and after the cursor. Abstract syntax trees, language servers and caller retrieval subsequently brought more structure into that local context.

The next stages expand from an agent in an IDE to parallel agents connected through MCP and skills, then toward background agents and agent teams. The human cost expands too: managing several tasks means repeatedly switching between their assumptions, histories and unfinished decisions. Moving that work into the background requires a system that already understands the code, the organization and the motivations behind earlier changes.

Werry invokes the promise of Mythos as an example of rising coding capability, while acknowledging that he has not yet tried it. His practical concern is what happens when a capable agent lacks context: it can complete an entire task incorrectly, leaving the developer to repair successive stages in a corrective loop. Connecting RAG or a collection of MCP servers gives the agent access to information, but does not by itself explain the relationships among sources or the reasons behind them. Access does not establish understanding.

The first concrete example is a migration to Anthropic's adaptive thinking. The older integration supplied an explicit token budget to control the thinking window. An agent connected to MCP servers implemented the new behavior but removed code that still supported legacy dependencies. It could find the implementation without understanding why those older paths remained necessary.

With the context engine connected, Werry reports that the agent recovered those reasons, changed the appropriate locations and preserved compatibility for callers using the old behavior. The example concerns that historical explicit-budget migration; the current thinking-control documentation describes a later API surface. The engineering requirement here was to introduce adaptive thinking without breaking existing consumers.

Three common approaches leave important parts of the problem unresolved:

With naive retrieval, an agent can search repeatedly, consume its token budget and reach compaction without finding the decisive information. In a large organization, broadly relevant results can come from the wrong repository or a team with different conventions. Personalization is therefore part of retrieval quality, not merely a presentation feature.

The long-context discussion turns to Gemini and needle-in-a-haystack retrieval: if you already know what you want, a model may locate it inside a large document. Werry distinguishes that from reconciling different sources and choosing the right organizational action. He also acknowledges subsequent model improvements. The useful distinction is between retrieving an item and understanding its significance, rather than a fixed ceiling on how many tokens a model can process.

Even a much larger window leaves a selection problem. An organization's material may exceed the available window, and fitting more of it into a prompt does not decide which statements are current, which are mistaken, or which apply to the task. Werry extends the thought experiment to windows containing tens of millions of tokens; the enduring design question is how to select trustworthy evidence, whatever the capacity available.

The opposite failure to endless searching is stopping too soon. Werry borrows satisfaction of search from radiology: finding one explanation for a patient's symptoms can cause a reader to stop examining the image and miss another abnormality. An agent can similarly find a plausible answer in Notion, Confluence or code and proceed, while the decisive constraint sits in a Slack conversation or an incident report.

Compiling code is only the visible tip of this problem. Below it are the user's original intent, approaches the team already rejected, experiments that failed, and information that disappeared when code or documents were deleted. Recovering those constraints requires history as well as the current repository.

A context engine needs to know who is asking, which team they belong to, who they collaborate with, and who understands the relevant code. It also needs to distinguish resolvable conflicts from disagreements that require human input. When it cannot determine which evidence should govern the task, it should expose the conflict to the agent and learn from the user's clarification.

Permissions must follow the evidence. Werry uses private Slack channels as the example: Unblocked may use their contents only for a questioner who already has access, and an answer using that private information remains private to that person. Repository restrictions and secret projects require the same discipline. Delivering the right context includes delivering it to the right person.

The architecture has many inputs and many outputs. Planning tools, documents, conversations, source code and pull requests feed the engine. Coding agents consume its output through MCP or a CLI; applications can use an API; code review integrates with source control; messaging integrations deliver answers inside conversations. These surfaces share a need for timely, economical context.

Building relationships starts with easy links, such as a Slack message containing a PR URL. Understanding a practice requires more work. Historical PR comments can be distilled into their core guidance, repeated patterns combined into organizational memories, and those memories loaded when an agent encounters similar code. That transforms a collection of review comments into reusable knowledge about how the team works.

Conflict resolution evolved through failed shortcuts. Initially, the team preferred recent material. That failed when a newer document or conversation misstated the system's behavior. Preferring code on main improved matters, but current code cannot always answer a question about intended future behavior. Historical evidence helps identify what to avoid; expert discussions can explain where the system is meant to go.

Targeted retrieval and personal relevance work together. PR submissions and contribution history identify the repositories a person usually works in. The engine can retrieve deeply from those repositories, retrieve more broadly elsewhere, and bias selection toward the focused set without excluding useful evidence outside it. Alongside unified context, conflict resolution, governance and token optimization, this completes the requirements shown on the slide.

In an initial larger-task comparison, Werry reports that the baseline repeated mistakes whose history it had failed to recover, while the context-enabled run avoided them. He explicitly warns against trusting the quality scores generated by Claude for the comparison. The later workshop discussion returns to the task, its access controls, and the time and token accounting.

Three implementation lessons follow. First, providing a knowledge graph and integration-specific tools did not make an agent understand the organization. Second, applying simplistic conflict-resolution rules hid disagreements the engine could not actually settle. Those unresolved cases needed to become visible so that corrections could improve future behavior.

Third, Werry warns against caching a completed answer and serving it again for a similar question. Code, documents and the reasons behind decisions change. Feeding old generated answers back into later answers creates another risk: mistakes become part of the next prompt and reinforce themselves. Reusable organizational memory needs to remain grounded in evidence rather than becoming an accumulation of previous model responses.

The workflows differ in where that evidence pays off:

• Planning and review: Werry identifies planning as the strongest intervention point. At review time, organizational motivation supplements checks for broken behavior and security issues.
• Ticket enrichment: An agent fills gaps in a feature request using existing organizational context.
• Production triage: Related past issues give the agent a starting point for investigating a new problem.
• Incident management: Sentry and Datadog signals connect to code, previous incidents and Slack discussions.
• Engineering support: A context engine answers product questions from customer-success and sales teams inside shared support channels.

The common operation is to bring previously scattered evidence into the task before an engineer has to reconstruct it manually.

Teams package that access in repository-hosted skills, a ticket-enrichment action taking an issue ID, or a workflow that prepares an incident timeline. They also connect Claude Code to the engine in CI, giving background work an API credential. Unblocked provides a dedicated review component as well, so the CI pattern is not limited to building a reviewer.

One review demonstrates what organization-specific guidance looks like. Unblocked asked Richie to reduce duplicated tests. The recommendation came from a practice distilled from earlier PRs—and Richie himself had supplied the earlier guidance. The system had recovered a team's convention well enough to reflect it back to its author.

Another demonstration compares a long baseline agent transcript with a shorter context-enabled one. The presenters asked Claude to analyze both; its assessment favored the context-enabled plan for shipping and treated the other as a prototype missing previously discussed requirements. Werry's target is that generated code should feel like it came from a colleague with years of experience on the team.

The first audience question asks for the concrete artifact: is a context engine an installed program, a hosted API, or an MCP server? Unblocked exposes several surfaces over the underlying system. Agents use MCP or CLI access; people can ask questions in a dashboard personalized to their identity and recent work; Slack supports conversational and automatic answers. There is no single interface that defines the engine.

Karpathy's LLM Wiki, decision traces and context graphs enter the discussion as possible components. A compiled wiki can exploit an agent's ability to traverse a filesystem-like structure. But its usefulness still depends on how it represents organizational memories, practices and experts—the points from which retrieval can branch toward the right evidence. Werry also limits the product's scope: engineering integrations can help business users understand product behavior, but at the time of the talk, the absence of a Salesforce integration limited sales-domain coverage.

Synthesis raises a harder permission question than retrieving an individual document. A summary may combine information from several sources with different audiences. Werry's starting point is compartmentalized synthesis: build knowledge inside boundaries such as a repository, then correlate it with material available to the intended audience, such as public Slack discussions. When synthesized information crosses boundaries, attach group identifiers and check them during retrieval.

GraphRAG makes the risk easy to see because it builds summaries at multiple levels of a graph. A higher-level summary can combine facts that originated under different access rules. Permission-aware compartments and retrieval checks are therefore necessary design work; hierarchical summarization itself does not guarantee that an answer respects the original boundaries.

Underneath retrieval, Werry describes a combination of procedural and model-based operations. The engine first builds entity relationships, which he compares to a PageRank-like structure. It then vectorizes data, uses LLMs to distill material such as PR history, and exposes procedural tools for runtime fetching. Conflict handling also happens at two stages: ingestion tags relate and rank evidence, while a runtime judge receives criteria for resolving the conflicts that remain relevant to the current request.

An audience member asks how a system handles organization-specific meanings—for example, different definitions of revenue. Werry points to the references delivered with an answer, both to the human and to the agent. A user can reply with a correction or mark the answer as unhelpful and explain why. This remains a partly manual process, but repeated feedback creates signals the system can use.

Werry reports hundreds of feedback items from teams of 20–30 people, and hundreds more from teams of 100–200, without specifying a collection period. He emphasizes that natural-language correction is an interaction people readily understand.

The workshop turns to a smaller, inspectable component: the Social Graph Builder. Participants first join the workshop Slack workspace and its AI Engineering London channel, post their GitHub identity for an invitation, and enter the GitHub organization. That organization access is a prerequisite for the workshop's Unblocked link. The shared repository is the target for collaborative changes.

The tool analyzes repository activity to show who reviews whose PRs and where expertise is concentrated. Werry introduces the graph-building workflow as local analysis with no uploads. The later public version makes the boundary more specific: graph storage is local, while optional Anthropic labeling can send member names and code-area metadata. That optional labeling path should not be treated as offline processing. The first demonstrated view is a reviewer–author relationship grid for Unblocked.

The demonstration then moves from individual relationships to inferred teams. Its history starts at the beginning of 2025; Werry recommends a shorter range for a first run because a long scan is slow. AI is optional and used to label teams. Without it, labels come from the code areas members work on most. The experts view groups people by project area and path; coverage reflects both active contributions and the presence of a strong contributor. An interactive graph then shows team areas and their major contributors.

At the workshop, the repository is private and described as MIT-licensed, with public release planned. Participants are invited to submit changes, with Unblocked acting as a reviewer. Prepared issues provide starting points, and the displayed MCP instructions explain how to connect Claude Code or another agent to the context engine.

A question about asynchronous agents leads to a qualitative usage breakdown. In the usage view Werry shows, Claude Code leads, followed by Cursor; Claude Desktop appears more often than he expected, while VS Code and Codex form smaller components. A catch-all category captures other traffic. These labels do not separate interactive from autonomous use: Claude Code traffic can include CI and PR-triggered work.

Another question asks why exploratory agents plus memory cannot reconstruct the same graph. Werry agrees that the social graph itself can be compact. The cost is producing it: an agent starting from scratch would need to reconstruct the graph-building algorithm, run it, and distill the result. Precomputing that component avoids repeatedly rediscovering the same structure.

The more important role of the graph is as a retrieval pivot. Knowing the expert for a code area points the engine toward that person's past work, organizational role, Slack decisions and PR comments. Werry calls the distillation step bottling the expert. For a new employee working in unfamiliar code, the resulting context provides three complementary layers:

The expert material helps the agent decide where to search next, rather than merely adding a person's name to the prompt.

Running the workshop project follows a deliberately small procedure:

1. Point Claude Code at the repository and ask it to read the README.
2. Specify the repository to analyze.
3. Bound the scan with a date range or PR limit—for example, the last 300 PRs.
4. Ask the agent to bootstrap and run the project.

The bound matters: an unrestricted history scan can take a long time. The presenters report that the repository instructions are sufficient for an agent to get the application running.

The roadmap discussion returns to autonomous agents. Werry wants finely tuned context for those workflows; a presenter describes the future load using an IOPS analogy, with agent swarms repeatedly requesting and consuming context. An audience question about traces, runbooks and embedded business knowledge broadens the use case, but the response stays task-driven: connect an agent to the engine, ask it to perform the work, and retrieve the evidence needed for that task.

The near-term investment is in API and CLI access, HTTP endpoints and an interaction layer that supports many humans and agents. Slack Q&A, the dashboard and code review remain first-class applications on top. The workshop environment has a separate lifecycle: the presenters plan to keep it available through the end of the week, then release the project publicly with contributor credit. Participants can clone it, launch an agent in the directory, and request bootstrap and launch.

A later question clarifies the earlier experiment's controls. The baseline was Claude with vendor MCP servers, including GitHub and Slack. The other condition was Claude with Unblocked only. The presenters say the prompt and underlying data access were the same; they do not describe both conditions as having an identical set of MCP tools. This distinction matters: the comparison changes how organizational evidence is retrieved and prepared, not simply whether the agent can access it.

The initial expert-inference implementation compared PR contribution counts with review counts. Werry says that simple approach produced inaccurate team clusters. The workshop algorithms occupy a middle ground; the full product adds richer evidence. A minimal Python aggregation illustrates the raw reviewer-to-author signal before that richer inference:

from collections import Counter

reviews = [
    {"pr": 101, "author": "Asha", "reviewer": "Ben"},
    {"pr": 102, "author": "Asha", "reviewer": "Ben"},
    {"pr": 103, "author": "Ben", "reviewer": "Cara"},
    {"pr": 104, "author": "Cara", "reviewer": "Asha"},
]

edges = Counter(
    (review["reviewer"], review["author"])
    for review in reviews
    if review["reviewer"] != review["author"]
)

for (reviewer, author), count in sorted(edges.items()):
    print(f"{reviewer} -> {author}: {count}")

In this small example, Ben has reviewed two of Asha's PRs. That establishes a collaboration signal, but it does not establish either person's team or expertise by itself.

The product also associates contributors with vectorized source code. People working in nearby code clusters can then be related through that proximity. A further LLM layer distills historical work and Slack conversations and weighs those signals against the procedural graph. This matters for people who work across teams: a single cluster assignment in the workshop graph can obscure their broader role.

Slack and Teams need different signals because messages lack the review relationships available in source control. The engine can summarize a channel's subject, vectorize that summary, and associate it with frequent contributors. But activity alone is insufficient. Werry's counterexample is a highly vocal junior engineer: frequent messages do not necessarily carry more expertise than a quieter person's occasional intervention. Relating discussion back to source control—what PRs followed, and which merged—helps assess impact rather than volume.

The intended contribution flow is to create a branch and open a PR, without pushing directly to main. Participants discover that they cannot perform the expected operations, and forking may also be disabled on the private repository. Unblocked attempts to answer the access question in Slack, but the presenters still have to investigate the actual permissions.

They identify a mismatch involving direct assignments rather than the expected organization assignment, open Settings and Collaborators, and add the necessary access. After announcing write access, they ask participants to validate it. Real PRs then begin arriving, and the first approved PR is announced.

The presenters query Unblocked in Slack about an accepted PR and react positively to its response. They also notice that the answer is visible only to the questioner. The live sequence connects the workshop's contribution, review and messaging surfaces without exposing the PR's contents or the answer's wording in the spoken discussion.

A consultant asks to see the actual SaaS product: how customers interact with sources, conflicting information and compliance concerns. After an initial misunderstanding about the workshop graph application, Werry shows the dashboard for asking questions about code and the organization. He describes an internal source mark engine that tracks code changes over time, including moves between files. Meaningful demonstrations require connected organizational data, so he suggests a vendor demo or connecting the product to one's own organization; he also describes a full-product enterprise trial.

The feedback controls make the correction path concrete. A user can continue the discussion or select Not Helpful and explain the problem. In the displayed answer, those controls sit below reference links and a diagram syntax error. The feedback mechanism is useful precisely because an answer can contain something the user needs to correct.

Asked whether feedback merely adjusts weights or confidence scores, Werry gives a more specific answer: it constructs task memory. Repeated correction signals are distilled, and the expert graph helps weight their sources. In his description, a correction from an established expert receives more weight than one from a new engineer whose trustworthiness the system has not yet established.

The stored representation differs from what the agent sees. Memories live in database tables and draw on multiple sources; at runtime, the system hydrates them into an agent-facing form presented as files. Retrieval tools remain available, but the engine cannot leave all memory hydration to the agent. Some of that material is seed context: it must be supplied before the agent can reliably choose its next retrieval step. Expert context provides that initial direction.

Asked about an official benchmark, Werry acknowledges internal benchmarks but does not identify a public evaluation for this organizational-context problem. He invokes Boris Cherny's discussion of Claude Code evaluation and a colloquially named Shitpost benchmark to explain the importance of user sentiment. Werry reports a sentiment score around 60 on a scale from −100 to 100, without specifying the measurement protocol. He describes its normalized value as roughly 0.75–0.8.

Satisfaction can reflect many things: less back-and-forth, fewer mistakes, or faster completion. The team also measures timing and is working to reduce response latency. For autonomous tasks, however, a slower context response can be worthwhile if it prevents a much larger implementation detour. The relevant comparison is the time to a correct completed task, including the work caused by a bad initial decision.

Werry roughly estimates context collection at about 90% of an agent task's time; he does not supply a measurement protocol for that estimate. He then distinguishes input processing from output generation: in the team's experiments, output tokens were a major performance cost, while input processing and time to first token were comparatively well optimized. Supplying focused context should therefore reduce unnecessary output loops as well as retrieval work.

The presenters identify the ambitious comparison task as implementing Anthropic's adaptive-thinking mode. The context-enabled run completed without human corrections. In the baseline, the first result was wrong, subsequent results still needed correction, and four corrective loops accumulated into the reported wall-clock time.

These are results from the presenters' single task comparison. The baseline duration is also stated as 2 hours 25 minutes during the answer; no repeated-trial protocol is supplied. The mechanism behind the difference is the avoided rework after an initially incorrect implementation.

An audience member asks for a like-for-like token comparison with Composio on Slack retrieval, but the presenters do not provide one. They return to the same migration task: the presenters report 21 million total tokens without the context engine versus 10 million with it, with avoided correction loops accounting for part of the reduction. He expects little benefit for a generic task such as centering a div; the intended use is feature and bug-fix work whose correctness depends on organizational knowledge.

A late question about the underlying RAG technology moves to a side conversation. The next recorded architecture discussion concerns freshness. Many integrations update through webhooks; integrations without them use cron-based polling. Incoming changes require frequent updates to the graph data, but that does not mean rebuilding everything from scratch.

The social graph supports incremental updates. In an established organization, one new change is unlikely to transform the expertise graph, although a brand-new organization has less history to stabilize it. Different derived artifacts also deserve different update schedules: Werry says best-practice distillation runs roughly weekly because those practices change more slowly than the underlying activity stream.

The final audience question brings the engine back to organizational trust: what does it mean to introduce another processor holding code and internal knowledge? Werry says privacy discussions happen at the organizational level and describes relatively little friction in his experience, while acknowledging more sensitive government and banking environments. He also observes that Slack discussions can contain reasoning organizations consider more sensitive than source code itself. He refers to a customer-data protection white paper, but does not specify retention periods in this answer.

Unblocked offers an on-premises option for sensitive environments, according to Werry, but he recommends cloud deployment because integrations and software patches can be updated more readily. His example is a network-isolated bank: administering the platform requires either vendor staff working inside that network or training the bank's own administrators. The deployment choice therefore includes an ongoing operational responsibility—keeping integrations, derived context and the platform itself maintained inside the organization's security boundary.