Note: Zendesk's AI MCP Client is currently in Early Access. Setup details and field names in the configuration sections below are subject to change as the feature moves toward GA. Check Zendesk's announcement for current availability.
A customer submits a ticket asking whether their data is stored in the EU region. A Zendesk AI Agent, drawing on the knowledge base, answers: "Yes, all customer data for our European plans is stored in EU-West." The customer is satisfied. Six months ago, the company migrated EU-West data to EU-Central for a latency optimization; the knowledge base article was not updated. The declared compliance artifact in the engineering team's source-of-truth was updated that same week. The AI Agent read the wrong source. The customer received a factually incorrect answer about where their data lives, which is the kind of support interaction a compliance auditor will find and escalate.
Zendesk's AI Agent is only as current as the knowledge base it reads. Knowledge bases drift. Declared system behavior, if you have the infrastructure to declare it, does not. The shape of the fix is the same as for every other AI support surface: connect the agent to a source of truth that updates when the system changes. Zendesk's AI MCP Client is the mechanism. It is still in Early Access. When it lands generally, Ribo is the connector that makes this pattern durable.
The drift problem at Zendesk scale
Large support organizations run on knowledge base articles. Tens of thousands of them, authored by support engineers and product managers across years, each attached to workflows and automations. The articles rarely get retired; they get added to. When system behavior changes, the burden of updating every relevant article falls on whoever notices. Most of the time, nobody notices until a customer cites the article back to a human agent and the agent has to apologize.
AI Agents amplify this. They are fluent, confident, and fast. They also cannot tell which article is current and which is two years out of date. The scale of automated responses turns a slow trickle of drift into a steady stream of incorrect answers, delivered with the same tone as the correct ones. The support function ends up paying for this in escalations, compliance incidents, and the time humans spend walking back automated replies.
The architectural fix is not "write fewer knowledge base articles" or "retire old ones more aggressively." It is "connect the AI surface to something that maintains current behavior as a first-class artifact." Zendesk announced the AI MCP Client as the mechanism for exactly that shape of connection. When it moves from EAP to GA, external MCP servers become a supported source that Zendesk AI Agents can draw on during ticket resolution.
What changes when Zendesk reads declared intent
Ribo exposes four read tools over MCP: search declared artifacts, retrieve a specific artifact, list artifacts in a project, walk relationships. When a Zendesk AI Agent has Ribo among its MCP sources, its retrieval gains a surface that is structurally current by design. Intent artifacts declare what the product is supposed to do. Glossary artifacts define what terms mean. Integration artifacts name the external systems the product is declared to talk to.
Take the data-residency scenario. With Ribo connected, the AI Agent searches declared artifacts for "data residency" and "EU storage." It finds the compliance artifact declaring current regional storage arrangements. It finds the integration artifact naming the cloud provider and region. The reply cites the current arrangement. The knowledge base article that was wrong six months ago is no longer the agent's primary source; the declared artifact is. When the team changed regions, they updated the artifact as part of the same proposal that deployed the change. The support answer now tracks the system.
The knowledge base does not disappear. It becomes a human-readable layer on top of declared artifacts, kept loosely consistent. Automated answers bypass it for questions about current behavior and go directly to the declarations.
Role-appropriate projection for Zendesk
Zendesk AI Agents are customer-facing. The projection must be narrow; the blast radius of a compromised or misconfigured support bot is the widest of any MCP consumer a team wires up. Ribo's DNA splits into thirteen layers. For Zendesk, expose three: intent, glossary, integration.
Intent tells the AI Agent what the product is supposed to do at the level a customer experiences it. Glossary defines your product's vocabulary so the bot speaks the same language as your product team. Integration names the external systems your product is declared to talk to, which is exactly the dimension residency and data-handling questions turn on.
Withhold ten layers. Compliance, constraint, algorithm, evaluation, monitor, reporting, pace, escalation, contract, tradeoff: none of these should be queryable by a customer-facing agent. A compliance artifact may describe gaps in your security posture or regulatory exposures that a customer does not need to read about. A constraint artifact names what the product must not do, which is valuable to engineers and toxic to customers. Algorithm, contract, evaluation, and tradeoff are implementation details. Monitor, reporting, pace, and escalation are operational. The three-layer projection is the minimum sufficient surface for a support bot and it is also the maximum safe surface.
How to wire it up (pending GA)
The exact fields below reflect the current EAP configuration shape and are expected to stabilize at GA. When Zendesk's AI MCP Client becomes generally available, the steps will be:
First, mint the support token in the Ribo console. Go to Agents, create an agent named zendesk-<subdomain>. Set scopes to artifact:read. Set projectIds to the Ribo projects whose customer-facing behavior the AI Agent should be able to answer about. Set allowed_kinds to the three-layer support projection: intent, glossary, integration. Capture the bearer token. Treat this token as the most sensitive integration token in your Ribo workspace.
Second, add Ribo as an MCP source in Zendesk. Based on Zendesk's announcement, the configuration surface will sit in Zendesk's Action Builder, used by Copilot, AI Agents, and workflows. The expected fields:
| Field | Value |
|---|---|
| MCP source name | Ribo |
| Endpoint URL | https://mcp.ribo.dev/context/mcp |
| Authentication | Bearer token from the Ribo console |
Save the source and enable it for the AI Agents or workflows that should consult it. Validate with a residency-style test question before widening to production traffic.
What we recommend while EAP is still the state
Two pieces of preparation are worth doing now, before the MCP Client reaches GA, because the work compounds.
First, take an inventory of the knowledge base articles that carry compliance or residency risk. These are the articles whose inaccuracies will cause the most damage if they drift. For each, identify whether the underlying behavior is already declared in Ribo (or could be). If not, authoring those declarations is the engineering work that makes the downstream support surface trustworthy when it connects.
Second, design the three-layer support projection for your specific product. The generic intent-glossary-integration cut works for most teams. Some products have domain-specific reasons to add or remove layers; a healthcare product, for example, may want an additional layer constrained to customer-safe compliance statements. Ribo's role-appropriate projection model supports custom layer selection; the work is in deciding what belongs and what does not before the integration goes live.
What this becomes at GA
Once the Zendesk AI MCP Client ships generally and Ribo is wired in, the shape of automated support changes from "confident answers from possibly stale sources" to "current answers grounded in declared product behavior." The knowledge base continues to exist; it becomes a human-readable layer rather than the primary source of truth for automation. Support teams stop playing knowledge-base-maintenance whack-a-mole, because the declarations are maintained by the engineering teams that own the behavior. The support surface tracks the system because it reads the system's declaration, not a description of the system from eighteen months ago.
Zendesk is preparing the connector. Ribo is the source of truth that will make the connector worth using. When the two meet, the cost of being wrong about your own product in your own support channel goes to zero.