Distributed Saga Workflow Specification for Agentic Microservices
Design a resilient multi-step saga workflow chain with automated compensation logic for distributed agent tasks.
Use this template when designing fault-tolerant multi-agent orchestrations that execute stateful operations across multiple software services. It delivers a formal specification outlining forward execution steps, state persistence checkpoints, and rollback transactions.
Role: Principal Distributed Systems Architect with 15+ years of experience in microservices orchestration and fault-tolerant agent execution.
Context
- Target Orchestration Engine: {{orchestration_engine}}
- Sequential Agent Workflow Steps: {{primary_agent_steps}}
- Shared State Store: {{state_store}}
- High-Risk Failure Modes: {{failure_modes}}
- Retry and Backoff Policy: {{retry_policy}}
- Ops Notification Channel: {{notification_channel}}
Task
Author a production-ready Distributed Saga Workflow Specification that defines the deterministic orchestration sequence, forward transaction contracts, compensating actions for failures, and state persistence rules across {{primary_agent_steps}} using {{orchestration_engine}}.
Method
- Analyze {{primary_agent_steps}} and map each step to an explicit atomic transaction boundary.
- Define the payload structure and state delta committed to {{state_store}} at each transition step.
- Identify failure triggers per step based on {{failure_modes}} and categorize them into retryable vs fatal errors.
- Apply {{retry_policy}} to transient failures, defining jitter, maximum attempts, and timeout budgets.
- Design compensating rollback actions for each completed step in reverse order when a non-retryable failure occurs.
- Specify idempotency mechanisms (e.g., deduplication keys, token checking) for both forward and compensating tasks.
- Establish dead-letter queue (DLQ) ingestion and alerting workflows routed to {{notification_channel}}.
Constraints
- MUST define explicit backward compensating logic for every forward-executing agent task.
- MUST NOT leave state transitions uncommitted between step boundaries in {{state_store}}.
- Every transaction boundary MUST specify maximum timeout durations and retry ceilings.
- Specifications must avoid vague pseudo-code; use structured schema definitions.
Output format
- Workflow Topology Overview (Mermaid sequence diagram and state machine definition, max 30 lines)
- Step-by-Step Step Contract Table (Step ID, Agent Role, Forward Action, Idempotency Key, Timeout)
- Compensation Matrix (Failure Trigger, Rollback Action, Target Microservice, Invariant Validation)
- State Persistence & Telemetry Specification (JSON schema for {{state_store}} state object, DLQ routing to {{notification_channel}})
Self-review
- Verify every forward step has a corresponding, executable compensating step.
- Confirm all variables from context ({{orchestration_engine}}, {{state_store}}, etc.) are mapped into the specification.
- Check that the idempotency mechanism prevents double-spend or duplicate mutation during retries.
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.