Planning Engine

What it is

The component that turns a goal into an ordered strategy before the work is done: a sequence or graph of intended steps, their dependencies, the effects each is expected to have, and how each will be judged to have succeeded. Its output is a plan object that something else executes, and it is also responsible for revising that object when the world turns out differently.

Why it matters

Without an explicit plan, a strategy exists only implicitly in whatever tool calls happen to be emitted, which means it cannot be seen until after it has been paid for. An explicit plan can be priced, checked against policy, shown to a person before anything irreversible runs, cached and reused for recurring goals, and compared afterwards with what actually happened. For any goal that touches the world more than trivially, the plan — not the final answer — is the artefact worth reviewing.

Ordering is not splitting

Producing an ordered strategy and dividing work into smaller units are different operations that frequently travel together. A strategy is about sequence, dependency, and intent: what must be true before step four, what step four will change. A division is about size and boundaries: what the pieces are and how their results rejoin. A strategy can be entirely flat and still be a plan, and a set of pieces with no ordering is not one.

Key decisions

• When the strategy is produced: once before execution, refreshed every step, or revised only when an observation contradicts an assumption it recorded.
• How it is represented — prose, an ordered list, a dependency graph with typed steps, or a formal language the executor can reject before running anything.
• Whether steps name concrete tools at planning time or stay abstract until execution. Concrete steps can be validated early; abstract ones survive a changing tool catalogue.
• Whether a person approves it before execution begins, and at what granularity that approval is meaningful.
• The repair policy when a step fails: patch that step, re-derive the remainder from the current state, or abandon and report.
• What fraction of the overall budget planning itself may consume, given that it is model calls with no visible output.

Failure modes

• Steps reference tools that do not exist or arguments the tool will reject; the mismatch surfaces at step seven, after six steps of real spend and real side effects.
• The strategy assumes a static world. By the fourth step its premises are stale and the executor follows them anyway because nothing re-checked them.
• Revising after every observation means the strategy is different each turn, progress never accumulates, and the agent alternates between two approaches indefinitely.
• A person approves something abstract — gather the data, then send the report — and the concrete execution does something they would have refused.
• Depth is unbounded: a step expands into its own strategy, which expands again, and the recursion is limited only by the budget running out.
• Steps carry no success criterion, so nothing except the model's own assertion can judge whether a step worked.
• The strategy optimises for looking well structured rather than being executable: rich in phases and milestones, empty of checkable postconditions.
• The plan is discarded once execution starts, so the record of what was intended no longer exists when someone asks why the outcome differs.

Related capabilities

• Task Decomposition — sizes the units a strategy sequences
• Execution Loop — consumes the plan object one step at a time
• Multi-agent Orchestration — may generate the topology from a plan
• Autonomy Levels — decides whether the plan or each action needs approval
• Loop Detection — catches revision cycles that never converge

Applies: Production readiness · Design questions