Workflow 4.1 Beta: Event-sourced architecture

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.Workflow 4.1 Beta

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.Event sourcing

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:

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

Learn more about or with your first workflow.Workflowget started

Read more

What event sourcing means for workflows

Other updates

• : 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.Self-healing

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

• : 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.Consistency

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

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

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

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

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

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