AI agents for customer support are software agents that read your help docs, act across your connected systems within a granted scope, request approval before anything risky, and escalate to a person when a case exceeds what they should decide alone.
The first wave of support AI answered questions. A customer asked how to reset a seat, the bot found the article, and — if you were lucky — the ticket closed. That was deflection, and it was worth having. But deflection tops out fast, because most tickets that reach a human are not questions. They are cases: a refund that needs a record changed, an access request that needs a grant, a bug that needs a person who can actually fix it.
The interesting shift now underway is from answering to resolving — from a bot that retrieves a passage to an agent that reads the case, does the multi-step work across your systems, and either closes it or hands it to the right human with the context already assembled. That shift is worth designing on purpose, because the moment an agent can act rather than merely answer, the question changes from “is it accurate?” to “what is it allowed to do, and when should it stop?”
This post lays out that operating design as a capability ladder, and shows where each rung maps to real Insulin features.
What “resolving a case” means, versus deflecting
Resolving a case means completing the underlying work — updating the record, granting the access, issuing the credit — not just returning an answer the customer then has to act on themselves. Deflection ends when the right article is shown; resolution ends when the case is actually done or safely in the right hands.
The distinction is the whole game. A support org that measures itself on deflection is optimizing for tickets a human never touched. A support org that measures itself on resolution is optimizing for cases that got finished correctly — which is what the customer actually wanted and what your CSAT actually reflects. An AI agent that only answers can improve deflection. An agent that reads, drafts, updates, coordinates, and escalates can move resolution, and that is a different and more consequential capability.
The rest of this guide is the ladder between those two: seven rungs from “retrieve” to “escalate.” Each rung adds power, and each rung adds a reason to be careful.
The capability ladder: retrieve, draft, classify, update, coordinate, resolve, escalate
A support agent should climb these rungs in order, because each depends on the ones below it. Here is the ladder, and the Insulin capability behind each step.
| Rung | What the agent does | The Insulin capability behind it |
|---|---|---|
| 1. Retrieve | Pulls the right passage from your help docs and runbooks | Knowledge bases with hybrid search and cited sources |
| 2. Draft | Writes a reply the customer can read, in a consistent voice | Agent drafting, grounded on retrieved sources |
| 3. Classify | Tags, routes, and prioritizes the incoming ticket | Inbox app rules described in plain English |
| 4. Update | Changes a record — a field, a status, a note | An agent scoped to the CRM or ticketing integration |
| 5. Coordinate | Chains steps across more than one system | An agent executing tools against several granted integrations |
| 6. Resolve | Completes the case, or stages the change for approval | Approvals — the plan runs only when a person allows it |
| 7. Escalate | Hands a case it should not decide to the right human | The boundary set by scope and approvals, with context attached |
The rungs below the middle are read-only and reversible. The rungs above it change the world — a record, a customer’s account, money. That line is where design stops being about accuracy and starts being about authority.
Rung 1: grounding in your help docs, with cited sources
The base of every support agent is retrieval, and retrieval only helps if it is grounded in your documentation rather than a model’s general memory. In Insulin you attach a knowledge base to the agent, and it answers from your pricing, contracts, and runbooks — the agents page is explicit that this is how you get answers “with cited sources.”
Two things make this the right foundation for support. First, it is retrieval-time grounding, not training — Suger does not use your documents to train models; knowledge base content is searched at query time to ground an answer. Your help center stays yours, and an update to an article changes the agent’s answer immediately, with no retraining. Second, every result carries its source document, so a drafted reply shows what it was based on. When a customer disputes an answer, you can see whether the agent read the current policy or an old one, rather than guessing why it said what it said.
Ingestion is built for a real help center: PDF and DOCX, Markdown, HTML, and the other text formats, plus connectors that pull directly from Google Drive, GitHub, and ClickUp, or crawl a public docs site — so the knowledge stays in sync with where your team already writes it. And hybrid search combines vector similarity with keyword matching, which matters for support specifically: customers describe a problem in their words while your docs use your product’s terms, and a keyword-only index misses the overlap.
Rungs 4–5: acting across systems, inside a granted scope
An agent that can change a record needs a boundary, and in Insulin that boundary is the integration allowlist. You scope an agent to its integrations: grant access only to the connected systems the agent needs, and — in the agents page’s words — “Scope is the boundary, so an agent cannot reach data outside its job.”
For a support agent, think about what that means concretely. Say Acme runs a support agent to help work its queue. You scope it to the ticketing system and the CRM, and nothing else. Now it can read a ticket, look up the customer, update a case status, and add a note — because those systems are on its list. It cannot touch billing, cannot reach the production database, cannot open your data warehouse, not because you instructed it not to but because those tools are simply absent from what it can call. The allowlist constrains what is possible, not merely what is instructed, which is why it holds even on an unattended run.
Coordination — chaining a couple of these into one flow — is just the agent executing tools against the several integrations you granted. The agents page describes exactly this: “Agents execute tools against the integrations you grant them.” The narrower that grant, the smaller the blast radius of every case the agent ever handles. So scope a support agent the way you would scope a new hire on their first day: the ticket queue and the customer record, and you add the next system only when a real, recurring case needs it.
Rung 6: approvals for the risky step
The rung that separates a safe support agent from a reckless one is the approval gate: the agent does the reversible work automatically and holds the irreversible step for a person. Insulin builds this in. The agents page states that “Agents execute tools against the integrations you grant them, and that execution runs through approval workflows in chat” — you “see the plan before it runs, and you decide whether it runs at all.”
Split the work by reversibility and the design becomes obvious. Reversible steps — reading the ticket, retrieving the policy, drafting the reply, classifying and routing — can run unattended, because a mistake is cheap and visible. Irreversible steps — issuing a refund, changing an entitlement, emailing the customer, writing to the CRM — should stage as a proposed action a human approves. This is the same principle the Inbox app follows when it acts versus asks: the Inbox app “stages CRM actions like offer creation or field updates — all routed through Approvals before anything sends,” and “never sends email on its own.”
For a support team this is what makes autonomy tolerable at the edges. An agent that could issue a credit on its own is a liability the first time it misreads a policy. An agent that drafts the credit — the amount, the reason, the account — and drops it in an approvals queue with the full case attached is a genuine time-saver, because the agent, who did the reversible legwork, keeps the send a human decision. Let the work run; keep the consequence a choice.
Rung 7: escalation as a designed outcome, not a failure
Escalation is not the agent breaking — it is the agent correctly recognizing a case that exceeds what it should decide, and handing it to a person with the context already gathered. A well-designed support agent escalates on purpose, and the same two boundaries that make it safe also tell it when to stop.
Scope defines escalation structurally. When a case needs a system the agent was never granted — a billing adjustment, a security exception — the agent has nothing to call, so the case has to go to a human by construction. Because an agent can inspect the connections it has been given, it can say why it is handing off in plain language: the system it would need is not on its allowlist. Approvals define escalation behaviorally: an irreversible step it is unsure about does not fire — it becomes a proposal a person reviews, which is a soft escalation for exactly the decisions a human should own.
The payoff is that a handoff is not a dropped ball. The agent has already retrieved the policy, drafted the summary, and pulled the customer record; the human who picks up the case starts from an assembled brief rather than a cold ticket. Escalation done this way is faster than a queue with no AI in front of it — the easy cases never reach a person, and the hard ones arrive pre-researched.
What competitor content gets wrong: the automation-rate trap
Much of the support-AI market sells on one number — the share of tickets fully automated — and that number quietly optimizes for the wrong thing. A high automation rate rewards an agent for not escalating, which is precisely the behavior you do not want on the cases that most need a person. Deflection benchmarks measure how many customers you kept away from a human, not how many cases you actually resolved well.
The safer frame, and the one Insulin’s building blocks are shaped for, is resolution design: cited grounding so answers are auditable, scope so reach is bounded, approvals so irreversible steps stay human, and escalation as a first-class outcome rather than a miss. An agent built this way may automate fewer tickets end-to-end than one tuned purely for deflection — and resolve more cases correctly, which is the number your customers feel. Chase the deflection percentage and you will eventually automate a decision that should have escalated. Design for safe resolution and the automation you do get is automation you can leave running.
Frequently asked questions
What is the difference between a support AI that deflects and one that resolves cases? Deflection ends when the right article is shown to the customer. Resolution ends when the underlying work is actually done — the record updated, the access granted — or the case is safely handed to the right person. Resolution requires an agent that can act, not just answer.
How does an Insulin agent ground its support answers in our help docs? You attach a knowledge base and the agent answers from your documents with cited sources. Content is searched at query time to ground the answer — Suger does not train models on your documents — so a doc update changes the agent’s answer immediately.
How do I stop a support agent from touching systems it shouldn’t? You scope the agent to an integration allowlist — grant only the connected systems its job needs. Scope is the boundary, so the agent cannot reach data outside its job. A system you did not grant is simply absent from what it can call.
Can an AI support agent issue a refund or change a record on its own? Not without a person. Agent execution runs through approval workflows in chat: you see the plan before it runs and decide whether it runs at all. Reversible steps run unattended; irreversible ones stage for approval.
When should an AI support agent escalate to a human? When a case needs a system the agent was never granted, or an irreversible step it should not decide alone. Scope forces the first — it has nothing to call — and approvals hold the second. The human inherits a case with the context already assembled.
Takeaways
- The shift worth designing for is from deflection (show the article) to resolution (finish the case or hand it off cleanly). They optimize different numbers, and resolution is the one customers feel.
- Ground the agent in your help docs with a knowledge base: cited sources, retrieval-time grounding rather than training, and hybrid search that bridges the customer’s words and your product’s terms.
- Scope is the safety boundary. Grant a support agent only its ticketing and CRM systems; what you did not grant, it cannot call — on unattended runs too.
- Approvals gate the risky step. Reversible work runs on its own; refunds, entitlement changes, and customer emails stage for a person to approve.
- Escalation is a designed outcome. Scope forces a handoff when a system is out of reach; approvals hold decisions a human should own — and the person inherits an assembled case, not a cold ticket.
Ready to build a support agent that resolves rather than only answers? See how agents are scoped to the systems they need, ground one in your knowledge bases, or read the Insulin agents documentation for the full model of scope, skills, and approvals.
Sources
Primary sources for the platform rules cited above. Last verified August 19, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Suger Insulin docs: Agents — That an agent is grounded on attached knowledge bases in read or edit mode, uses only the integrations selected for it, and that action runs through in-chat approval where you see the plan before it runs.
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.