The DOCOD Method

Engineering with agents needs a cycle, not a sequence of prompts.

Agents can carry out more and more of the work. The method organises what still has to be decided, coordinated, confirmed and learned by whoever answers for the system.

Define · Orchestrate · Confirm · Observe · [re]Define

How to read the cycle

The method is not a pipeline.

The five movements have a logical order, but real software does not travel in a straight line.

Something found in Confirm can send you back to Define.
Something seen in production during Observe can change the requirements.
An architecture decision can surface mid-execution and demand an impact analysis before the work continues.

The cycle exists to preserve continuity while the system changes.

The manual

Each movement solves a different engineering problem.

Define

Decide what needs to be true.

Define turns intent into something that can be built without relying on implicit context.

Here you clarify the problem, requirements, constraints, decisions, architecture, risks, contracts and the decomposition the work needs in order to start.

You are in Define when you have to answer:

What are we trying to change?
For whom?
Which behaviours need to exist?
Which constraints cannot be violated?
Which decisions have to be made before implementation?
What will count as success?

Inputs: Intent, the problem, existing context, constraints and available knowledge.
Outputs: Requirements, decisions, design, contracts, risks and work defined well enough to execute.

Define is over when

the next piece of work can be executed without anyone guessing intent or rebuilding essential decisions.

Do not mistake Define for

writing documentation for its own sake. The goal is not to produce files. It is to remove the ambiguity that matters before it turns into code.

Orchestrate

Organise who executes, with what context, and within which limits.

Orchestrate turns defined work into coordinated execution.

This is where agents, people, tools, context, environments, rules, dependencies and the sequence of work come in.

You are in Orchestrate when you have to answer:

Who should execute this part?
What context does that execution need to receive?
Which rules and limits apply?
Can the work happen in parallel?
Which dependencies have to be respected?
Where does a person need to step in?

Inputs: Defined work, decisions, context and constraints.
Outputs: Coordinated execution with clear responsibilities, context and boundaries.

Orchestrate is over when

the right work is being executed by the right participant, with the context and constraints it needs.

Do not mistake Orchestrate for

“having several agents work at once”. More agents without coordination only produce more divergence, faster.

Confirm

Do not accept a conclusion. Demand reasons to accept it.

Confirm establishes whether what was produced actually satisfies what had been decided.

Tests, review, acceptance criteria, evidence and human gates belong here.

You are in Confirm when you have to answer:

Does the expected behaviour actually exist?
What evidence supports that conclusion?
Were the agreed criteria met?
Is whoever produced it also the one signing it off?
Is there a decision that still requires human approval?
Are we verifying the result, or only the activity?

Inputs: The result of execution, the criteria, the contracts and the relevant decisions.
Outputs: Evidence, checks, reviews, and approvals or rejections with reasons.

Confirm is over when

there is enough evidence to accept the result, or enough information to know why it has to go back.

Do not mistake Confirm for

the agent declaring it is finished. “Done” is a claim. Confirmation requires evidence.

Observe

Production answers questions planning cannot.

Observe follows the system as it meets reality: users, traffic, failures, cost, unexpected behaviour and the consequences of the decisions that were made.

You are in Observe when you have to answer:

Is the system behaving the way we expected?
Which failures only show up in operation?
What costs or bottlenecks appeared?
Which assumptions were wrong?
Is there drift between intent and behaviour?
What did we learn that we did not know before?

Inputs: The system in use, and the signals its operation produces.
Outputs: Operational evidence, incidents, metrics, deviations and new learning.

Observe does not end the same way

it keeps feeding the next movement whenever reality demands a change.

Do not mistake Observe for

having dashboards. Observability without decisions produces information, not learning.

[re]Define

Learning only matters when it can change a decision.

[re]Define closes the cycle by carrying what was learned back into the state of the project.

A change does not start by erasing the past. It starts by understanding the impact on what had already been decided, built and confirmed.

You are in [re]Define when you have to answer:

What did we learn?
Which earlier decision does that challenge?
What has to change?
What depends on that change?
Which earlier confirmations stop being sufficient?
What is the new desired state?

Inputs: Evidence from Confirm, signals from Observe, new needs or external changes.
Outputs: Revised decisions, impact understood, and a new state of Define.

[re]Define is over when

the change stops being a discovery and starts existing as an explicit new decision.

Do not mistake [re]Define for

editing a spec and moving on. Upstream changes have downstream consequences.

Outside the box

Some decisions do not belong to a single movement.

Architecture decisions, comparisons between alternatives, proposals opened for comment, project rules, impact analysis and technical advice can surface at different moments.

They are cross-cutting because they record reasoning that has to outlive the movement it was born in.

ADRs, RFCs, trade-offs, impact analysis, rules and counsel cut across the cycle.

They surface when the problem demands them, not because a step came up in the queue.

Teaching otherwise would teach a wrong version of the method, one where everything has to fit in a box.

Where one ends and the other begins

The method is not the runtime.

DOCOD Method: Describes the engineering work: how to decide, coordinate, confirm, observe and learn when agents take part in building.
DOCOD Runtime: Is a reference implementation that makes parts of that model executable and verifiable inside a project.