Execution plans
The plan is the contract. A Task Agent never improvises against your systems: the brief becomes an ordered set of steps you can read and correct before anything runs, and the plan — not the conversation — is what actually executes.
What a step is
A plan is a set of steps forming a dependency graph. Each step has:
| Field | Meaning |
|---|---|
| Kind | Tool — one named tool call — or reasoning, a thinking step with no tool. |
| Tool & input | For tool steps: the exact tool and the input the agent should construct. |
| Depends on | Steps that must complete first. Independent steps may be worked in any order. |
| Run input | Whether the step receives the payload a webhook trigger delivered. |
| Instructions | What the step should actually do, in words. |
| Expected output | What “done” looks like, so failure is detectable. |
The plan renders in the chat as markdown and in the blueprint panel as a timeline. You edit it by talking to the planning agent — “make step 2 depend on step 1”, “split the summary into its own step” — never by hand-editing fields, which keeps every revision inside the conversation record.
Validation
Saving validates the graph: duplicate step IDs, steps that depend on themselves, dependencies on steps that don’t exist, and cycles are all rejected with a message naming the offending step. A plan that saves is a plan that can execute.
How a plan executes
Each run walks the graph in dependency order inside its own execution
session. Steps report pending → running → completed, or failed, or
skipped.
- Retries are per step. A failing step gets up to three attempts, with corrective feedback between them. After the third failure the step fails for the run.
- Failure flows downstream. Steps that depend on a failed step are skipped, and the run’s failure report says which step broke and why.
- Approvals pause, they don’t consume. A step waiting on a human approval is paused, not failed — though a rejected approval does count as a failed attempt.
- There is no run-level retry. A failed run is not re-attempted; the next scheduled slot is the next attempt.
The full step-by-step record of every run — inputs, results, errors, pauses — is the run’s Execution Log; see Schedules & runs.
The saved plan is a snapshot. Editing an agent’s plan later (via Edit Plan on its detail page) changes future runs only — a run in flight finishes on the plan it started with, and its log shows exactly which plan that was.
Steps marked as depending on run input only do useful work when a webhook delivers that input. A plan built around run input, fired from a cron schedule, runs with nothing to work on — the planning agent will warn you, but it’s worth designing deliberately.