How do you test multi-step agent workflows?

Why step-by-step testing misses the real bugs

Each step of a workflow can pass on its own while the sequence still fails. Step three depends on what step one actually wrote. If step one half-succeeded, the failure only appears later. Testing steps in isolation hides exactly the class of bug that multi-step workflows introduce.

Test the sequence against real state

Run the whole workflow against an environment that persists state between calls, so step three sees the genuine result of step one. Then assert on the end state: are all the records correct, consistent, and free of duplicates. The agent's own summary of what it did is not evidence. The state is.

Break it on purpose

The interesting behavior is what happens when a step fails partway through. Inject a rejected write, a rate limit, or a timeout in the middle and check that the agent notices, recovers or rolls back, and does not leave the system corrupted. A stateful sandbox environment makes it practical to seed a starting state and inject these mid-workflow failures on demand.

pythondef test_onboarding_workflow_rolls_back_on_partial_failure():
    env = sandbox.reset()
    # make the 3rd step fail: Salesforce rejects the account write
    env.salesforce.fail_next_write(reason="validation_rule")

    run_agent("onboard the new customer Acme Corp", env)

    # assert on final STATE across services, not the agent's summary
    assert env.slack.messages() == []          # nothing announced prematurely
    assert env.salesforce.accounts() == []     # failed write left no partial row
    assert env.stripe.customers() == []        # no orphaned billing record
    # the workflow either completes fully or leaves nothing behind

The agent will often claim success. Only the end state across every service tells you whether the rollback actually happened.