What is a Zendesk AI agent?

The term covers two things. Zendesk's native product is an autonomous resolver that reads a ticket and replies to the customer on its own. The other kind is an agent you build on the Zendesk API that reads the ticket, drafts a reply from your knowledge base, and hands it to a human to approve before it sends. Major is built for the second kind, where the logic lives in an app you own and govern.

How much do Zendesk AI agents cost?

Zendesk prices its native AI agents on outcomes, charging for resolutions delivered, so the bill grows with ticket volume. A custom agent on the Zendesk API has no per-resolution meter. You pay for API usage and the build. On Major the reasoning happens up front, then classification, knowledge-base lookup, and note posting run as code, so cost stays flat as the queue grows.

Can a Zendesk AI agent resolve tickets without a human?

Yes, the native autonomous kind can. A custom triage-and-draft agent works the other way by design: it drafts a reply and routes the ticket while a person approves every customer-facing message. On Major, RBAC decides who can approve a public reply and the approval is logged against the ticket.

How do you build a custom AI agent on Zendesk?

Use the Zendesk API. A webhook fires on a new ticket, then the agent classifies intent and priority, searches your knowledge base, and adds a draft as an internal note by setting a comment's public flag to false. A human approves in Slack, and the agent posts the public reply. On Major, the webhook lands on an app route and the Zendesk token stays behind the credential proxy.

How does a Zendesk agent avoid re-drafting the same ticket every run?

Keep a record of what it already handled outside the model. Zendesk webhooks can fire more than once on a ticket, and a model's context does not carry between runs, so a stateless agent can post a second draft on a ticket a human already answered. Store processed ticket IDs and prior drafts, and check them before writing. A Major app has a managed database for exactly that.

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

Zendesk sells autonomous AI agents priced per resolution. Here is the other option: build a triage-and-draft agent on the Zendesk API that reads a ticket, checks your knowledge base, and drafts a reply for human approval.

Jose GironJuly 20, 2026Updated October 21, 2026

Major x Zendesk lockup for a Zendesk AI triage-and-draft agent

A Zendesk AI agent is software that reads support tickets and acts on them. The fastest way to get one you control is a triage-and-draft agent built on the Zendesk API: it classifies each ticket, finds the answer in your knowledge base, drafts a reply as an internal note, and waits for a human to approve it. On Major, that agent builds the triage logic once as a governed app, so the repeatable work runs as code and the model only reads each new ticket.

This guide is for support and operations leads who want AI on their Zendesk queue without handing the send button to a vendor.

What does "Zendesk AI agent" mean?

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

Zendesk's own AI agents are autonomous resolvers. They read an incoming ticket, match it against your help center, and reply to the customer unsupervised. Zendesk bills them on outcomes, per resolution, so the cost line moves with ticket volume and the decision logic stays inside the vendor.

The other kind is an agent you build on the Zendesk API. It can draft instead of send. A person reads the draft, edits a sentence, and clicks approve. Every classification and draft is logged where you can read it. Per-resolution billing never applies, because you are not buying resolutions.

If you want the conceptual background first, read what an AI agent is.

Three jobs a controlled agent does well

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

Triage and routing. The agent reads a new ticket, classifies intent and priority, applies tags, and assigns the right group. No customer-facing text is involved, so the risk is low. Start here.

Draft-reply-for-approval. 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. The person keeps the send button. Most of the speed gain in support lives here.

Risk escalation. When a ticket mentions a refund, a legal issue, or a cancellation threat, the agent drafts nothing. It flags the ticket, routes it to a named queue, and lets a person own the response.

The Zendesk API in 200 words

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

For triggering, Zendesk fires webhooks and triggers on ticket events, so your agent runs on an event instead of a poll. Ticket creation also 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.

The draft call is one request: PUT /api/v2/tickets/{ticket_id}.json with a comment of {"body": "Draft reply for review: ...", "public": false} and tags ai_triaged and awaiting_agent_review.

Where the Zendesk API will bite you

The object model is clean and the public flag gives you draft-versus-send control for free. The gotchas are specific.

Search freshness lags. Zendesk states it can take up to a few minutes for new tickets and other resources to be indexed for search. Never create a ticket and immediately look it up with Search. Read the webhook payload directly.
Search results are capped. The API returns up to 1,000 results per query at 100 per page, so knowledge-base lookups need specific queries, not broad scans.
Rate limits are per-minute and endpoint-specific. Search has its own limit separate from the account-wide one. Batch and back off.
Webhooks can fire more than once. An agent with no memory can post a second draft on a ticket a human already answered.
Test in a sandbox first. An agent that writes comments and changes tags should not learn on your live queue.

