Context Engineering for Engineering Teams: What Goes In, Who Owns It, and the Tools (2026)
The discipline is deciding what a coding agent knows before it acts: code, PRs, tickets, docs, chat, incidents. Here is who owns each source, how it scales past a few repos, and which tools automate it.
Key Takeaways
• The discipline covers five jobs: source curation, retrieval, conflict resolution, permissions, and freshness. Retrieval is the only one a vector database does for you.
• For coding agents the inputs are code, pull requests, tickets, design docs, chat threads, and incidents, and each has a different natural owner on the team.
• Scale is the test. Cloudbeds runs 987 repositories and Advidi about 300; the largest Unblocked customers run over 100,000. Per-repo instruction files do not survive that.
• Unattended cloud agents raise the bar because nobody is at the terminal to course-correct, so the context an agent starts from sets the ceiling on what comes back.
Context engineering is the discipline of deciding what an AI system knows before it acts. That means choosing which sources count as truth, how conflicts between them get resolved, who is allowed to see what, and how fresh the evidence is. A context engine is the system that automates that discipline for a whole team rather than for one developer's session. Most advice under this name is prompt tips for a single terminal. This page covers the team version: what goes in, who owns it, how it scales, and which tools do the work.
Picture a platform engineer at a 300-person company who starts a cloud agent on Friday afternoon to move the billing service off a deprecated HTTP client. The agent reads the README, which still documents the old client, and ships a tidy pull request on Monday morning that deepens the dependency. The decision to retire that client lives in a Jira ticket, a Confluence page nobody updated, and a Slack thread where a staff engineer explained why. None of that reached the agent. Nothing about the prompt caused the failure; the agent started from the wrong evidence.
What is context engineering?#
Anthropic's engineering guidance defines the work as the set of strategies for curating and maintaining the optimal set of tokens during inference (Anthropic Engineering). It also names the failure the work prevents: context rot, where a model's recall degrades as the window fills. The target is the smallest possible set of high-signal tokens for the task at hand.
In practice that means five decisions, made once and kept in force. Which sources qualify as ground truth. How the relevant slice gets retrieved for a given question. Which source wins when a README, a merged PR, and a Slack thread disagree. Who is allowed to see each piece, enforced at retrieval time rather than in the UI. And how the system knows a source has gone stale. One developer can do all five by hand for one repository and one afternoon. A team cannot, which is why the discipline needs a system behind it. Unblocked, the context engine for engineering, is one such system; the full framework is in the guide for engineering leaders.
Context engineering for enterprise coding agents: what goes in the context and who maintains it?#
Adoption is settled. The Stack Overflow 2026 Developer Survey, with 30,903 responses, found 80% of developers use AI at least an hour a day (Stack Overflow, 2026). It also found 48% trust its output only for low-risk, easily verifiable tasks. Trust follows evidence, and the evidence a coding agent needs comes from six places.
What goes into the context?#
Code is the obvious input and the least sufficient one. The decisions that explain the code live in pull request reviews, Jira or Linear tickets, design docs in Confluence or Notion, Slack and Teams threads, and incident timelines. A deprecation is a code change plus a ticket plus a thread; an agent that only sees the first will reintroduce what the other two retired. The same survey found 93% of developers consider citing sources important when AI answers, which only works if those sources were in the context to begin with.
The first instruction in every agent project file is: before making any changes, gather context. That pulls from Jira, Confluence, and Slack via Unblocked — because that's where most of our knowledge actually lives, in threaded discussions. I set it up the day it was announced and now I don't even think about it. I just get the relevant information.
Andrei Antanovich — Software Engineer, Waste Logics
That is the discipline in miniature: one instruction, one retrieval step, every source.
Who maintains each part?#
Ownership follows lines most teams already have. The platform team owns connectors and indexing: which repositories, which Slack channels, which Jira projects, and how often each refreshes. Developer experience owns the surfaces where context reaches people and agents: IDE, CLI, PR review, chat. The AI or ML team owns retrieval quality and the evaluation set that catches regressions. Security owns the permission model and the audit trail. That concern is live: Temporal's State of Development 2026 found 39.5% of engineers name security as the main blocker to truly autonomous agents (Temporal, 2026). Two jobs fall between those owners and fail first: conflict resolution and freshness. Assign them to a named person.
What are the context engineering tools for engineering teams, not prompt tips?#
The tools fall into four buckets, and most advice online covers none of them. GitKraken's July 2026 report, drawn from 554 developers and engineering leaders, found 96.4% of teams have adopted AI coding tools while 39% have no way to measure the impact (GitKraken, 2026). Measuring starts with knowing what the agent was able to see.
Unblocked is built around six requirements a context engine has to meet: unified context across code and non-code sources, conflict resolution between them, targeted retrieval, governance, token optimization, and personalized relevance. Enterprise search covers documents, agent memory covers one agent's own history, and DIY RAG gives you the plumbing. The table scores each approach on the six.
| Tool or approach | Unified context | Conflict resolution | Targeted retrieval | Governance | Token optimization | Personalized relevance | Best for |
|---|---|---|---|---|---|---|---|
| Unblocked (context engine) | Yes, code and non-code | Yes | Yes | Yes, source-level permissions | Yes | Yes | Engineering teams grounding coding agents |
| Glean (enterprise search) | Partial, documents and chat | No | Yes | Yes | Partial | Yes | Org-wide document search |
| DIY RAG (Pinecone, Weaviate) | No, you wire each source | No | Partial | No, you build it | No | No | Teams with capacity to build and run their own index |
| Mem0 or Letta (agent memory) | No, one agent's history | No | Partial | No | Partial | Yes, per agent | Persisting what an agent learned across its own sessions |
Memory tools get mistaken for context engines. Mem0 and Letta persist what one agent learned in earlier sessions, which is a different problem from telling it what the organization decided before it ever ran. A longer breakdown, including knowledge graphs, is in context engine vs knowledge graph vs RAG tools compared.
Context engineering vs prompt engineering for coding agents: what is the difference?#
Prompt engineering shapes the instruction; the discipline on this page shapes the evidence. The Pragmatic Engineer's 2026 survey of 906 engineers found 55% now use AI agents regularly (The Pragmatic Engineer, 2026). The common setup it describes is a terminal running an agent beside an IDE open for review. That reviewer is doing the context work by hand.
A prompt can tell an agent to follow team conventions. It cannot supply the conventions if they live in a review thread from March. We measured the split directly: the same prompt and the same model, given curated context instead of raw context, used 42% fewer tokens and made 64% fewer tool calls (Unblocked, 2026). Only the evidence changed between runs, and it was one task run once, so read it as a worked example. Prompt work still matters for format, scope, and guardrails, and it hits a ceiling the moment the answer depends on something the model was never shown. The side-by-side with worked examples is in the comparison with prompt engineering.
How do teams do context engineering across hundreds of repos?#
Per-repo instruction files stop working somewhere around the tenth repo. Cloudbeds, an Unblocked customer, runs 987 repos (Cloudbeds, 2026). Advidi runs some 300 legacy repos plus about a hundred newer microservices (Advidi, 2026). The largest organizations on the platform run well over 100,000 with tens of thousands of engineers (Unblocked, 2026). At that scale nobody can keep a CLAUDE.md or AGENTS.md per repo true by hand.
Three things change past a few repos. First, the index has to be built centrally rather than per project, with code history, PR discussion, tickets, and chat linked to the repos they describe. Second, retrieval has to be scoped. A question about the billing service should not return the mobile app's deprecation notes, and a question about a cross-cutting migration should return all of them. Third, permissions have to follow the source, so an engineer who cannot open a private channel does not get its contents through an agent. Stanford's 2026 AI Index found agents still fail roughly one in three attempts on structured benchmarks (Stanford HAI, 2026). Multiply that by hundreds of repos and a wrong starting point stops being noise. The mechanics, and why a pile of connectors does not add up to them, are in a context layer is not a context engine.
Context engineering for agents that run unattended in the cloud: what changes?#
Cloud agents remove the human who used to catch mistakes mid-task. A Claude Code cloud session keeps running after you close your laptop, and you can start several in parallel (Claude Code docs). GitHub's Copilot cloud agent researches a repository, plans changes, and implements them in the background, with a 59-minute ceiling per session (GitHub Docs). Nobody is steering.
Two consequences follow. The first is satisfaction of search, a term borrowed from radiology (Unblocked, 2026). An agent handed a pile of connectors tends to accept the first plausible result it finds and act on it. At a terminal you would say no, you missed the constraint in the other channel. Unattended, that correction never happens. So the context the agent starts from, and can return to mid-task, sets the ceiling on what comes back. The second is scope. By default, Copilot's cloud agent only has access to context in the repository where it is working, which is exactly the blind spot the Friday-afternoon migration fell into. Temporal found 41.1% of engineers hit agent issues daily or more (Temporal, 2026). Unattended, each one becomes a pull request someone has to reject on Monday.
Is a context engine just RAG over Slack and GitHub?#
No. Retrieval is one of five jobs. Anthropic's guidance treats just-in-time retrieval as one way to assemble context and curation as the work that recurs at every step (Anthropic Engineering). The Model Context Protocol's 2026 roadmap lists audit trails, SSO-integrated auth, and gateway behavior as the open enterprise problems (MCP, 2026). Those are the other four jobs, surfacing as infrastructure.
A RAG pipeline over Slack and GitHub returns chunks that resemble the question. It has no opinion on whether the Slack message is newer than the README, whether the person asking may read that channel, or whether two retrieved chunks contradict each other. Curation, conflict resolution, permissions, and freshness are what a team builds next, and the building is the expensive part. Expo's VP of Engineering, Brent Vatne, weighed building that index for the team's code review agent. He concluded it made more sense to use Unblocked than to hit the GitHub API and sort through everything themselves (Expo, 2026). A context engine is that index, built once and kept current. Unblocked's version adds an expert graph that weighs sources by who wrote them and when, and enforces source permissions at retrieval (Unblocked, 2026). The longer answer is in context engine vs RAG and what is a context engine.
Where context engineering starts on your team#
Start with an inventory. Stanford's 2026 AI Index puts AI adoption by organizations at 88% (Stanford HAI, 2026), so the difference is whether anyone can say what the agents were allowed to read.
List every place a coding agent currently pulls from, mark which ones are canonical, and write a name next to each. Then pick one measurable target, such as the share of agent answers that cite a source updated in the last 90 days, and track it for a quarter. If the inventory shows that decisions live in Jira, Confluence, and Slack rather than in the repository, you need a system that reads those sources with permissions intact. That is what Andrei found at Waste Logics. That gap is why MCP servers alone are not enough. The guide for engineering leaders has the rollout plan.
Frequently asked questions#
Is this the same as fine-tuning?#
No. Fine-tuning changes model weights to bake in behavior. Context curation changes what the model sees at inference time, which is where decisions that change weekly belong. Most coding-agent accuracy problems are evidence problems.
Do we still need a CLAUDE.md or AGENTS.md file?#
Yes, for conventions, scope, and guardrails. What those files cannot hold is the decision history: why a client was deprecated, which service owns a table, what the incident last month changed. Keep the file short and point its first instruction at a system that retrieves the rest.
What breaks first when the discipline is weak?#
Conflict resolution and freshness. Old docs outrank new PRs, the agent quotes a deprecated pattern with confidence, and nobody owns the fix because both jobs sit between teams. Assign them before adding another connector.
Can we start with one MCP server per tool?#
You can, and most teams do. Connectors give an agent access without telling it which result to trust or whether it may read the source. Satisfaction of search means the agent will act on the first plausible hit unless something ranks the rest.
How does this reduce token spend?#
By sending the model the reconciled slice instead of everything. In Unblocked's controlled test, curated context cut tokens by 42% and tool calls by 64% against the same prompt and model (Unblocked, 2026).
What is decision-grade context?#
Decision-grade context is context that is synthesized, conflict-resolved, and permission-enforced, so an agent acts on the current decision rather than the stale document. It is what a context engine retrieves for, drawn from code, PRs, tickets, and the threads where the decision was made.
