What is the difference between an AI agent and a chatbot?

A chatbot answers predefined questions from a script and cannot see your backend state. An AI customer service agent reads live context and completes multi-step tasks through integrations: it pulls the ticket and customer record, checks policy, then drafts a reply, updates the ticket or proposes a refund. On Major, the repeatable write-back runs as a typed app rather than free-form model output.

What are the best use cases for AI agents in customer support?

Ticket triage and routing, reply drafting grounded in your knowledge base, refunds and plan changes, account verification, SLA escalation sweeps, churn-risk flagging and post-resolution follow-up. Start with one high-volume, low-risk type such as order status or password resets, and keep human approval on refunds and account changes.

How do you build an AI customer service agent?

Wire five pieces: a trigger on new or updated tickets, a reader that gathers the ticket, customer history and matching knowledge-base article, a reasoning step that classifies and drafts a reply, a Slack approval gate, and a typed write-back that posts only after approval. On Major the write-back and state live in an app the agent builds and then runs.

How do you keep an AI support agent from making mistakes?

Keep it read-only on customer data, require human approval on sensitive writes, and let it write only through typed apps with fixed inputs such as ticket id, reply body and status. Log every read and write so each action is attributable. Major provides scoped credentials, RBAC on the app and audit logging at the point the agent acts.

AI Customer Service Agents: Use Cases and How to Build One

What an AI customer service agent does, the seven support workflows teams ship first, and how to build a governed triage and draft agent on Major across Zendesk, Postgres, Notion and Slack.

Jose GironJune 30, 2026Updated October 21, 2026

Major x Zendesk lockup for an AI customer service agent built on Major

An AI customer service agent reads a support ticket, pulls context from your help desk, billing system and knowledge base, then resolves it or drafts a reply for a person to approve. A chatbot answers scripted questions. An agent completes multi-step work such as refunds, plan changes and account checks by calling backend systems.

The hard part in production is not the model. It is making the repeatable parts of support run the same way every time, with state that persists and an audit trail on every write. That is where Major fits. Major is the enterprise platform where agents build the software they run on: the agent works out how to triage and respond to a ticket type once, builds an app for it, and runs that app from then on. This guide is for support and ops leaders who want that on their own stack.

What separates an AI agent from an FAQ chatbot

A chatbot returns a scripted answer from a database. It cannot see the customer's order, subscription or account state, so it stalls or escalates when a question leaves the script.

An agent reads the ticket, fetches the customer record, checks policy, and then acts: it updates the ticket, drafts the reply, or proposes a refund. The short test is that a chatbot talks and an agent does.

Vendors lead with resolution rates. In regulated or high-stakes support, that is the wrong headline. The question to ask is whether every sensitive action is approved where it matters and logged everywhere.

Seven support workflows teams ship first

Each of these maps to named connectors and a metric you already track.

Ticket triage and routing (Zendesk, Salesforce): classify category and urgency, assign the queue. Measure time to first touch and reassignments.
Reply drafting grounded in your KB (Zendesk, Notion): draft from the matching article and macro for human approval. Measure handle time.
Refunds and plan changes (Stripe, Salesforce, Slack): propose within policy, execute only after approval. Measure resolution time on billing tickets.
Account verification (Postgres, Salesforce): confirm identity and account state before any action. Measure wrong-account actions.
SLA and escalation sweeps (Zendesk, Slack): scan open tickets on a schedule and escalate breach risks. Measure SLA breaches.
Churn-risk flagging (Postgres, Salesforce, Intercom): score accounts on ticket sentiment and usage. Measure how early you intervene.
Post-resolution follow-up (Zendesk, Intercom): check in after a close and reopen if the customer is unhappy. Measure CSAT.

Refunds and plan changes carry sensitive writes. Those two need an approval gate from day one.

Where to start

Pick one high-volume, low-risk ticket type. Order status and password resets work because a mistake is cheap and volume is high.

Keep a human approval on every write at first. Ground replies in your own knowledge base so answers follow your policy rather than the model's guess. Measure deflection and CSAT on that single ticket type before widening scope. Add refunds only after the low-risk path is stable and audited.

Why the work should live in an app, not in the model

Most support agents re-reason every ticket from scratch. Cost scales with ticket volume, behavior varies run to run, and the only record of what happened is a transcript.