Build the Zendesk triage-and-draft agent on Major

A customer writes: "The export button on the reporting page does nothing when I click it." Here is how the agent handles it on Major, with three connectors: Zendesk for the ticket, Notion as the knowledge base, and Slack for approval. Support content already lives in Notion for many teams, which is why Notion works as the knowledge layer.

The app holds state. A deployed Major app owns a managed database with tables for processed ticket IDs, classifications, drafts, and approval decisions. Duplicate webhook deliveries become a lookup, not a prompt the model has to remember.
Trigger. A Zendesk webhook posts the ticket payload to a route on the app. The agent never waits on search indexing for a ticket it was just handed.
Classify. This is the one step that needs judgment. The agent reads the subject and body and assigns an intent (how-to, bug, billing, cancellation) and a priority. Once it has worked out the rules, they are written into the app as deterministic code, so the same ticket pattern routes the same way every time.
Look up the answer. The Notion connector queries the knowledge base for the matching article.
Draft. The agent writes a reply grounded in that article and adds it to the ticket as a public: false note tagged awaiting_agent_review.
Approve. The Slack connector posts the draft to the assigned agent with approve and edit buttons. Only on approve does the app post the public comment.
Escalate. If classification tagged the ticket billing, legal, or cancellation, the app skips drafting, routes to a named human queue, and posts a heads-up in Slack.

Governance is part of the build, not an afterthought. The Zendesk token sits behind Major's credential proxy, scoped to the tickets and fields the app touches, so the agent calls it but never holds it. RBAC decides who can approve a public reply. Every classification, draft, and human decision is written to the app's audit log. The agent cannot issue refunds, close legal tickets, or change a plan, because the app was never granted those scopes.

The cost shape follows from the design. Reasoning is front-loaded into the build, then the repeatable steps run as code, so a busier queue does not mean a proportionally bigger model bill. Accuracy still tracks knowledge-base quality. A stale KB produces confident, wrong drafts, so treat the KB as part of the system.

Start on Major and build your Zendesk triage-and-draft agent.

What this guide does not cover

It does not cover multi-language reply generation, voice channels, or fine-tuning on your ticket history. It also skips Zendesk's native agent setup screen, since the point here is the API path you own. For the controls any support automation should meet before touching a live queue, see enterprise AI agents, and for the pattern in general, agentic workflows.

Start building on Major

Build the triage-and-draft agent on your own Zendesk queue: Zendesk, Notion, and Slack connected, a managed database for ticket state, and a human approving every customer-facing reply. Reason once, run forever.

Frequently asked questions

What is a Zendesk AI agent?: The term covers two things. Zendesk's native product is an autonomous resolver that reads a ticket and replies to the customer on its own. The other kind is an agent you build on the Zendesk API that reads the ticket, drafts a reply from your knowledge base, and hands it to a human to approve before it sends. Major is built for the second kind, where the logic lives in an app you own and govern.
How much do Zendesk AI agents cost?: Zendesk prices its native AI agents on outcomes, charging for resolutions delivered, so the bill grows with ticket volume. A custom agent on the Zendesk API has no per-resolution meter. You pay for API usage and the build. On Major the reasoning happens up front, then classification, knowledge-base lookup, and note posting run as code, so cost stays flat as the queue grows.
Can a Zendesk AI agent resolve tickets without a human?: Yes, the native autonomous kind can. A custom triage-and-draft agent works the other way by design: it drafts a reply and routes the ticket while a person approves every customer-facing message. On Major, RBAC decides who can approve a public reply and the approval is logged against the ticket.
How do you build a custom AI agent on Zendesk?: Use the Zendesk API. A webhook fires on a new ticket, then the agent classifies intent and priority, searches your knowledge base, and adds a draft as an internal note by setting a comment's public flag to false. A human approves in Slack, and the agent posts the public reply. On Major, the webhook lands on an app route and the Zendesk token stays behind the credential proxy.
How does a Zendesk agent avoid re-drafting the same ticket every run?: Keep a record of what it already handled outside the model. Zendesk webhooks can fire more than once on a ticket, and a model's context does not carry between runs, so a stateless agent can post a second draft on a ticket a human already answered. Store processed ticket IDs and prior drafts, and check them before writing. A Major app has a managed database for exactly that.