Does one context source serving coding agents, support bots and internal Q&A exist?
Yes. A context engine indexes code, pull requests, tickets, docs and Slack once, then serves the same reconciled answer three ways: over MCP to coding agents, through an API to support bots, and in Slack or a web app for internal Q&A. The part to check is permissions: each consumer needs its own scope, not one shared login.
Yes, it exists, and it is called a context engine. One context source can serve a coding agent in Cursor, a support bot that drafts replies, and an engineer asking a question in Slack, as long as it does three jobs. It has to read the systems where answers actually live (code, pull requests, tickets, docs, chat), reconcile them into one answer, and hand that answer out under a different scope for each consumer. A shared context source is one index and one reasoning layer over those systems that every AI tool in the company queries, instead of each tool keeping its own copy of the knowledge. Support platforms and coding-context tools each serve one of the three, and enterprise search reaches further.
What each of the three consumers needs#
The three consumers ask about the same systems but want different things back.
| Coding agent | Support bot | Internal Q&A | |
|---|---|---|---|
| Who asks | Claude Code, Cursor, Copilot, a background agent | A bot in a help desk or support channel | An engineer, PM or support lead |
| How it connects | MCP tools inside the agent session | An API call from a backend service | Slack, Teams or a web app |
| What it needs back | A short answer with links it can follow | A plain answer it can cite or hand to a person | A cited answer a human can check |
| Whose access | The developer who runs it | A service identity with a narrow scope | The person asking |
The sources overlap almost completely. "Why does this customer's export fail?" from support, "why does the export job retry five times?" from an agent, and "who owns exports now?" in Slack all resolve to the same pull request, ticket and thread. If each tool keeps its own index, you get three answers to one question, and they drift apart the first time the code changes.
Which tools serve coding agents, support bots and internal Q&A#
Support platforms are built for the support bot and stop there. Intercom's Fin answers from help center articles, snippets, PDFs, websites and synced sources such as Confluence, Guru and Notion, and "External content (via public URLs) is only updated weekly" (Intercom). Zendesk's AI agents search external sources "as of the last sync, which usually happens every 24 hours" (Zendesk). Neither lists code or pull requests as a knowledge source, and neither is meant to feed a coding agent. The support-side comparison is in context for support and ops agents.
Enterprise search now reaches agents as well as people. Glean's MCP server offers search, chat, document reading, code search and people tools, with 22 tested hosts including Claude Code, Cursor and VS Code (Glean docs). Its Client API adds a chat endpoint for applications (Glean developer docs), so one Glean index can reach all three consumers. Its search tool returns "permission-aware results" for the agent to read, and its chat tool hands back an answer from Glean's assistant (Glean docs). How it handles a design doc that disagrees with merged code is covered in Glean vs Unblocked for engineering teams.
Coding-context tools such as rules files and per-agent MCP servers serve the coding agent only. They do nothing for the support lead in Slack, who still has to ask an engineer. That handoff is covered in codebase answers for product and support.
The deciding question: whose permissions each consumer uses#
Sharing one source is only safe if each consumer sees a different slice of it. A developer's agent should see what that developer can see. An engineer asking in Slack should get an answer built from what they can open. A support bot should see a narrow, chosen set of sources, and a bot that answers customers should never read private engineering channels at all.
The protocol allows this. The MCP specification says the set of tools a server returns "MAY vary by the authorization presented on the request," since "credentials are per-request input, not connection state" (MCP specification). In practice that means three kinds of identity on one source:
- Agents and Q&A run as the person, through OAuth sign-in, so answers follow that person's access in each source system.
- Bots run on a team token. A team token is a service credential limited to the sources you pick when you create it.
- Customer-facing bots get the narrowest token, and a human reviews anything drawn from internal sources before it goes out.
If a vendor can only offer one shared admin login across all three, you have one source with one level of access, which is the setup that leaks. A May 2026 paper on multi-agent authorization makes the same point: identity checks have to be "enforced at every interaction boundary" (arXiv 2605.05440). The paper also names "aggregation inference" as a separate risk. Aggregation inference is when an answer combines sources in a way that reveals something no single source would. For example, a bot allowed to read both the incident channel and the customer list could tie an outage to a named account even though neither source says so on its own.
How Unblocked serves all three#
Unblocked is a context engine that reads code, pull requests, issues, docs, Slack or Teams, and incidents, reconciles them, and returns one cited answer with permissions mirrored from each source. The same engine answers in Claude Code, Cursor, VS Code and other tools over MCP, in Slack, Teams and the web for people, and through a REST API for backend services. Its docs describe the Answers API as one where "clients submit a question and poll for its result." Personal and team tokens "have different access scopes," and a team token can be limited to selected data sources (Unblocked docs). How the engine weighs code against an old wiki page is in inside the Unblocked context engine.
Brent Vatne, VP of Engineering at Expo, describes it this way in Expo's customer story: "I see Unblocked as the API for our organization's context. We happen to use it through an MCP, a CLI, and a Slack bot, but there are so many other ways to plug it into different workflows."
When separate tools are still the right call#
Say your support bot answers "how do I reset my password" questions and every answer is already in the help center. A support platform like Fin or Zendesk is the simpler choice there, and it does not need your code. If your engineers only want enterprise search across SaaS apps and nobody runs coding agents yet, a search tool covers that.
The case for one source starts when the questions cross over: support asks why something broke, agents need the reason behind a change, and engineers are the ones answering both by hand. At that point, three tools mean three answers, and engineers end up settling which one is right. One source with three scopes removes that work.