A predictable agent changes that. Classification rules, routing tables, SLA timers and the Zendesk write-back are repeatable. Major's agent builds them as an app with a managed database, then calls the app instead of reasoning through the step again. The model is left for the tickets that need judgment: an ambiguous complaint, a policy edge case, a tone call on an upset customer.

The practical effects are structural. Triage runs identically on ticket 10 and ticket 10,000. State such as ticket history, approval decisions and routing outcomes sits in the app's database, not in a context window. And cost is front-loaded while the agent figures the workflow out, then flattens as the app takes over. The model still does real work. It just does less of it.

Build the support triage and draft agent on Major

Here is a concrete build across Zendesk, Postgres, Notion and Slack.

Connectors. Attach Zendesk for tickets, Postgres for customer history, Notion for the knowledge base and policy docs, and Slack for approvals. Each connector uses scoped credentials, so the agent only holds the access you grant.
The app that holds state. A "Support Triage" app with a managed database: a tickets table (ticket id, category, urgency, proposed status), an approvals table (approver, decision, timestamp) and a routing-rules table. Support leads manage queues and rules in its UI. The agent executes through the same app.
The agent and its judgment. The agent reads a new ticket, assembles the account context, and decides category, urgency and a draft reply grounded in the matching KB article. Anything that fits an established pattern goes through the app's deterministic rules. The model is spent on tickets that do not.
Trigger. A workflow fires on a Zendesk ticket event. A second scheduled run sweeps open tickets for SLA risk and posts escalations to Slack.
Approval gate. The draft and proposed status post to a Slack channel. A support agent approves, edits or rejects. Refunds and account changes need a second approval before anything is written.
Write-back. A typed "Update Zendesk Ticket" app accepts ticket_id, reply_body and status, and performs the write only after approval. The agent cannot post a malformed payload or touch a field it was never granted.
Governance. The agent runs with the permissions of the support user who owns the queue. RBAC applies on the app, every read and write is logged at the point the agent acts, and the audit trail is exportable to your SIEM.

Once built, that app is reusable. The next team that needs triage over a different queue starts from it instead of from a blank prompt.

Build a support triage agent on Major and have the first ticket type running in one sitting.

Can AI replace customer service reps?

No. An agent deflects routine tickets and assists on the rest. Judgment on emotional, high-stakes or policy-sensitive cases stays with a person. The durable model keeps people on actions that carry risk and lets the agent carry volume, which is leverage for the support team rather than a substitute for it.

What this build does not cover

Major does not ship a consumer chat widget or out-of-the-box deflection dashboards. You bring your own knowledge base and policy docs, and you own keeping them current. What you get in return is a support agent over your own systems with approvals, permissions and an audit log you control.

Start building on Major

Build the support triage and draft agent described above on your own Zendesk, Postgres and Notion data, with Slack approvals and a full audit trail on every write.

Frequently asked questions

What is the difference between an AI agent and a chatbot?: A chatbot answers predefined questions from a script and cannot see your backend state. An AI customer service agent reads live context and completes multi-step tasks through integrations: it pulls the ticket and customer record, checks policy, then drafts a reply, updates the ticket or proposes a refund. On Major, the repeatable write-back runs as a typed app rather than free-form model output.
What are the best use cases for AI agents in customer support?: Ticket triage and routing, reply drafting grounded in your knowledge base, refunds and plan changes, account verification, SLA escalation sweeps, churn-risk flagging and post-resolution follow-up. Start with one high-volume, low-risk type such as order status or password resets, and keep human approval on refunds and account changes.
Can AI replace customer service reps?: No. An agent deflects routine tickets and assists on the rest, while emotional, high-stakes and policy-sensitive cases stay with a person. Major turns the repeatable triage and follow-up into governed apps, and every sensitive write waits on a named approver, so the agent adds leverage to the support team.
How do you build an AI customer service agent?: Wire five pieces: a trigger on new or updated tickets, a reader that gathers the ticket, customer history and matching knowledge-base article, a reasoning step that classifies and drafts a reply, a Slack approval gate, and a typed write-back that posts only after approval. On Major the write-back and state live in an app the agent builds and then runs.
How do you keep an AI support agent from making mistakes?: Keep it read-only on customer data, require human approval on sensitive writes, and let it write only through typed apps with fixed inputs such as ticket id, reply body and status. Log every read and write so each action is attributable. Major provides scoped credentials, RBAC on the app and audit logging at the point the agent acts.