Workflows

A workflow is a business process, drawn as a diagram rather than written as code. You lay out the steps and the paths between them in a visual editor, and wasabi runs the result.

The palette maps to BPMN:

• Tasks do the work: a user task shows a form and waits for a person, a service task runs an automated action, an AI task has a model produce a structured result, a conversation task holds a goal-directed chat that can use tools, and a sub-process runs another workflow.
• Events start, end, or interrupt a flow, including timers and messages that let a process wait for a moment in time or an external signal.
• Gateways split and merge the flow: exclusive (one path), inclusive (several), parallel (all at once), or event-based (whichever signal arrives first).

Start
  -> Submit request    (user task)
  -> Over $10k?         (gateway)
       yes -> Director sign-off   (user task)
       no  -> Manager sign-off    (user task)
  -> Create PO          (service task)
  -> End

Workflows run on a durable, event-sourced engine. The state of every run lives as tokens moving through the graph, recorded as an append-only stream of events, so a process survives restarts and can wait for minutes or months without losing its place. Each run carries a payload of variables that every step can read and update.

Workflows are where the pieces come together: a user task renders a form, a step can persist a document, data transformation reshapes the payload between steps, and a run can be moved forward straight from a document through message-driven processes.

The conversation task is the most open-ended step. Instead of a fixed form, it opens a guided chat in the person's inbox and works toward one or more goals you define — each is shown to the person, steers the assistant, and is checked off as it's met. Goals can be fixed, or generated one per item from a list in the payload (one per line of an order, say), and you choose whether every goal or only a set number must be reached before the run moves on.