An agent can pass a prompt test and still fail in production. The model may answer correctly in isolation, then choose the wrong tool, receive stale data, retry a successful write, or get stuck when a person is unavailable. Integration tests need to follow the whole journey rather than stopping at the generated text.

Test a real slice of work

Choose one representative workflow and give it realistic inputs. Include the normal request, incomplete information, an ambiguous request, a request that should be refused, and a case that needs approval. Test with more than one tenant and role so a lucky happy path does not hide an authorization problem.

Watch the boundaries

Check what enters context, which sources are retrieved, which tool is selected, and whether its arguments are valid. Confirm that the server—not the model—decides whether the actor may read or change the record. Inspect the side effect itself: the exact fields changed, the destination, the idempotency key, and the audit entry.

Make failure ordinary

Simulate a slow provider, a duplicate event, a malformed tool result, a stale record, a full queue, and a model that returns a valid shape with an invalid value. Decide which failures may be retried, which need a person, and which should stop the workflow. A test that only checks for a 200 response is not checking enough.

Keep a small regression set

Save the cases that once failed, along with the expected safety boundary and outcome. Run them after changing a prompt, tool schema, model, retriever, or policy. The goal is not to prove that the agent never makes a mistake. It is to make important mistakes visible before customers find them.