8 keys to take your support AI from 20% to 95% resolution

Improving a support AI's resolution rate takes eight things beyond connecting your docs: guards checked on every answer, account context before the first message, docs split by topic, contradictions removed, filtered past conversations, flexible skills, permission to act on the account, and an analysis layer that shows why each answer failed. Each one raises both resolution and answer quality.

Connecting Claude or ChatGPT to your documentation and getting it to talk takes an afternoon. What you get is a chatbot. A support agent is a different thing.

Your best agents don't look up an answer and repeat it like a parrot.

A bot that searches the docs and returns what it finds handles the easy 20 to 30% of conversations (Zentesimal observation across production deployments, 2026): how to reset a password, where a setting lives, what a plan includes. Questions that need no judgment and no empathy.

When a team handles hundreds or thousands of users a day, the questions stop being easy.

One message carries two problems. The customer is angry because it's the third time they ask. The right answer depends on their plan, their country or a bug fixed last week. The thinking the AI needs before it replies gets harder too.

What separates a support chatbot from a support agent?

Behavior. Both read the same docs, and only one knows what to do with them.

Skills, guards and loops sound technical, and they are all the same idea: ways of telling the AI how it should behave.

• A skill is a set of instructions for one kind of situation, like a billing question or a bug report.
• A guard is a rule the agent checks before a reply goes out.
• A loop is the cycle the agent runs on every reply: read the message, look up what it needs, draft, check, send.

The eight keys below are the ones that have moved the number most in the support agents Zentesimal runs in production. They're ordered by what changes first, and they work together.

Why should every reply pass a list of guards?

Because some mistakes can't happen, ever. In every reply loop, the agent checks a short list of rules it should never break under any circumstance, and only sends the answer once all of them pass.

Some examples of what goes on that list in our deployments:

• Answer in the user's language, whatever language the docs are written in.
• Never offer a demo to a customer whose plan doesn't include one.
• Never write "contact the support team" when the agent is the support team.

Other mistakes are more forgiving. An answer a bit longer than needed, or a phrasing that could be warmer, costs little. The guard list is only for the no gos, the errors that confuse the customer or send them somewhere that doesn't exist.

Picture a customer who writes in Spanish to a product whose help center is in English. Without the guard, the agent answers in the language of the docs it just read. The answer is correct, the customer doesn't follow it, and the conversation ends in an escalation that never needed to happen.

CSA Research, a market research firm focused on language and localization, found that customers consistently prefer content in their own language, even when its quality is poor (Can't Read, Won't Buy, 2020).

The trade-off is time. Checking every reply against the list makes some answers take a little longer.

In return, after adding the guard list to a support agent in production, escalations dropped 40% and CSAT (customer satisfaction score) rose 18% (Zentesimal client data). Fewer customers left a conversation more confused than they arrived.

A slower right answer is worth more than a fast one the customer can't use.

What changes when the agent already knows the account?

The customer stops explaining who they are. Plan, usage, past conversations and billing get loaded before the first message, without the agent having to ask for them, and without the customer having to give them.

Without that context, the conversation opens with "Which plan are you on?". The customer has already told someone that, more than once, and the first two minutes go to admin instead of the problem.

With it, the opening sounds like this: "I can see your workspace hit the export limit on your plan yesterday. Here's what happened and how to get past it." Same question from the customer, completely different conversation.

That difference shows up in three places: less frustration, fewer customers abandoning the chat, and a customer who feels the agent knows them. In the answer rate bands we measured across Zentesimal accounts, customer data was the single biggest jump, from the 50 to 65% band into 65 to 80%.

Why do the docs need clearly defined topics?

Because the assistant searches by fragments. These systems pull the pieces of text closest to the question, and when one article covers five things, it can end up stitching together pieces that belong to different situations.

Anthropic, the AI lab behind Claude, describes the same problem in its work on contextual retrieval: a fragment pulled out of its document loses the context that tells the system when it applies.

A typical case: one long article explains how to cancel a subscription on the web, in the mobile app and on an annual plan with a partner discount.

A customer on the mobile app asks how to cancel. The AI pulls one step from the web flow and another from the annual plan section, and the result is an answer that's right in each sentence and wrong as a whole.

Split into narrow topics (cancelling on web, cancelling in the app, cancelling an annual plan), each search lands on one place, and the answer stays coherent.

An agent can only be as precise as the documentation it searches.

What happens when the docs contradict each other?

The assistant picks one of the two versions, and nobody knows which. Documentation gets written by many people over many years, so it piles up outdated information, features that no longer exist and articles that say opposite things.

In the help centers we've cleaned up, contradictions show up in the hundreds: roughly one for every 10 to 20 documents (help center cleanups run by Zentesimal, 2026).

Say one article says refunds are possible within 14 days. Another, written two years later after a policy change, says 30. Both look official. A human agent knows which one is current because they were there when it changed. The AI has no way of knowing.

Detecting and removing those conflicts makes the job easier immediately: fewer candidates per search, and the ones left are right.

The same AI can do most of the detection, reading the documentation topic by topic and flagging articles that contradict each other, mention features that are gone or describe flows that changed. A person then decides which version stays.

