Zendesk AI Agents: How to Build a Triage-and-Draft Agent You Control

Key takeaways

• Zendesk's native AI agents resolve tickets on their own and bill per resolution. A custom agent on the API bills for API usage and build time, with no per-resolution meter.
• A triage-and-draft agent reads a ticket, finds the answer in your knowledge base, and drafts a reply for a human to approve before it reaches the customer.
• The Zendesk API exposes Tickets, Ticket Comments, and Search. Setting a comment's public flag to false makes it an internal note.
• Route anything touching refunds, legal, or churn to a person instead of drafting it.

What a Zendesk AI agent is (and what Zendesk's own product does)

Two different things share the name, and the difference decides how much control you keep.

Zendesk sells a product called AI agents. It is an autonomous resolver. It reads an incoming ticket, matches it against your help center and past conversations, and replies to the customer on its own. Zendesk says these agents can "resolve up to 80% of customer interactions" (a Zendesk claim, from its AI agents product page), and it prices on outcomes, charging for the resolutions the agent delivers rather than a flat fee.

The other thing is an agent you build on the Zendesk API. It does not have to answer customers unsupervised. The version most support orgs actually want reads the ticket, checks the knowledge base, drafts a reply, and hands that draft to a human to approve or edit before a word reaches the customer. Same phrase, "Zendesk AI agent," a very different control model. This article covers how to build the second one, and it is honest about when the first one is the better call. If you want the conceptual background first, here is what an AI agent is.

When an AI agent over Zendesk actually helps

Not every support workflow needs an autonomous responder. Three jobs are a strong fit for a controlled agent, and they map onto how AI customer service agents tend to earn their keep in practice.

Triage and routing

The agent reads a new ticket, classifies its intent and priority, applies tags, and assigns it to the right group. No customer-facing text is involved, so the risk is low and the time saved on manual sorting is real. This is the safest place to start.

Draft-reply-for-approval from a knowledge base

The agent looks up the answer in your knowledge base, writes a reply in your team's voice, and posts it as an internal note. A human reads it, edits if needed, and sends. The agent does the retrieval and the first draft. The person keeps the send button. Most of the speed gain from AI in support lives here, without the exposure of an unsupervised reply.

Risk escalation

When a ticket mentions a refund, a legal or compliance issue, or a churn signal like a cancellation threat, the agent should not draft anything. It flags the ticket, routes it to a named queue, and lets a person own the response. The judgment stays with the human on exactly the tickets where judgment matters.

Native, third-party, or custom: how they compare

The market gives you three ways to put AI on Zendesk tickets. They differ most on who owns the logic and how you pay.

• Native Zendesk AI agents Who owns the logic: Zendesk (you configure, not build). Pricing model: Outcome-based, per resolution. Human in the loop: Optional, autonomous by design. Transparency: Limited into the decision.
• Third-party resolver (e.g. Intercom Fin) Who owns the logic: The vendor. Pricing model: Outcome-based, per resolution. Human in the loop: Optional, autonomous by design. Transparency: Vendor sits between you and your data.
• Custom triage-and-draft agent on the API Who owns the logic: You. Pricing model: API usage plus build, no per-resolution meter. Human in the loop: Required, drafts, never sends by default. Transparency: Every classification and draft is logged.

Native agents are the right call when you have a high volume of repetitive, low-risk questions (order status, password resets, hours and policies) and a help center good enough to answer them. If deflecting that volume is the whole job, an autonomous resolver earns its keep. The custom route wins when you want to keep the send button, log every decision, and avoid a bill that climbs with each resolution.

What you need to build one

The Zendesk API in about 200 words

You authenticate with an API token or OAuth access token, sent as a bearer credential against your subdomain. Three objects carry the workflow. Tickets lets you list, show, create, and update tickets, including their tags, priority, group, and assignee. Ticket Comments is how replies are added: each comment has a public boolean, which is "true if a public comment; false if an internal note." Set it to false and the agent's draft lands as an internal note the customer never sees. Search lets you find tickets and knowledge-base content by type, tag, date, and property.

For triggering, Zendesk fires webhooks and triggers on ticket events (new ticket, ticket updated), so your agent runs on an event rather than a poll. One detail worth pinning down early: ticket creation supports an Idempotency-Key header, so a retried create returns the cached result instead of a duplicate ticket. Per the Zendesk docs, keys expire after two hours and apply to creation requests.

# Add the agent's draft as an internal note (public:false), not a customer reply
curl -s -X PUT \
https://{subdomain}.zendesk.com/api/v2/tickets/{ticket_id}.json \
-H "Authorization: Bearer {access_token}" \
-H "Content-Type: application/json" \
-d '{
"ticket": {
"comment": {
"body": "Draft reply for review: ...",
"public": false
},
"tags": ["ai_triaged", "awaiting_agent_review"]
}
}'

