How does an AI agent simulation work?
A simulator stands in for everything the agent touches. Fake tools return realistic responses, a simulated user plays the customer, and sandboxed code execution keeps any generated code away from live systems. Teams then score the resulting agent trajectory with AI agent evals, checking the path the agent took as well as its final answer. A simulation is useful only when its constraints resemble production.
What should an agent simulation include?
The failures the happy path never shows. Script tools that time out, return a rate-limit error, send a malformed or partial response, or succeed slowly after the agent has already given up. Add users who change their mind halfway, give contradictory details, or ask for something outside the agent’s permissions. The cases worth simulating are the ones that would cost money or trust if they happened live: a duplicate write, a wrong record updated, an action taken without approval.
How do we simulate agent failures before production?
We turn production failures into simulated cases. In the AI sales agent we built for Open Loyalty, a CRM write timed out, the agent retried, and both calls landed, so one conversation produced two lead updates. After the fix, the evaluation set gained a simulated timeout asserting one lead update per turn, as we described in LangGraph agents in production.
Three rules from our delivery work decide whether a simulation proves anything:
- In-memory fakes drive the outcome matrix. A stock OpenAPI mock serves one canned example per endpoint and cannot vary its answer by input, so it gets a single smoke test that the real client is wired to the real contract.
- Fakes copy the dependency’s real return type. A fake that misstates the shape passes every test and fails in integration, and a fake that ignores the prompt makes any test of prompt behavior pass by construction.
- The valuable assertions are negative: when a request should be rejected, the outbound call ran zero times.
Before we trust a simulated case, we plant the defect it exists to catch and watch it fail.
When does agent simulation matter, and what can it not replace?
Run simulations before agent deployment and again after any change to models, prompts, tools, or permissions. Simulation narrows the unknowns; it does not remove them. Real users and real dependencies still produce conditions no script anticipated, so pair it with online evaluation of production traffic and feed what goes wrong back into the simulated set. Passing a toy environment is not evidence of production reliability.