This step and the previous one are cheap compared with everything else on the list. Together, they take the same documentation from the 20 to 30% a bare chatbot resolves to the 35 to 50% band, without adding a single new source.

Same docs, cleaner, and the resolution rate moves up a full band.

How do past and internal conversations fill the gaps?

They hold what was never written down. Past tickets and the support team's internal chat contain the answers that never made it into a help center article, usually because whoever knew them answered in thirty seconds and moved on.

This source needs more work than the others, because it has to be processed before the agent learns from it.

One client's agent once offered a customer a discount coupon that had been retired months earlier. The coupon was in an old conversation, it had been valid at the time, and nothing told the agent it no longer was.

The filters we apply cover four kinds of noise: cases specific to one account, private data, commercial exceptions like discounts and refunds, and anything the product has since made obsolete.

The full breakdown, with how team chat turns into a knowledge source, is in our article on which sources to connect.

A small filtered archive answers better than a complete one nobody checked.

How should skills and prompts be written?

Flexible, and split by topic or by step. Whether they're short or long matters much less than how they're divided.

One giant prompt that covers billing, bugs, onboarding and cancellations ends up with instructions bleeding into each other. A rule meant for refunds starts showing up in answers about invoices.

A skill per topic (billing questions, bug reports) or per step (understand the problem, check the account, resolve or escalate) keeps each instruction where it belongs, and makes it easy to see which one failed when an answer goes wrong.

Flexible means describing the goal and the criteria rather than a fixed script. A script works for the exact case it was written for. Customers rarely write the exact case.

A skill that says what a good outcome looks like, and what to check on the way, handles the variations the script never imagined.

When should the agent be allowed to act on the account?

When everything above already works. This is the last step and the one that marks the biggest difference between a simple setup and a complex operation: the agent changes account settings, triggers actions in the product and touches finances, like issuing refunds or expanding a plan.

It's also what takes the share of tickets the AI can handle to around 90 to 95% (Zentesimal production accounts, 2026).

An agent with full context can explain in five accurate steps how to change the billing email. The customer still has to do it, and some come back when step three looks different on their screen. An agent that can make the change closes the ticket in one message.

How do you keep the agent from refunding everyone?

Security is what makes this step hard. Nobody wants an agent that refunds every user who asks.

OWASP (Open Worldwide Application Security Project), the nonprofit behind the reference list of security risks for AI apps, lists this as one of the main risks of AI systems, excessive agency, and recommends human approval for high impact actions and permission checks outside the model.

Zentesimal's agents issue refunds and expand accounts, with a level of control per action:

The split matters because each layer fails differently. An agent can talk itself into an exception. A line of code that checks eligibility can't be persuaded, and a human only gets the cases where judgment is worth their time.

Explaining a change and making it are two different jobs, and only one of them closes the ticket.

How do you know which key to work on next?

With an analysis layer that's almost as important as the agent itself. Every change to a skill, a guard or a source can fix one thing and break another, and without a detailed look after each change, nobody knows when or why the agent failed.

At Zentesimal, a system reads every conversation along with the agent's full reasoning: which skills it used, what it looked up, where it escalated and what the customer was talking about. Put together, those four things show patterns no single conversation does.

Picture a week where escalations go up. The headline number says something broke.

The analysis says that most of the new escalations are about invoices, that the agent searched three different articles on the same question, and that two of them disagree. The fix is a doc cleanup on one topic, and the team knows it before anyone touches a prompt.

An agent without analysis gets changed by intuition. An agent with it gets changed by evidence.

In what order should the keys go?

It also decides the order in practice. The cheap fixes come first (guards, docs split by topic, contradictions removed), then account context, then filtered conversations, and actions last, one at a time.

The data shows when each step is done and which one is next. An agent allowed to refund, working on top of contradictory docs, is a risk nobody should take.

For which numbers to watch, how not to measure AI support success covers why "not escalated" is a misleading number on its own.

Key takeaways

• Connecting docs to a large language model (LLM) resolves the easy 20 to 30%. Behavior handles the rest.
• A short list of non negotiable guards, checked on every reply, cut escalations 40% and raised CSAT 18% in production, even if some answers take longer.
• Account context loaded upfront is the biggest single jump in resolution.
• Clean docs, split by topic and free of contradictions, take the same documentation from 20 to 30% to 35 to 50%.
• Past conversations fill the gaps, once they're filtered.
• Letting the agent act takes it to 90 to 95% of tickets, with control matched to risk: the agent for low, code for medium, a human for high.
• An analysis layer over reasoning, skills, escalations and topics tells you why an answer failed and what to fix next.

How does Zentesimal build this into its support Workers?

Zentesimal's support Workers operate inside your existing stack, with the full context of each account loaded before the first message, a set of non negotiable checks on every reply and the permission to act on the account that your team decides to give them.

Every conversation gets analysed along with the agent's reasoning, so your team sees what failed, why, and what to prioritize next.

What happens in a support conversation also feeds the rest of the AI Manager: a plan limit hit during a support question becomes a conversion moment, and a frustrated customer becomes a retention signal. You can explore all use cases or read how AI chatbots turn support into a sales channel.

Book a demo