Planning Engine — Patterns

Validate the strategy before executing any of it

Problem. An unexecutable strategy is usually discovered partway through, after earlier steps have already spent money and changed things. The cost of the mistake scales with how long it took to find.

Approach. Require the strategy to conform to a schema, then statically check it before the first step: every named tool exists, every argument type-checks against that tool's declared schema, every dependency refers to a step that precedes it, and the graph has no cycles. Reject and regenerate, with the validation errors fed back as the correction signal.

Trade-off. Static checking only reaches what is declarable; it cannot know whether the identifier in step three will still exist by the time step three runs. It also pushes toward concrete tool binding at planning time, which makes strategies brittle to catalogue changes.

Record assumptions, revise on contradiction

Problem. Revising after every observation destroys continuity and wastes model calls; never revising marches a stale strategy into a changed world. Choosing between them as a global setting gets one of the two failures.

Approach. Have the planner emit, alongside each step, the assumptions that step depends on in checkable form. After each observation, test the assumptions of the remaining steps cheaply and deterministically. Revise only when one is contradicted, and revise only the affected suffix where that is possible.

Trade-off. The quality of the mechanism rests entirely on the planner stating assumptions honestly and completely, which it will not always do. Unstated assumptions still fail silently, so this narrows the failure window rather than closing it.

Approve the strategy, constrain the execution

Problem. Approving individual actions produces fatigue and tells the approver nothing about where the sequence is heading. Approving a summary of intent authorises something far broader than it appears to.

Approach. Present the materialised strategy for approval with its concrete steps, arguments, and expected effects, and treat approval as authorising exactly that strategy. Any revision that adds a step with an effect outside the approved set returns for re-approval; revisions within the approved envelope proceed.

Trade-off. Requires effects to be classifiable well enough to decide whether a revision stays inside the envelope, and the classification will sometimes be wrong in the permissive direction. Approval latency also becomes part of the critical path.

Keep the intended strategy next to the actual one

Problem. Once execution begins, the strategy is typically discarded. When the outcome is disputed, there is no record of what was supposed to happen, only a transcript of what did.

Approach. Persist each strategy revision with its reason, and record the executed trace against it so intended and actual steps can be diffed. Make the divergence — steps skipped, added, reordered, or failed — a reviewable artefact and an aggregate metric.

Trade-off. Storage and plumbing for data nobody reads on a good day. The divergence metric is also noisy at first and needs a period of interpretation before it means anything, which teams under delivery pressure tend to skip.