Agent Architecture and Orchestration
Planning Engine — Stack
Planning engine › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
You are choosing how intent is represented, how early a bad strategy can be rejected, and what it costs to produce one.
- Rejectability. Whether a malformed or unexecutable strategy can be detected before any step runs, or only when a step fails.
- Grounding in the real tool set. Whether step arguments are checked against actual tool schemas at planning time rather than assumed.
- Revision trigger. Whether the mechanism supports revising only on surprise, or forces a choice between planning once and planning every turn.
- Cost and latency of planning. How many model calls precede the first useful action, and whether that is acceptable for interactive use.
- Legibility. Whether a non-author can read the strategy and understand what will happen, which is the prerequisite for approving it.
- Partial order support. Whether independent steps can be expressed as independent, or whether everything is forced into a line.
- Reproducibility. Whether the same goal and state produce the same strategy, and therefore whether a change can be evaluated at all.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Single-prompt planning inside the reasoning model | Short goals where separating planning from acting adds more latency than value | The strategy is never materialised, so it cannot be approved, cached, or compared with the outcome |
| Explicit planner-executor split with a validated plan schema | Multi-step goals with real side effects and a need for pre-execution review | Two model-shaped components to evaluate; the executor must handle strategies that were valid but wrong |
| Plan-then-execute with deferred observations (ReWOO-style) | Reducing token spend by avoiding re-sending the whole history each step | Blind to mid-execution surprises by construction; needs a strong revision trigger to be safe |
| Search over candidate strategies (tree or beam search with a scoring function) | High-value goals where a better strategy is worth many model calls | Cost multiplies by the branching factor; the scorer is usually another model and inherits its biases |
| Classical planners driven by a model (PDDL and similar formalisms) | Domains with a stable, formalisable action model and hard correctness requirements | Writing and maintaining the domain model is the real work; most product domains resist formalisation |
| Hierarchical task networks with authored methods | Recurring goal shapes where expert decomposition already exists on paper | Authoring effort up front; novel goals fall outside the authored methods entirely |
| Compiled workflow graphs as the strategy | Goals that recur with little variation and need auditability | Not planning in any adaptive sense; a changed goal means an engineering change |