Three-Phase Workflow
The prepare → execute → validate cycle that every task follows.
Last reviewed
Why three phases?
Agents do better work when they slow down at the right moments. The three-phase workflow keeps them from skipping context, widening scope, or claiming completion without evidence.
Phase 1 — Prepare
Before changing anything, the agent should:
- Read the action item.
- Adopt the right role.
- Check prior work and related knowledge.
- Identify what evidence will prove the work is complete.
- Keep the scope narrow enough to review.
This is the "do the homework" phase. It prevents agents from solving the wrong problem quickly.
For tracked task work, preparation also defines task-specific validation before implementation begins. The checks should prove the requested outcome, not merely repeat a generic build command. Visual work needs a baseline and explicit inspection criteria so later screenshots can show what changed.
Preparation ends with a bounded scope, an owner, an understood dependency path, and a committed validation manifest. If those pieces are missing, execution has no reliable finish line.
Phase 2 — Execute
The agent does the work inside the agreed scope. A good execution pass respects existing patterns, avoids unrelated cleanup, and records anything that could not be finished.
For copy, this means matching the product truth. For code, it means reading before writing. For operations, it means using the current board and runtime state instead of stale notes.
Execution is iterative. Run the smallest relevant check, inspect the actual output, and correct what the evidence shows. A file existing is not visual proof; a package being produced is not installed-runtime proof; a chat response is not a board lifecycle receipt.
When the task uncovers an adjacent problem, keep it visible without silently absorbing it. Fix it only when it is required for the requested outcome and remains inside the task's authority. Otherwise record a focused follow-on item with the dependency or approval boundary.
Phase 3 — Validate
Validation turns "I think it is done" into evidence. Depending on the task, proof may include:
- Build or test output.
- Runtime proof.
- Link checks.
- Screenshots.
- A Knowledge Item.
- A deliverable.
- A clear note about remaining risk.
Only after validation should the item move to review.
Validation must use the final source state. Re-run the task-specific checks after the last edit, inspect the rendered or installed product when relevant, and package the evidence in the task's Knowledge Item and deliverable. Completion timestamps and rubric grading describe the closeout; they do not replace proof.
The completion gate moves validated work to review, not done. Review is where a human or delegated reviewer checks the request-to-evidence chain and decides whether to approve, revise, or reject the work.
Why the phases stay separate
Separating the phases protects the user from impressive but unprovable output. Preparation locks the claim, execution changes the system, and validation tests the result. Combining them makes it easy to weaken a check after seeing a failure or to call an implementation finished before the final surface is inspected.
The separation also helps recovery. A reviewer can see whether the failure came from an unclear request, an incomplete implementation, stale proof, or a lifecycle mismatch.
Recovery
If execution starts before the validation manifest is committed, stop and repair the task lifecycle before continuing. Do not retroactively invent checks that merely describe the implementation.
If final validation fails, keep the item in progress, diagnose the root cause, update the work, and rerun the same acceptance gate. If the failure depends on an external decision or unavailable service, record the blocker and preserve the evidence instead of promoting the item.