{"slug": "if-claude-codex-can-connect-via-what-do-we-need-a-context-layer-for", "title": "If Claude/Codex can connect via, what do we need a context layer for?", "summary": "Unblocked, a context engine provider, argues that connecting AI agents to sources via MCP connectors gives access but not understanding, costing up to 83% slower task completion and 60% more tokens. In benchmarks, agents using Unblocked's context engine finished 83% faster with 48% fewer tokens on a Kotlin SDK task and scored 9.5/10 on conventions versus 2/10 without it, while a Claude Code session without Unblocked spent 81 turns and cost 10x more yet returned the wrong answer.", "body_md": "# A Pile of MCP Connectors Is Not a Context Engine\n\nConnecting an agent to your sources gives it access, not understanding. Why cross-source assembly, contradiction resolution, and unwritten conventions need a context engine.\n\n**TL;DR:** Wiring an agent into Slack, Jira, and GitHub via MCP gives it access to your sources but it doesn't give it understanding. Each connector returns documents from one silo, so every cross-source question leaves your agent doing the assembly itself: guessing at names it has never seen, reconciling contradictions, and burning tokens at inference time.\n\nA context engine does that work server-side, knowledge is synthesized, cited, and permission-enforced before anything reaches your context window.\n\nThat difference is worth up to 83% faster task completion at roughly 40% of the tokens.. and actually getting the right answer.\n\nToday, wiring an agent into your tools takes about ten minutes. Claude ships a connector catalog, there are MCP servers for GitHub, Slack, Jira, Notion, Google Drive and whatever else your team is paying for.\n\nWe frequently get the question: if Claude can already reach every source directly, what is Unblocked for?\n\nThe premise sounds right, but the conclusion is wrong. Connecting an agent to your sources gives it **access**. It does not give it **understanding**. The distance between those two is where most of the value lives, and where most of the cost hides.\n\n## What a connector actually gives you[#](#what-a-connector-actually-gives-you)\n\nGive an agent a Slack MCP, a Jira MCP, and a GitHub MCP, and each one behaves the way its authors built it, often mapped 1:1 to the underlying API: you send a query, you get back a list of matching documents from that one system. Search Slack, get Slack messages. Search Jira, get Jira tickets.\n\nThat's genuinely useful for known-item lookups. \"Fetch PR #4821.\" \"Create a ticket in PROJ.\" If that's the whole job, connectors do it fine.\n\nBut the questions that actually slow engineers down don't sit inside one system. Take something like \"why does the payment service retry like this?\" The answer is spread across a PR review thread from last year, a Slack argument that never made it into any doc, a Jira ticket that got closed as won't-fix, and the code itself. No single connector holds more than a fragment of it. Which means someone (or something) has to assemble it.\n\nWith raw connectors, that somebody is your agent. At inference time, on your token bill.\n\n## Your agent becomes the integration layer[#](#your-agent-becomes-the-integration-layer)\n\nHere's what cross-source research looks like when the agent does the stitching itself: query Slack with three or four keyword guesses derived from the quality of your prompt, query Jira, query GitHub, read a dozen results per source, notice a link, fetch it, guess again, repeat. Every intermediate result lands in the context window, relevant or not. Every hop is another turn. Every turn is another pile of tokens wasted.\n\nNone of that is hard, exactly. It's just slow, expensive and easy to get wrong, which is the same thing we said about humans doing it manually back when humans were the ones doing it.\n\nWe benchmark this constantly. We run the same task, same model, same codebase with a blind (LLM) judge:\n\n- On a Kotlin SDK task, the agent with Unblocked context finished 83% faster, used 48% fewer tokens and cost 60% less. It scored 9.5/10 on following the team's conventions, where the agent without context scored 2/10.\n- On a frontend feature-toggle task, 26.6% faster with 41.6% fewer tokens. The agent without context ran out of turns and never produced working code at all.\n\nWe also ran the same question through Claude Code internally, once with Unblocked and once without. The session without it spent 81 turns of subagent exploration crawling the codebase, roughly 84% of a session that cost about 10x more, and still came back with the wrong answer.\n\nThe session with Unblocked answered correctly in 40 seconds.\n\nYou shouldn't take our word for any of that, which is why we open sourced [ context-engine-simulator](https://github.com/unblocked/context-engine-simulator). Point it at your own repo, use your own tooling and your own model key, and see what the delta looks like on your codebase instead of ours.\n\nThe point isn't that agents are bad at searching. It's that \"search each silo and reconcile the results\" is a hard, expensive job and per-source connectors assign that job to the most expensive worker in the building: your frontier-model inference loop. Frontier labs have [even written explicitly](https://claude.com/blog/the-advisor-strategy) about separating the thinking model from the working model.\n\n## The agent doesn't know what it doesn't know[#](#the-agent-doesnt-know-what-it-doesnt-know)\n\nThere's an assumption buried in that retrieval loop: that the agent knows what to search for in the first place. Mostly it doesn't. It doesn't know your team calls the checkout rewrite \"phoenix\" in Slack and \"checkout-v2\" in Jira. It doesn't know the retry behavior was settled in a PR comment rather than a doc. It doesn't know the argument that settled it ever happened. You can't write a query for a conversation you don't know exists, in vocabulary you've never seen, against a system you didn't think to check.\n\nAnthropic's Thariq Shihipar has [good framing of this](https://x.com/trq212/article/2073100352921215386): the map is not the territory. The map is the prompts, skills, and context you hand the model. The territory is where the work actually happens. The gap between them is your *unknowns*, the points where the agent hits something it wasn't told and has to guess at what you wanted. With frontier models, his argument goes, the quality of the work is no longer limited by the model. It's \"bottlenecked by my ability to clarify its unknowns.\"\n\nHis prescriptions are [worth reading in full](https://thariqs.github.io/html-effectiveness/unknowns/): blind spot passes, brainstorms, structured interviews, reference walkthroughs, implementation logs. They work. But look at what they cost. Each one is a human-in-the-loop ritual, re-run for every task, spending your time and your tokens rediscovering context that already exists somewhere in your org. And each one is bounded on both ends: an interview only surfaces what you already know how to answer, and a blind spot pass only scans what the agent can reach. The convention buried in three years of PR history survives both.\n\nThat's the case for attacking unknowns from the other end. Unblocked shrinks them before the session starts, at ingestion time instead of inference time. The engine has already mapped which system holds what, already learned that phoenix and checkout-v2 are the same project, already linked that PR to the Slack thread that reversed it. The agent doesn't have to know where to look, because the engine already knows what exists.\n\n## Sources disagree. Connectors don't care.[#](#sources-disagree-connectors-dont-care)\n\nSay the agent clears that hurdle and finds the information. A second problem is waiting: knowing which version of it is still true.\n\nAlmost every engineering org I've worked in looks like this: a Confluence page says one thing, a Slack thread three weeks later reversed it and nobody went back to update the page. The README documents the old auth flow, and the reasoning behind the new one lives in a review comment on the PR that replaced it.\n\nAn agent querying sources one at a time has no way to know which answer wins. It stops at the first plausible result, and \"plausible\" is exactly how you end up shipping code against a decision your team reversed months ago.\n\nUnblocked's context engine does this reconciliation server-side, before anything reaches the agent: recency and authority signals resolve contradictions, and every answer carries citations so you can see the provenance. That's a different contract than search. Search tells you where information lives. A context engine tells you what's actually true.\n\n## Some knowledge doesn't live in *any* source[#](#some-knowledge-doesnt-live-in-any-source)\n\nHere's the deepest gap, and the one no amount of connector-chaining can close: some organizational knowledge cannot be constructed from queries to individual systems, no matter how many you run because it only exists in the patterns *across* systems, observed over time.\n\n**Unwritten conventions.** No document says \"PRs touching the auth module always get a security review\" or \"changes near the order flow always run the payment integration tests first.\" Those rules exist only as patterns in years of PR history. You can't query for them; you have to have watched.**Expertise topology.** Who actually knows the payment service, not who the org chart says owns it? The answer is derived from[who reviews those PRs on GitHub](https://github.com/unblocked/engineering-social-graph), who answers those questions in Slack, and who closes those bugs in Jira, weighted by recency. No single system holds it. It emerges only when you observe all of them, longitudinally.\n\nUnblocked builds this continuously as part of ingestion: an institutional map of people, projects, conventions, and workflows that gets applied to every query. An agent with ten MCP connectors and an empty context window reconstructs none of it and it starts from zero on every session. That's a high price to pay in search tokens and wasted time.\n\n## Ten connectors is ten security surfaces[#](#ten-connectors-is-ten-security-surfaces)\n\nThere's an operational cost to the connector-mesh approach that security teams have started noticing. Every direct source connector you hand an agent is a separate credential, a separate permission model, and a separate slice of the \"lethal trifecta\" — an agent with access to sensitive data, exposure to untrusted content, and the ability to act. We hear this from platform and security teams weekly: they don't want an agent holding raw keys to Google Drive and Slack and Jira, each governed differently, each auditable separately.\n\nUnblocked collapses that to one connection with server-side enforcement: permissions from every underlying source are propagated at ingestion and enforced before results leave the server, so an agent can only ever surface what the requesting user is authorized to see. One integration to govern, one surface to audit, and no source credentials living in an agent's configuration.\n\n## When a connector is the right call[#](#when-a-connector-is-the-right-call)\n\nAll that said, if the job is transactional, use a connector. Create the ticket, post the message, fetch the one file you already know you need. Unblocked is not trying to replace any of that, and plenty of our customers run both, with connectors handling the writes and Unblocked as the research layer their agents call when the question starts with why, who, or what did we already decide.\n\n| Per-source MCP connectors | Unblocked | |\n|---|---|---|\n| Returns | Documents from one system | A synthesized, cited answer across all systems |\n| Cross-source assembly | Your agent, at inference time | Server-side, before the agent sees anything |\n| Unknowns | The agent guesses at names, systems, and whether a discussion exists | Aliases and cross-system links resolved at ingestion |\n| Contradictions | First plausible result wins | Reconciled by recency and authority, with provenance |\n| Unwritten conventions and expertise | Invisible | Mined continuously from cross-source history |\n| Permissions | Per-connector, agent-held credentials | One connection, enforced server-side |\n| Token cost | You pay for every init and dead-end search | Ranked and resolved before it hits your context window |\n\n## Access is table stakes. Understanding is the product.[#](#access-is-table-stakes-understanding-is-the-product)\n\nMCP made it easy to give agents access, and that's genuinely good. It's the reason Unblocked can deliver its context through a single MCP server into Claude Code, Cursor, Windsurf, Copilot, or anything else that speaks the protocol. But access was never the hard part. The hard part is turning ten systems' worth of partial, contradictory, decade-deep history into one decision-grade answer an agent can act on quickly enough to matter and cheap enough to run on every task.\n\nThat's not a feature a connector catalog grows into. It's a key building block of the future of agentic applications.\n\nRun [ context-engine-simulator](https://github.com/unblocked/context-engine-simulator) against your own repo. If the numbers come out differently than ours did, I'd like to hear about it.", "url": "https://wpnews.pro/news/if-claude-codex-can-connect-via-what-do-we-need-a-context-layer-for", "canonical_source": "https://getunblocked.com/blog/mcp-connectors-are-not-a-context-engine/", "published_at": "2026-07-30 00:11:34+00:00", "updated_at": "2026-07-30 00:22:07.304907+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-infrastructure", "developer-tools"], "entities": ["Unblocked", "Claude", "Codex", "MCP", "Slack", "Jira", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/if-claude-codex-can-connect-via-what-do-we-need-a-context-layer-for", "markdown": "https://wpnews.pro/news/if-claude-codex-can-connect-via-what-do-we-need-a-context-layer-for.md", "text": "https://wpnews.pro/news/if-claude-codex-can-connect-via-what-do-we-need-a-context-layer-for.txt", "jsonld": "https://wpnews.pro/news/if-claude-codex-can-connect-via-what-do-we-need-a-context-layer-for.jsonld"}}