ON THIS PAGE ▾
A chatbot answers. An agent acts. It decides which tool to call, reads the result, decides what to do next and keeps going until it believes the task is done. It might search, update a record, send a message or spend money along the way.
That shift changes what testing is for. A wrong answer is embarrassing; a wrong action can be expensive, and the mistakes compound across steps. Judging only the final message misses most of what can go wrong.
What makes agents harder to test
Three properties make agents different from the software most teams are used to testing. They are non-deterministic, so the same task can take different routes. They are multi-step, so a small early error can steer everything after it. And they have side effects, so a mistake leaves something behind in a real system.
The OWASP Top 10 for LLM Applications includes Excessive Agency for exactly this reason: giving a model more tools, more permissions or more autonomy than the task needs widens the damage a mistake or an attack can do. Testing is how you find out whether the limits you intended are the limits you built.
What to test
Task success
Does the agent reach the goal correctly across typical, awkward and ambiguous tasks? Judge outcomes against agreed criteria rather than exact steps, because several routes may be acceptable. Include tasks that cannot be completed, to see whether the agent says so or bluffs.
Tool selection and use
Check that the agent picks the right tool, passes the right parameters and uses the result correctly. Misread output and wrong parameters are among the most common quiet failures, and they often look fine in the final message.
Planning and multi-step behaviour
Look for loops, dead ends, skipped steps and drift away from the goal. Traces make this visible: repeated identical calls and long runs with no progress are the signature of an agent that is stuck.
Permissions and approval gates
List every action the agent can take and mark which ones should need a person's approval, especially anything that is hard to undo. Then test the gate: that it appears where agreed, that rewording a request cannot walk around it, and that the confirmation describes the action accurately.
Hostile content
Agents read pages, files and tool output, and any of it can contain instructions written by someone else. Test whether text embedded in that content can redirect the agent. This is usually called indirect prompt injection, and it is one of the more realistic ways an agent gets misled in practice.
Failure and recovery
Make tools fail on purpose: errors, timeouts, empty results, partial data. A good agent retries sensibly, tells the user what happened or hands over. A poor one invents a result or tries the same thing forever.
Limits and runaway behaviour
Check the ceilings on steps, time and spend, and what happens when one is reached. An agent that stops cleanly and explains why is behaving well; one that quietly continues, or stops with no explanation, is not.
A workable approach
- Map the agent. Its goals, tools, permissions, data access and the systems it can change.
- Rank by consequence. Actions that change data, spend money or reach customers come first.
- Write task scenarios. From normal to ambiguous to hostile, plus tool-failure cases.
- Run in a safe environment. Use sandboxed or simulated tools, and capture full traces.
- Review traces with a person. Judge whether each action was appropriate, not just whether the answer sounded right.
- Keep what you find. Confirmed failures become scenarios you re-run after every change to the model, tools or permissions.
THE UPDOER APPROACH
How UpDoer approaches this
Our seven-step methodology applies directly. We map the agent's tools and permissions first, rank them by consequence, and design scenarios including hostile and failing-tool cases. AI helps us draft task variations, cluster similar failed runs and summarise long traces, but a QA engineer reads the traces behind every flagged run, judges whether actions were appropriate and confirms that a failure reproduces before it is reported. The release recommendation stays with a person, and we state plainly what was not tested.
See our AI Agent Testing service, the related AI Application Testing work, or our notes on where AI sits in our process.
Questions to answer before an agent touches real systems
- Which actions can it take, and which of them can it not undo?
- Where does a person approve, and can the approval be bypassed by rewording?
- What stops a runaway: steps, time, spend?
- What does it do when a tool fails or returns nonsense?
- Can we replay and review a full run after the fact?
If you would like a second pair of eyes on your own situation, schedule a meeting and tell us about your product, your delivery process and the quality questions you are facing.