How do we recognise an agent that actually resolves something?
There is a verifiable result in the connected system: changed delivery instructions, an opened case or a confirmed appointment. Saying “done” without changing the data is not a completed service.
Ask to see the whole journey: customer identity, selected order, why the change is allowed and its confirmation. Repeat with a different user and an order already dispatched. The same request must produce a different outcome when circumstances differ.
This supports considerable autonomy without approving every sentence. Routine cases run automatically. A specific operation that fails its conditions stops, while the agent can continue along another permitted route.
What results do established vendors report?
For Tidio, Anthropic describes 71% of its own support handled autonomously, more than two million conversations and 700% growth in Lyro product adoption. The last figure concerns adoption, not sevenfold customer productivity. All are vendor case-study figures, not Tanduva results. Tidio and Claude.
“In e-commerce, customers mostly ask about issues requiring action.” — Marcin Gwizdała, Tidio CTO, in the cited study.
Look for value where the customer needs a change of state. Explaining general rules is only part of support. For example, the Kodif case study describes tools for service actions. It is architectural inspiration; permissions and business rules must come from your own operation.
Which actions can we gradually delegate to an agent?
Start with read access and reversible, low-impact changes. Expand autonomy based on operational results, not on how confident the model sounds.
| Level | Example | What must be verified |
|---|---|---|
| Information | Shipment status | Identity and correct order |
| Preparation | Complaint draft | Required details and attachments |
| Limited change | Instructions for an undispatched order | Current status and allowed fields |
| Financial action | Refund within a defined limit | Payment, permissions, earlier actions |
Restrictions belong in the system, not only the prompt. An address-change tool must not accept arbitrary database commands. It receives a case identifier and permitted fields; the server checks again that the customer and current status allow the operation.
How can we verify customers without a cumbersome conversation?
Use existing sign-in or verification appropriate to the action’s sensitivity. Public visitors can ask about delivery without logging in. Specific order details need stricter verification; a financial change may require an additional check.
Explain clearly why verification is needed. There is no reason to ask again for details the application already knows. Credentials and payment data, however, do not belong in ordinary conversation text.
Test customer mix-ups specifically. A verified account must never access someone else’s order, even through a convincing request. The system must enforce ownership checks on every relevant read and write.
What if the customer and agent disagree?
A customer’s negative response must affect the next action. Distinguish misunderstanding, missing information and disagreement with policy. Rephrasing the same point three times usually resolves none of them.
In the August 2026 customerexperience discussion participants express frustration about reaching a human. These are individual experiences, not an objective score for every product. The design implication is clear: a working route to a responsible person, rather than an empty promise.
A further discussion among Fin administrators in Intercom Community also highlights repeated disagreement. Preserve what has already been tried during handover so the operator can continue rather than restart the conversation.
How can we prevent duplicate actions during outages?
Every change needs a unique identifier and a traceable result. Repeating the same request then returns the original operation’s status, rather than issuing another refund or complaint.
Imagine the payment system accepts a refund but the response is lost. To the model, it may look like failure. Without checking status separately, it could repeat the action. The tool must distinguish rejection, completion and an outcome that remains unknown.
The same applies to work alongside an operator. If a person just changed the order, the agent must not use an old version. Recheck the state before changing it, resolving conflicts with a fresh read or a different process.
How do we test an independent service agent?
Tests must cover the conversation and data before and after the action. Correct wording about the wrong order is an error. A correct change without understandable confirmation leaves the customer experience incomplete.
Include routine cases, identity mix-ups, forbidden requests, tool outages, state changes mid-conversation and text attempting to override rules. Evaluate action selection, correctness, permissions and communication separately.
A pilot can start by proposing actions on real cases and progress to automatically performing one operation. Expansion requires measurable reliability. As action types grow, it becomes more important to see current permissions and disable one feature quickly without stopping all support.
Frequently asked questions
How is this different from a chatbot?
A chatbot can explain a process. An action-taking agent also has specific tools to perform an authorised step in a system and verify the result. The difference lies in integration and outcomes, not just the model.
Can an agent issue refunds on its own?
A limited workflow can cover precisely defined cases and amounts. It must verify the customer, original payment, earlier refunds and current status. Every action needs a traceable confirmation.
What if the system stops responding during a change?
The agent first checks whether the operation completed. It must not blindly repeat a refund or create another request. Uncertain status must be visible to staff and recorded in the case history.
Research and solution design: Tanduva with AI assistance. External case studies are identified; illustrative examples are not measured results from our clients. Editorial methodology and corrections.