Workflow 4.1 Beta: Event-sourced architecture

Workflow 4.1 Beta changes how workflows track state internally. Instead of updating records in place, every state change is now stored as an event, and current state is reconstructed by replaying the log. This release also adds support for provider-executed tools and higher throughput.

Link to headingWhat event sourcing means for workflows

Event sourcing is a persistence pattern where state changes are stored as a sequence of events rather than by updating records in place. Instead of storing "this run is completed," the system stores "run_created, then run_started, then run_completed" and reconstructs the current state by replaying those events.

In Workflow 4.1, runs, steps, and hooks are no longer mutable database records. They're materializations of an append-only event log. Each event captures a timestamp and context, and the runtime derives current state by processing events in order.

This architecture makes workflows more reliable in three ways:

• Self-healing: If a queue message is lost or a race condition occurs, replaying the workflow route detects missing state and re-enqueues the necessary messages. Old runs required manual intervention to recover from queue downtime; new runs recover automatically.

• Complete audit trail: The event log lets you replay the exact sequence that led to any state, which makes debugging distributed workflows much easier.

• Consistency: Events are append-only, so partial failures during a write can't leave entities in an inconsistent state. The event log is the single source of truth.

For a deeper look at the event model, including state machine diagrams for run, step, and hook lifecycles, see the Event Sourcing documentation.

Link to headingOther updates

• Improved throughput: The workflow queue system now processes many thousands of steps per second. When dependencies allow, multiple steps execute in parallel.

• Provider-executed tools: @workflow/ai now supports provider-executed tools like Google Search and WebSearch, which run on the model provider's infrastructure rather than in your workflow.

• NestJS support: The new @workflow/nest package adds build support for NestJS applications, handling dependency injection patterns so workflows integrate with existing NestJS services.

• Top-level using declarations: The SWC plugin now supports the TC39 Explicit Resource Management proposal inside step and workflow functions, enabling automatic resource cleanup.

• Custom class serialization: Client mode now supports custom class serialization, with a classes object in manifest.json that declares serializable types.

• Fixed double-serialization of tool output in @workflow/ai

Learn more about Workflow or get started with your first workflow.