Durable agent execution
Recover long-running AI workflows from saved checkpoints, even when workers crash or external services time out.
Execution workspace
Follow a ticket from intake to routing. The execution record shows where the worker stopped, which outputs survived, and what resumed.
Open interactive demoRUN_7F21
Checkpoint inspector
Customer contextReplacement worker reused the saved output.
01 Use cases
TKT-2418 · Billing question
01 / Customer operations
Recover an interrupted support workflow with its customer context and routing decisions intact.
Explore customer operationsOP-4C01 · Update customer record
02 / CRM synchronisation
Look up a customer record update by its original operation ID and recover the confirmed result.
Explore crm synchronisationJOB-B772 · Monthly reconciliation
03 / Background jobs
Keep the job ID and continuation point while an external process runs. Resume on its completion signal.
Explore background jobsApplication design
Start with a workflow that already has clear steps. Decide which outputs need to survive, where execution can pause, and which external actions need reconciliation.
Read the engineering notesChooses the next action and defines completion.
Records what can be reused and what still needs to run.
Return results or expose an operation status for reconciliation.
02 Architecture
The execution record tracks completed work, pending events, and external operation IDs. A new worker uses that record to decide what should run next.
A worker takes a runnable step and produces a result.
Persist the step output and the next runnable position.
Save the wait condition or detect that the worker stopped.
Load the checkpoint and continue from the first unfinished step.
03 Engineering notes
A checkpoint should identify the run and workflow version, the steps that completed, and the outputs later steps need. Persist the result and the next execution position together so a replacement worker sees a consistent point from which to resume. Use worker leases or equivalent coordination so overlapping attempts cannot both advance the run.
Record a stable operation ID before making the request. If the connection drops, ask the provider whether that operation already succeeded or retry using the same idempotency key where supported. When the provider offers neither reliable lookup nor idempotency, route the uncertainty to review before sending another write.
Persist the event type, correlation ID, and optional deadline, then release the worker. Save incoming events durably and schedule a continuation when one matches the run’s wait. Matching and advancing the wait need to tolerate repeated events and an event arriving before the worker has released the run.
Interactive demo
Try a worker crash, an uncertain CRM write or a long-running job. Inspect the evidence as the run recovers.
