Skip to main content
Orchestration

Workflow Automation

Orchestrate multi-step agent tasks with durable workflows.

Orchestrate multi-step agent tasks with durable workflows that survive crashes and restarts. Build them with RivetKit’s workflow() run handler, where each ctx.step() is recorded, retried, and resumed independently, and the output of one step can feed into the next.

Basic workflow

A workflow is the durable run handler of an actor. Wrap it in workflow() and drive a multi-step agent task as an ordered series of steps: clone the repo, let an agent fix the bug, then run the tests. Trigger work by sending to a queue; the workflow loops and waits durably for the next message.

Session creation and prompting happen within the step that uses them, so a session never has to outlive the work it backs (sessions are ephemeral and would not survive a replay). Steps reach the agentOS VM, a separate actor, through ctx.client().

Agent chaining

Output of one agent session feeds into the next. Each session is created and completed within its own step, and data passes between steps through the VM filesystem (a review file) and step return values.

Recommendations

  • Build the actor’s run handler with workflow() so each ctx.step() is durable: recorded, retried, and resumed independently across crashes and restarts.
  • Keep step names stable across code changes. Renaming a step breaks replay for in-progress workflows.
  • Create and close sessions within the step that uses them. Sessions are ephemeral, so keep their lifetime scoped to one unit of work.
  • Pass data between steps via the filesystem or step return values, not session state.
  • Keep state changes and other actor-local side effects inside ctx.step() callbacks; use non-step workflow code (queue waits, loops, sleeps) only for orchestration.
  • Reach the agentOS VM, a separate actor, from inside a step with ctx.client().
  • See Workflows for the full workflow API reference including timers, joins, and races.