# 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. As of September 25, 2026, OpenEng AI isn't live yet. 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. > [!WARNING] Status on September 25, 2026: OpenEng AI isn't live yet > The Console and Web Console interfaces load, but the OpenEng AI API routes and the Broker aren't > deployed. Nothing can be saved or published, and no AI engine can register or connect. Pro, > Enterprise and pay-as-you-go launch in Q4 2026 and can't be purchased yet. This page describes > OpenEng AI as it works once those services are live ([status](ai.md)). 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`. *Figure: Configs → a config → the Execution flow step — the stage palette, the canvas and the problems panel. The glowing arrow marks where you are in the console.* ## 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: | Preset | What runs | Use it when | |---|---|---| | **Minimalist** | The agent only — no scoring, no plan, no review | A single-purpose config that should just answer or act directly | | **Product-ship** | Planner → agent → summarizer | Every turn should plan, execute once, and hand back a clean summary — no reviewer, no recursion | | **Detailed** | The full pipeline — complexity branch, planner with an orchestration strategy, agent with sub-agents / delegators / device use, per-node reviewer, summarizer | You want the complete default behavior laid out to tune stage by stage | 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. > **Note:** An authored flow runs only on an engine with execution-flow > support; the published `openeng` engine has it. An older engine ignores the > drawing and runs the default pipeline — identical to today's behavior — so > a stale binary is never broken by a flow, it just doesn't apply it until the > engine is updated (run the installer again: as of September 25, 2026 the release feed has no > `engine` release for the engine's self-update to fetch; see [Updates](engine.md#updates)). The designer carries a similar reminder.