Execution flow

A configuration's execution flow is the graph of stages the engine runs for every turn on that config. You design it visually — drag stages onto a canvas, wire them in order — and it publishes as part of the config. It replaces the old fixed pipeline (complexity → plan → execute → review → summarize) with one you author per configuration.

You edit it as a step while building a config (Configs → open a config → the Execution flow step, right after Resources); there is no separate page and no separate save — it rides the config builder's autosave (the header shows Saving… and then Saved) and freezes into the same id@version.

The default flow

A config with no authored flow uses the default flow — today's pipeline: score the request's complexity, plan it when it's complex, run the agent (spawning sub-agents and delegators as the plan needs, with device use available on an engine build that has the X11 device backend), review, and summarize. This is exactly how every config behaves before you touch the canvas, so authoring a flow is always opt-in and never changes a config you leave alone.

The empty designer says as much and offers three starting points; the Use default button clears an authored flow back to it at any time.

The three presets

The preset gallery seeds the canvas with a working flow you then adjust:

Detailed is the default flow drawn out explicitly, so starting from it and publishing changes nothing until you edit a stage. Once a flow exists, the presets stay available as a compact Start from a preset row above the canvas.

The stages

Stages fall into four ordered groups. You place only the ones you want; the designer keeps the ordering legal and shows what the engine will run.

• Intake — an optional complexity stage. It is a branch, not a step that feeds the planner: its output chooses between the simple path (straight to the agent) and the planned path. Leave it out and the flow is unconditional — plan every turn if a planner is present, otherwise run the agent directly. Its one setting is the complexity threshold: the score (0–1, 0.65 by default) at or above which a turn takes the planned path.
• Planning — an optional planner, with an optional orchestration strategy over the resulting plan: the Plan orchestrator toggle on the planner, which executes the plan with the plan-orchestrator role instead of the deterministic step-by-step walker.
• Execution — the agent, which is always present and is the one stage you can never remove. Its capabilities are toggles on the agent, not separate stages: sub-agents (leaf specialists), delegators (with a recursion-depth cap, 4 by default), sub-delegators (deeper recursion; needs the delegator), and device use (a tool the agent may call; it also needs a Device Use model bound in the config's Models step, otherwise the engine leaves it off, and an engine build with the X11 device backend, which the published Linux x86_64 engine doesn't include yet). You enable which of these the executor may spawn; you don't sequence them.
• Finalize — an optional reviewer (running per node as an accept/revise gate, or once as a final go/no-go) and an optional summarizer.

The inbound message and the outbound response bookend every flow automatically; they are not stages you place.

Designing on the canvas

The editor has a stage palette on the left, grouped Intake · Planning · Execution · Finalize, and the canvas beside it. Selecting a stage opens its settings in a slide-over panel, where you can also remove it. Undo/redo, auto-layout, and a problems panel (with click-to-focus) work as they do elsewhere in the Console; when the flow is legal, the problems panel says how many tiers it normalizes to. The panel names anything that isn't yet a legal flow; only a legal flow is saved, so an in-progress edit never clobbers the last good one.

Each stage binds to one of your config's models by role — the agent stage to the agent role, the planner to the planner role, and so on — so which model runs each stage is the config's models step, not the flow. A flow that uses fewer stages hides what it doesn't need from the rest of the config builder: the Models step shows only the role slots the flow uses (the agent and the two researchers always show), the Device Use slot appears only when the flow enables device use, and the Agents step appears only when the agent can spawn sub-agents or delegators.

Publishing and the engine

The flow freezes into the config artifact at publish, the same immutable id@version rule as everything else. Because it is part of the config, there is no separate meter and no separate publish.