Guide
How to test AI agents your customers talk to
Agents that act on a customer's behalf need more than answer checks. Here is how to test them across chat, voice and text.
By RealHumanTests Updated 13 minute read
Knowing how to test AI agents matters more than it used to, because the agents your customers talk to no longer just answer questions. They issue refunds, change bookings, update addresses, cancel subscriptions and apply credits. When an agent that only talks gets something wrong, a customer is misinformed. When an agent that acts gets something wrong, money moves, orders change and records are updated, sometimes in ways that are hard to undo.
This guide explains how to test customer-facing AI agents across chat, voice and text, with a focus on agents that take actions. It is written for the business owner or CX lead responsible for the agent, not the engineer who built it, and every step can be done without access to the model or its prompt.
How agents differ from chatbots
A traditional chatbot has one job: produce a good reply. Testing it means checking whether the replies are accurate, clear and appropriate. Our guide on how to test a chatbot covers that method in detail.
An AI agent adds three things that change how you test:
- Tools. The agent can call systems such as your order database, billing platform or calendar. Each tool is a new way for things to go right or wrong.
- Decisions. The agent decides when to use a tool, which customer the action applies to, and whether the customer is eligible. Eligibility decisions are where policy mistakes happen.
- Consequences. A wrong answer can be corrected in the next message. A refund issued to the wrong order, or a booking cancelled instead of moved, cannot always be.
That means testing an agent has two halves: what it said to the customer, and what it actually did. You need to check both.
Map every action the agent can take
Start by listing every action the agent can perform, with the rules that govern each one. Ask the team or vendor that configured it for this list, and write it in plain language:
| Action | Allowed when | Never allowed |
|---|---|---|
| Issue a refund | Order within the return window, item not marked final sale | Above the standard amount without a person approving |
| Change a delivery address | Order not yet shipped, customer verified | After the order has left the warehouse |
| Cancel a subscription | Account holder verified | Without confirming which subscription, when there are several |
| Apply a discount | Valid published promotion | Made up codes, or stacking beyond policy |
The table above is an example; yours will reflect your own policies. This list is your answer key. Without it, testers cannot tell whether an agent that happily issued a refund did the right thing. If nobody can produce this list, that is a finding in itself: the agent is making decisions under rules nobody has written down.
Set up a safe test environment
Testing actions means actions will happen. Decide in advance where they will land. The options, from safest to most realistic:
- A staging copy of the agent connected to test versions of your systems. Safest, but make sure it runs the same model, prompt and knowledge as production, or you are testing something your customers never see.
- Production with test accounts: real agent, real systems, accounts and orders created for testing and flagged so your team can reverse any action.
- Production with limited real transactions, such as small real orders placed by testers and then refunded. Most realistic, and it needs clear sign off from whoever owns the systems involved.
How to test AI agents that take actions
For each action on your list, write scenarios that cover the happy path, the boundaries and the attempts to go around the rules. For a refund action, that might look like:
- Clearly eligible: an order well inside the return window. Does the agent complete the refund without making the customer work for it?
- On the boundary: an order on the last day of the window, or one day past it. Does the agent apply the rule correctly, and explain it kindly?
- Clearly ineligible: a final sale item. Does the agent refuse politely and offer what is actually available?
- Ambiguous: a customer with two recent orders who says "refund my order". Does the agent ask which one, or guess?
- Pressure: a customer who insists, gets angry, or claims a previous agent promised the refund. Does the agent hold its line, and does it offer a person when appropriate?
- Changed mind: a customer who asks for a refund, then asks for an exchange instead halfway through. Does the agent undo or stop the first action?
Ambiguity and changed minds are where agents most often misbehave, because the customer's intent shifts during the conversation. Real people change their minds constantly; make sure your testers do too.
Customer: Can you cancel my order please
Bot: Done! Your order has been cancelled.
Tester note: Test account has two open orders. Agent did not ask which one. It cancelled the older order; I meant the newer one.
Test across chat, voice and text
Many businesses run the same agent, or agents built from the same configuration, on more than one channel. Each channel breaks differently, so test each one your customers use.
Chat
Chat customers write in fragments, paste order numbers with extra spaces, send three messages before the agent replies, and switch tabs mid conversation. Test all of those. Check how the agent displays confirmations: a customer should always be able to see exactly what was changed.
Voice
On the phone, customers cannot scroll back. Confirmations have to be spoken clearly, and numbers such as order IDs, dates and amounts have to be read back. Accents, background noise and interruptions all affect whether the agent hears the right thing before it acts. Our guide on how to test a voice agent covers this in depth.
Text and messaging
SMS and WhatsApp conversations are slow and asynchronous. A customer may reply hours later, from a different context. Test whether the agent remembers what it was doing, whether it re-verifies the customer before acting on a late reply, and whether it handles short replies like "yes" or "ok" safely when the question they answer is no longer on screen.
Test the customers who push back
Agents that take actions attract customers who try to talk them into things. Most are not malicious; they are simply negotiating the way people do with human staff. Your testers should try:
- Claiming a manager or previous agent already approved something
- Asking for a discount or credit just for being a loyal customer
- Asking the agent to make an exception "just this once"
- Giving partial or conflicting identity details
- Asking the agent to act on someone else's account, such as a spouse or parent
An agent that can be talked into unauthorized actions is a direct cost to the business. We cover this style of testing in more detail on our human red teaming page. It focuses on customer behavior, not security penetration testing.
Score the conversation and the outcome
Use the same rubric for every session so results are comparable. Our eight criteria apply to agents as well as chatbots, with two carrying extra weight:
- Got it done now includes whether the correct action happened, on the correct account, with the correct details.
- Stayed in bounds now includes whether the agent performed any action it had no authority to perform, not only whether it said something it should not have.
The other six (Understood me, Got it right, Effort, Handoff, Tone and Would I stay) work exactly as they do for a chatbot. Each is scored 1 to 5 with a written reason. See the full rubric for what a 1 and a 5 look like.
Verify what actually happened
This is the step most agent tests skip. After each session, someone with access to the back office should check what the agent actually did, and compare it with what the agent told the customer. Look for:
- Actions the agent said it performed but did not
- Actions the agent performed but did not mention
- Actions performed with the wrong amount, date, item or account
- Duplicate actions, such as two refunds for one request
- Notes or case records that do not match the conversation, which confuse your staff later
A conversation can read perfectly while the underlying action is wrong. The customer will not find out until their statement arrives, and neither will you unless you check.
How often to test
Test before launch, after every meaningful change, and on a regular schedule. Changes include new tools, new policies, prompt edits and model updates from your vendor. The last one is easy to miss: vendors update underlying models, and an agent that handled refunds well last quarter can behave differently this quarter without anyone on your team changing anything. Our guide to AI drift explains why, and our ongoing monitoring page describes a light monthly check.
A short checklist
- Every action the agent can take is listed, with the rules for when it is and is not allowed.
- A safe environment is agreed in writing, with a way to reverse test actions.
- Each action has happy path, boundary, ineligible, ambiguous and pressure scenarios.
- Testers change their minds mid conversation at least once per action.
- Every channel customers use is tested, not just the one that is easiest to reach.
- Every session is scored on the same rubric, immediately, with written reasons.
- Someone checks the back office after every session and compares it with the transcript.
- The test is repeated after changes and on a schedule.
If you would like an independent panel to run this for you, RealHumanTests supplies real people who play your customers against the agent you already run, scores every session on a published rubric, and returns every transcript with a plain verdict. We diagnose only and never sell the fix. Learn more about AI support agent testing or how an Audit works.