The Resolution Agent

There is a category of support automation that has quietly poisoned the well. You know the shape of it: a chat widget that confidently paraphrases a help article, cannot see your account, cannot do anything about your problem, and eventually offers to connect you to a human — who then asks you to repeat everything.

That pattern is worse than no automation, because it costs the customer time and teaches them to distrust the channel. The distinction we build around is simple: an agent that can only answer is a search box with better manners. An agent that can act is support.

What "act" means

Take the most common contact in retail or subscription support: "Where is my order?"

An answering agent retrieves the policy on shipping times and restates it. A resolution agent looks up the order, sees the carrier scan stalled four days ago, recognises that against the client's own rules this qualifies for a reship, checks inventory, and asks the customer whether they would like it reshipped or refunded — then does it, and confirms.

That is not a harder AI problem. It is a harder engineering problem, because it requires the agent to be wired into the order management system, the inventory system, the payment processor and the CRM, with permission to write.

Most of the difficulty in this domain is not making the model smart. It is making the actions safe.

How we build it

Ground the conversation in the account. Before the agent says anything substantive, it establishes who it is talking to and pulls their context — orders, subscriptions, prior tickets, entitlements. The agent's answers are constrained to what those systems actually say. It cannot tell a customer their order shipped if the order system says otherwise, because it is not generating from memory; it is reporting.

Classify intent and check policy. The agent determines what the customer wants and looks up whether it is permitted for this customer, this order, this plan. Return windows, refund eligibility, plan-change rules, regional variations. These are client business rules, and they live in a rules layer the client can change without a model retrain — not baked into a prompt.

Propose the action. The agent works out what it can do, and states it plainly. If more than one remedy is available, it offers the choice rather than picking.

Execute within limits. Every tool the agent can call has a bounded blast radius: a refund cap, a rate limit, an allowlist of order states it can operate on. Actions are idempotent, so a retry cannot double-refund. Anything above the threshold becomes a human approval step rather than a failure.

Wrap up. Summary, disposition code, ticket updated, customer told exactly what happened and when to expect it.

Escalate with everything. When the agent hands off, the human gets the full conversation, what the agent already checked, what it already tried, and why it stopped. The customer does not repeat themselves. This single detail does more for satisfaction scores than most of the rest combined.

The guardrails are the product

We have found that the guardrail design, not the conversational quality, determines whether one of these builds survives contact with real volume.

Actions are tiered by consequence. Reading account data is free. Reshipping within a value threshold is autonomous. Refunds above a limit, account closures, plan downgrades, anything touching stored payment details or credentials — those require a human, always, or are not agent-accessible at all.

The agent never invents policy. If it cannot ground an answer in retrieved policy or account data, it says it does not know and escalates. We tune deliberately toward escalating too often at launch and tightening from there, because the cost asymmetry is brutal: an unnecessary escalation costs a few minutes of agent time, while a confidently wrong refund decision costs trust you do not get back.

And every action is logged with the reasoning and the evidence, because when someone asks why a customer got a refund they should not have, "the AI decided" is not an acceptable answer.

Agent-assist is the underrated sibling

Not every contact should be automated, and the copilot sitting beside a live human rep is frequently the higher-return build.

Same grounding, same systems, different surface: the rep sees drafted responses, surfaced account context, the relevant policy, and suggested next actions, and stays in control of all of it. Adoption is easier because nobody is being replaced, the risk profile is lower because a human approves everything, and the quality signal is excellent — every time a rep edits a draft, you learn something about where the agent is weak.

We often ship agent-assist first and use what it teaches to decide what is safe to automate outright.

What we measure

Containment, not deflection. Deflection counts conversations that did not reach a human, which flatters you when customers give up. Containment counts conversations that actually ended resolved.

Alongside it: resolution accuracy sampled by QA, escalation quality (did the human have what they needed), repeat contact rate within seven days, and CSAT split between contained and escalated conversations. The repeat contact rate is the honest metric — a "resolved" ticket that generates a second contact two days later was not resolved.

What it is not

It is not a replacement for a support organisation. The contacts that reach a human after this is running are harder, angrier and more consequential than the average contact today, and that team needs to be staffed for judgement rather than volume.

It is also not a project that finishes. Policies change, products change, and the agent's grounding has to change with them. The clients who get the most out of these builds treat the agent as a system they operate, not a feature they installed.

---

Customer experience is one of the domains we build agentic workflows in. If you have a support process worth automating properly, describe it in the console or run /estimate.