Open-source customer service agent examples, handoff included

What an example has to show before it is worth copying

Most customer service agent examples stop at the resolution: the question answered, the ticket closed, the conversation counted. The useful ones keep going. If your queue touches money, account state or the product itself, the question changes. Where does the agent stop, and what does the person on the other side see when it does?

A refund makes the difference plain. An agent that answers "why was I charged twice?" from a help article has done research. An agent that reads the invoices, finds the duplicate and moves the money has done something else. A page showing only the first looks the same whether the second has a gate or not.

So an example worth copying carries three things. The system the agent read, the action it took, and the person who approved it. A fourth helps a reviewer: the artifact it handed back. A reply, a filed issue or a routing tag is the thing someone opens at nine in the morning.

Four handoffs carry that shape: what the agent read, what it did, who approved it, and the artifact it left behind. They illustrate one support setup rather than measuring it, so read the pattern rather than the figures.

The setup behind these examples

Kortix runs its own support on the platform and writes up the shape of it, which is unusual enough to quote:

"Our support inbox in Plain is connected to an agent running on Kortix. Every inbound thread spawns its own isolated session with scoped access to the systems a support issue can touch: the product's knowledge, the codebase, and Stripe. It investigates, resolves what it can, and stops at a human for sensitive actions." (Kortix)

Three systems and one boundary, named before any outcome is claimed. That order is worth copying too. A vendor that opens with a resolution rate has told you what it measures. A count says nothing about the ticket where the agent would have refunded the wrong invoice.

The read is the easy part to fake in a demo. A connected-apps list proves a credential exists. It does not prove that one session can hold an invoice history, a stack trace and a help article at once. What you can check is the action and the approval, because both leave a trace someone else can open.

The rule that decides where it stops

The gate is configuration, not a feature list. In Kortix it is a policy block in the project manifest, and a new project starts without one. Approval gates you set. Off until you set them.

1policy:2  default_mode: risk3policies:4  - match: gmail.send_email5    action: require_approval

Two lines do most of the work. The mode decides the default: risk runs a read and holds a write or destructive call for a person. Rules then narrow it: a rule matches a tool path such as gmail.send_email with action: require_approval or action: block, and conditions limits it to calls whose arguments match. Approval hold defaults to 24 hours; approvals.ttl sets it. The keys and their defaults are in the manifest reference.

Read that block as a reviewer and you learn more than a product tour tells you. A refund call with a rule over the amount, a send held for every outside address: each is a sentence about what the agent may do alone. The block is a file in the repo, so a change to it is reviewed, and a support lead can find out who loosened a rule and when.

A vendor that will not show its equivalent is asking you to trust a promise about money.

What the person on the other side sees

During a hold, the customer sees nothing yet, and that is the design. The reply sits as a draft until someone releases it. On a triaged inbox that means a message that arrives labeled and answered only when a person presses send. On a billing question it means an answer that quotes the invoice, checked by the person who owns refunds.

The escalation example is the clearest one, because there the agent has no customer-facing channel at all. It routes, links and alerts, and a team lead decides what the customer is told, so nobody promises a fix time the team has not agreed to.

That is the detail to ask for in a demo: the customer's view during a held action, not the operator's dashboard after it. A vendor that can show both has built the handoff. One that shows only a resolution chart has built the easy half.

How to write your own test ticket

You do not need a vendor's example when you have last month's queue.

1. Take the ticket that pulled a senior engineer off their work. That is the one an agent has to earn.
2. Write the answer you would least like an agent to send. Then write what a good one contains: the invoice number, the code path, the policy.
3. Name the systems it has to read to get there, and connect nothing else. Scope is half the test.
4. Name the person who approves, by role rather than by name, and say what they see on the approval prompt.
5. Add the ticket that should stop: a refund over your limit, a send to an address outside your domain, a plan downgrade.
6. Read the record afterwards. If you cannot tell which call was held, who released it and what the customer saw, the gate is decorative.

Run all six against a candidate and you will know more than any list of examples tells you. Then change one rule and watch what the difference does to the queue.