Give your agent a process to follow

A workflow is a named graph of steps the MuK AI agent and the server walk through under runtime supervision. Agent steps inject a body into the system prompt or gate on a specific tool call; deterministic steps run server-side with no tokens; suspending steps wait on a human, a timer or a sub-workflow. Runs persist across many sessions, can be anchored to an Odoo record — mirroring progress to its chatter — and survive long pauses.

Nothing is bypassed: tool calls inside a run still flow through the existing approval gate, and per-agent read-only scope is honored. You get reliable, auditable multi-step automation on top of the same agent your users already chat with.

Eleven step kinds

Steps carry an inline-template body, kind-specific config, an optional advance_condition, an output_key to namespace results, and a retry policy for deterministic kinds.

A visual canvas

The Open Canvas button on the workflow and run forms opens a full-screen flow view: a palette to drag in any node kind, an inspector to edit a node or an edge (kind, condition, guard), and — in run mode — live per-node status, the taken path, the run state, and a drill-in to the child runs spawned by call_workflow, fork and foreach-map nodes. Each kind has its own icon and colour.

Branching, loops, timeouts & sub-workflows

Routing is edge-driven: normal edges carry an optional condition over the state bag (first-true wins), on_error catches a step failure, and on_timeout fires when a human_task or wait deadline elapses. A loop_back edge is the only sanctioned cycle — it requires a guard and is capped at 100 iterations so a mis-written guard can never spin forever.

call_workflow runs another workflow as a child and merges its outputs back; fork runs several branches concurrently and joins on all / any / N; foreach iterates a collection inline or maps a sub-workflow per item. Both suspend the parent to waiting_child and resume it when the child finishes — nesting is depth-capped.

Three ways to start a run

Chat — the agent calls workflow_start when the user describes a procedure that matches a workflow advertised in the <available_workflows> prompt addendum. Record event — a one-click base.automation rule runs the Start AI Workflow server action when a matching record is created or updated, driving an autonomous session to completion with no human in the loop. Schedule — reuse muk_ai_schedule's 1-minute cron worker to fire a workflow on a cron cadence, per matching record.

Versioned, capped & recoverable

Each run pins a definition_snapshot at start time, so editing a workflow — or publishing a new version — never reroutes in-flight runs. Per-run caps (lifetime, tokens, cost, max steps) and a 256 KiB state-bag ceiling keep runaway runs in check. An in-flight edit guard refuses structural changes while a workflow has live runs. Non-destructive recovery actions (Retry Step, Complete Task, Resume Now) plus a computed Needs Attention diagnostic keep stuck runs visible and unblockable, while background crons resume due timers, poll human tasks, and sweep over-age runs.