Key facts.
- GAIA (arXiv:2311.12983) tests agents on 466 real-world tasks requiring multi-step tool use and planning, even the strongest models score well below human performance, and complex multi-tool tasks show the largest gaps (GAIA, arXiv:2311.12983).
- The saga pattern (Garcia-Molina and Salem, 1987) handles long-lived transactions as sequences of local transactions, each paired with a compensating transaction that reverses its effects on rollback.
- MAKER (arXiv:2511.09030) found that errors in intermediate steps of multi-step tool chains corrupt downstream steps rather than producing clean failures, partial completion can be harder to recover from than a full abort (MAKER).
- Non-idempotent tool calls (creating records, sending emails, initiating payments) that have executed successfully within a failed workflow create orphaned side effects that persist in external systems after the agent's session ends.
- Orchestration-based sagas, where a central coordinator manages the saga state and compensating transactions, are more suitable for agent architectures than choreography-based sagas, because the agent already serves as the central orchestrator of tool calls.
Why partial completion is harder than total failure
A chain that fails on step 1 is easy: nothing happened, nothing needs to be undone. A chain that fails on step 4 of 6 has three completed steps that wrote to external systems. A record was created. An email went out. A payment got reserved. Those don't disappear when the agent's session ends. They stay in the external systems, orphaned, with no workflow coming to clean them up.
Sagas solved this in distributed systems. Each step in the saga has a compensating action that reverses it. The saga fails at step 4: the orchestrator runs compensating actions for steps 3, 2, and 1, in reverse. The system returns to a consistent state. For agents: before the workflow begins, define and register the compensating call for every tool call that has a side effect. Workflow fails partway? The agent runs those compensating calls in reverse.
Implementing saga-style recovery in agent workflows
Three pieces. Side-effect registration: before the workflow starts, the agent or its scaffolding registers a compensating action for each tool call that has a side effect. Failure detection: when a tool call fails, the orchestrator identifies which prior calls have compensating actions registered. Compensating execution: those calls run in reverse order, each logged with the same audit trail as the original action. The result is a workflow that either completes fully or fails cleanly. No orphaned side effects.
Saga implementation options for agent tool chains
| Approach | Complexity | Coverage | Agent framework support |
|---|---|---|---|
| Manual compensating calls | Low | Tool-call specific | Universal (any framework) |
| Orchestration-based saga | Medium | Full workflow | Custom scaffolding required |
| Event-sourcing with replay | High | Full with audit trail | Specialized infrastructure |
| Idempotency-only approach | Low | Partial (no undo for non-idempotent) | Universal (limited) |
VibeModel's Pattern Intelligence Layer identifies which multi-step tool call sequences have historically shown partial completion failures, the cases where some steps succeeded before the workflow aborted. It surfaces which tool chains most urgently need compensating transaction design, and which tool calls are the most common failure points. That tells you exactly where to invest the saga effort first.
Frequently asked questions
What if a tool doesn't provide a compensating API (no undo)?
Two options: first, confirm before executing non-compensable actions (a human approval step makes the non-reversibility explicit). Second, hold non-compensable actions until the reversible steps have all succeeded - execute the non-reversible action last, when there's the least remaining workflow risk.
How do we handle compensating transactions for email sends or notifications that can't be unsent?
Treat email sends as non-compensable and apply the "execute last" strategy: if the workflow requires sending an email and also writing to a database, write the database record first (compensable) and send the email only after the record write succeeds and is verified. The email becomes a final confirmation, not an intermediate step.
Is the saga pattern overkill for short tool chains?
For a two-step chain where step 1 is reversible, manual handling works. Sagas earn their keep at four or more steps, when multiple non-compensable actions are involved, or when regulations require a clean rollback audit trail for partial failures.