Synthetic Environments

A customer-support agent can sound impressive in a demo and still collapse the first time it has to change an address, cancel a duplicate order, rebook a flight, and explain what happened afterward. That collapse usually does not come from weak prose. The model can write the apology beautifully. The problem is that the world behind the apology has state. Orders exist or do not exist. Inventory changes. Refunds create records. A bad tool call can mutate the wrong row. A follow-up answer must reflect what the agent actually did, not what it vaguely intended to do. ...

Workflow automation has a bad habit of looking impressive right up to the moment it touches reality. A demo agent can summarize a refund policy, draft a polite message, and call a refund_order() tool with great confidence. Then the real workflow asks a boring question: does this order exist, is it within the refund window, has it already been refunded, does the customer’s loyalty tier matter, and should the database state change after approval? ...

Sandbox is a comforting word. It sounds safe, contained, childlike. Put an AI agent in a sandbox and let it practice. Nothing catches fire. Nobody accidentally cancels a real flight. No production database wakes up with 37 mysterious refund requests and a very confused compliance officer. The problem is that most agent sandboxes are either too fake to teach anything, too manual to scale, or too close to production to be relaxing. The agent has to learn how to navigate persistent state, business rules, incomplete user information, tool failures, and multi-step dependencies. A static API-call dataset does not teach that. A role-playing LLM pretending to be the environment may hallucinate the rules. A hand-built benchmark is useful, but expensive to multiply. ...