Execution Plans

An execution plan (usually just “a plan”) is a named, persisted workflow: you give a free-text goal, and Contenox stores an ordered list of step descriptions locally. One plan is active at a time; the runtime can advance it step by step, pause, recover from failures, or replan when the situation changes.

Plans are separate from a normal chat session or a one-shot contenox run: they are built for multi-step work you want to inspect, resume, and steer over time.

Planner and executor

Plan mode uses two roles, each backed by a task chain (the same JSON chain model as everywhere else in Contenox):

  • Planner — takes your goal (and context) and produces the step list (structured as an ordered sequence of strings the runtime can track).
  • Executor — takes the current step and runs it through the chain engine (model, hooks, tools) like any other Contenox run.

You choose which chains act as planner and executor when you integrate via CLI or API. That separation keeps “what to do next” and “how to do this step” explicit and swappable.

What gets stored

Plans are persisted (typically alongside other Contenox local state). The runtime tracks which steps are pending, in progress, or done, and which plan is active, so you can list plans, switch the active one, or delete plans you no longer need.

Typical workflow

  1. Create a plan from a goal — the planner fills in the ordered steps.
  2. Execute the next pending step — optionally with shell or other hooks enabled for that step, or in auto mode to run until completion or failure.
  3. If something goes wrong — retry the step, skip it, or replan so the planner adjusts the remaining work.

The exact subcommands and flags are listed in the CLI reference.

API and Beam

The same plan lifecycle is available programmatically (HTTP APIs for integrations) and through Beam (web UI) on deployments that expose it — so teams can drive plans from scripts, services, or a browser without reimplementing storage or state machines.

See also