Pros and cons of the Zendesk API

On the plus side, the object model is clean, the public flag gives you draft-versus-send control for free, and idempotency keys make ticket creation safe to retry. The gotchas are specific and worth planning around.

• Search freshness lags. Zendesk states "it can take up to a few minutes for new tickets, users, and other resources to be indexed for search." Do not build a flow that creates a ticket and immediately expects to find it by Search. Read the webhook payload directly instead.
• Search results are capped. The API returns up to 1,000 results per query at 100 per page, so KB lookups need specific queries, not broad scans.
• Rate limits are per-minute and endpoint-specific. Search carries its own limit separate from the account-wide one. Batch and back off rather than firing per-ticket bursts.
• Test in a Zendesk sandbox first. An agent that writes comments and changes tags should not learn on your live queue.

A worked example: the Triage-and-Draft agent

What it does

A customer opens a ticket: "The export button on the reporting page does nothing when I click it." The agent reads the ticket, decides it is a how-to or bug question rather than a billing or legal one, searches your knowledge base for the export feature, and drafts a reply that points to the right steps and a known workaround. It posts that draft as an internal note and pings the assigned agent in Slack. A person reads the draft, tweaks one sentence, and clicks approve. The public reply goes out. Total human time: under a minute, on a ticket that used to take five.

How the steps wire together

The flow uses three real connectors: Zendesk for the ticket, Notion as the knowledge layer, and Slack for approval. Each numbered step is a discrete action the agent takes.

1. Trigger. A Zendesk webhook fires on a new or updated ticket and hands the agent the ticket payload directly, so it never waits on search indexing to read the ticket it was just given.
2. Classify. The agent reads the subject and body and assigns an intent (how-to, bug, billing, cancellation) and a priority. This is the one step where the model earns its cost: reading unstructured language.
3. Look up the answer. The agent queries a Notion knowledge base for the matching article. Notion is the KB because support content already lives there for many teams, and it maps cleanly onto using Notion as the knowledge layer.
4. Draft. The agent writes a reply grounded in the KB article and adds it to the ticket as an internal note (the public:false comment), tagged awaiting_agent_review.
5. Approve. The agent posts the draft to the assigned agent in Slack with approve and edit buttons. On approve, it adds the reply as a public comment via Ticket Comments. Nothing reaches the customer without that click.
6. Escalate. If the classify step tagged the ticket as billing, legal, or a cancellation, the agent skips drafting entirely, routes the ticket to a named human queue, and posts a heads-up in Slack. No draft, no auto-reply, just a fast handoff.

Human stays in the loop: the agent drafts and routes, but a person approves every customer-facing reply, and risk tickets never get a draft at all.

What governance the agent needs

The agent must not do certain things unattended. It should not send public replies without approval, issue or promise refunds, close or resolve legal and compliance tickets, or change a customer's plan. Those actions belong to a person. Beyond that, the agent needs scoped Zendesk credentials limited to the tickets and fields it touches, and a durable log of every classification, draft, and human decision so a lead can audit why any reply went out. Accuracy tracks knowledge-base quality: a stale KB produces confident, wrong drafts, so the KB is part of the system, not a detail. These are the same enterprise-grade governance points any support automation should meet before it touches a live queue.

What this guide does not cover

This is a build guide for a controlled triage-and-draft agent, not a full support-operations manual. It does not cover multi-language reply generation, voice or phone channels, or fine-tuning a model on your ticket history. It also does not walk through Zendesk's native agent setup screen, since the point here is the API path you own. Pricing figures shift, so confirm current Zendesk rates before you budget.

Build this in Major

This is the kind of workflow Major is built for. Major is the enterprise platform where agents build the software they run on. An agent works out the triage-and-draft logic once (how to classify a ticket, when to escalate, how to ground a draft in the KB) and then builds a governed app that runs it. The app holds the classification rules, the escalation thresholds, and a log of every draft and human decision in its own database. Zendesk credentials are scoped to the tickets it handles, and there are no autonomous public replies by default. The model is reserved for the one step that needs judgment, reading each new ticket, while the rest runs as deterministic code. That is the triage-and-draft pattern as an agentic workflow: reason once, run forever, with no per-resolution meter attached.

If your ticket volume is mostly low-risk FAQ deflection, Zendesk's native agents may be the simpler fit, and that is a fair call. But if you want a human on every customer-facing reply, ownership of the logic, and every decision in a log, build the triage-and-draft agent instead. Start on Major and build your Zendesk triage-and-draft agent.

Related articles

• What an AI Customer Service Agent Actually Does
• AI Agents for Notion: Using Notion as a Knowledge Layer
• Enterprise AI Agents: Governance and Controls