The promise of AI agents is that they do not just answer questions — they act. They update CRM records, create support tickets, send emails, modify database entries, call external APIs and trigger business workflows. This is where the value is: an agent that can resolve a customer issue end-to-end instead of merely describing the solution.
It is also where the risk is. A language model that generates a wrong answer produces a bad user experience. A language model that triggers a wrong action in a production system produces operational damage — a refund processed incorrectly, a ticket routed to the wrong team, a database record corrupted, an email sent to the wrong customer.
Testing agents with downstream system access requires a fundamentally different approach than testing language model outputs.
The Testing Problem
Traditional LLM evaluation asks: "Is this answer correct?" Agent evaluation asks: "Is the resulting system state correct?"
This is harder for several reasons. The correct state depends on the full context of the interaction, not just the last response. Actions can have side effects — creating a ticket also sends a notification, updating a record triggers a webhook. Some actions are irreversible — a sent email cannot be unsent, a deleted record may not be recoverable. And the same natural language request can map to different actions depending on the current system state.
This last point deserves emphasis. "Cancel my order" means something different depending on whether the order has shipped. An agent evaluated only on the text of its response may look correct while taking an action that is wrong for the current state of the system. The only way to know is to evaluate against state, not against text.
Five Evaluation Layers for Agent Testing
Layer 1: Intent Classification
Before the agent acts, it must correctly understand what the user wants. Test intent classification independently: given a user message, does the agent identify the correct action category?
Test with ambiguous requests ("I need to change my account" — change what?), compound requests ("Update my address and cancel my subscription"), and requests that sound like one action but require another ("I was charged twice" — is this a refund request, a billing inquiry, or a fraud report?).
Layer 2: Parameter Extraction
Once the intent is classified, the agent must extract the correct parameters for the action. If the action is "create a support ticket," the agent needs the correct priority, category, description and customer identifier.
Test parameter extraction with realistic inputs: abbreviations, typos, implicit parameters ("send it to the usual address"), conflicting information, and missing required fields. Verify that the agent asks for missing information rather than guessing.
Layer 3: Action Selection and Execution
Given the intent and parameters, does the agent call the correct API with the correct arguments? This is the layer where most agent testing focuses, but it is meaningless without layers 1 and 2.
Test the mapping from intent and parameters to API calls. Verify that the correct endpoint is called, the correct HTTP method is used, the parameters are correctly formatted, and error responses are handled gracefully.
Layer 4: State Verification
After the action executes, verify the resulting system state. This means querying the downstream system and checking that the expected changes were made and no unexpected changes occurred.
State verification is the most neglected layer of agent testing and the most important. An agent that calls the correct API with the correct parameters can still produce incorrect state if the API behaves unexpectedly, if there are race conditions, or if the agent's understanding of the API's behaviour is wrong.
Layer 5: Rollback and Recovery
Test what happens when things go wrong. If the agent takes an incorrect action, can the damage be contained? Test timeout handling, partial failure recovery, and the agent's behaviour when a downstream system returns an error after a multi-step operation has partially completed.
A Worked Example: The Multi-Step Failure
Consider an agent handling "I moved — update my address and reship my last order." This is two actions: update the customer record, then create a new shipment. The interesting failures happen between them.
Suppose the address update succeeds but the reshipment API times out. A naive agent reports success because the first call returned cleanly, and the customer believes both actions completed. Or the agent retries the whole request, updating the address a second time (harmless) and creating a duplicate shipment (expensive). Or the reship succeeds but sends to the old address because the agent passed a cached value rather than the freshly updated one.
None of these failures are visible if you only check whether each API call returned a 200 response. They are only visible if you verify final state: one address record with the new value, exactly one new shipment, addressed correctly. This is why layers 4 and 5 exist — the failures that hurt most in production live in the gaps between individually-correct calls.
Sandboxing and Production Testing
Sandbox Testing
Agent testing requires a sandboxed environment that mirrors production: a test CRM instance, a test database, test API endpoints. The sandbox must be realistic enough that test results are meaningful but isolated enough that test actions do not affect real customers or real data.
The most common failure mode in sandbox testing is that the sandbox diverges from production. Schema differences, data differences, and configuration differences mean that an agent that works perfectly in the sandbox fails in production.
Production Monitoring
Even with comprehensive sandbox testing, production monitoring is essential. Track every action the agent takes: what was the intent, what parameters were extracted, what API call was made, what state change resulted. This audit trail is both a debugging tool and a compliance requirement.
Monitor for anomalies: unusual action frequencies, unexpected parameter values, actions taken on records that should not be accessible. These patterns often indicate failures that are invisible at the individual interaction level.
The Practical Standard
If your agent can read but not write — if it answers questions but does not take actions — evaluate it like a language model. If your agent can write — if it changes state in production systems — evaluate it like a production service with the full rigour that implies: integration testing, state verification, rollback testing, production monitoring and audit trails.