Planning & Execution

The naive way to hand work to an agent is to describe the task and let it run. It is also the way that fails most expensively. A single-shot agent gathers whatever context it happens to find, commits to an approach no one saw, and produces a change that is only reviewable once it already exists. By that point a wrong turn has cost a full implementation run. This chapter is the correction: useful autonomous work needs explicit context gathering, a tangible plan, and a review that happens earlier than a one-shot workflow allows.

Planning sits between intake and implementation. It consumes the structured context assembled during ticket enrichment and becomes operational inside end-to-end orchestration, where coding sessions and human review close the loop. Within the larger software development model, this is the bridge from collaborative scoping to auditable execution.

The plan is the cheap checkpoint

The most valuable thing about an explicit plan is when you can review it. A plan is a checkpoint before compute is spent; a pull request is a checkpoint after. Catching a wrong approach at the plan stage costs a few minutes of reading. Catching the same mistake at the pull-request stage costs the entire implementation run that produced it, plus the rework to undo it.

That single timing difference gives the pipeline two human-in-the-loop gates bracketing an autonomous middle:

Plan approval. An amendable plan artifact that a human (or a reviewing agent) inspects and can edit before any implementation begins. Every async coding system that works in practice, from Jules to Copilot to Factory, emits a plan-first artifact for exactly this reason.
Pull-request review. The output gate, where the finished change is reviewed before it merges.

Between the two gates the agent runs on its own. The gates are where human judgement concentrates, a division of labour developed further in Execution and Feedback.

The plan is a first-class artifact

A plan is durable and separate from the issue that prompted it. The issue holds the problem statement, the business intent, and the acceptance criteria: the record of what was wanted. The plan holds the concrete implementation approach: the record of how it will be done. Keeping them apart stops implementation detail from leaking into and polluting the durable statement of intent, a separation argued in Collaborative Development Structure.

A good plan artifact declares four things:

The context it needs. Organisation version, project package, repository target, and task prerequisites, so the orchestrator can resolve the right context layers at dispatch.
The intended change, broken into steps small enough that each is a short, verifiable session. Long-horizon work is many short sessions, not one long one; the reasoning is in Runtime Context Management.
The validation strategy. The tests that define success, written as requirements that fail until the work is done.
The risk and blast radius. Which surfaces the change touches, which feeds the controls autonomy gate and smart routing.

Validation is test-first, and adversarial

The plan must produce test-driven validation that defines the intended outcome before implementation starts. The order is load-bearing. Tests written afterward by the agent that wrote the code confirm that code and guard against regressions, but they do not establish correctness. They encode the implementation’s own assumptions, including its mistakes.

So validation belongs to someone else. It should be written by a separate agent that had no hand in the implementation, so it carries no shared bias. That validator should be adversarial by design (prompted to break the change, not to bless it) and ideally a different model from the implementer, so the two do not share the same blind spots. The discipline is developed in Verification & the Outer Loop, and the model choices in Model Usage.

Defining success as a set of failing requirements up front also closes off the field’s most common silent failure: an agent declaring the work done before it is.

Planning is a different mode from doing

Planning is not implementation done early; it is a different cognitive mode. It rewards slow, careful reasoning (strategic questioning, constraint analysis, deliberately surfacing uncertainty) where implementation rewards fast, fluent generation. The two warrant different models and different postures, a distinction drawn out in Model Usage. A strong plan exposes scope risk and ambiguity while they are still cheap to resolve. A weak plan defers those costs into the implementation run, where they surface as wasted work.

From here the pipeline moves in both directions: upstream to Ticket Enrichment, which prepares a task worth planning, and downstream to End-to-End Orchestration, which executes the approved plan and returns to it when reality pushes back.