The control plane decides what work may happen. The work plane does that work.

This separation is common in infrastructure, but it becomes more important when
the workers are agents. An agent can interpret instructions and choose tools,
so a vague boundary can turn a task assignment into unintended authority.

The two planes do not have to be separate products. They do need separate
responsibilities, data contracts, and permissions.

## What belongs in the control plane

The control plane holds operational intent and the rules around it. Typical
control-plane concerns include:

- goals and task definitions;
- ownership and assignment;
- budgets, deadlines, and retry limits;
- permissions and approval requirements;
- policy for starting, stopping, or escalating work;
- the status the rest of the organization can rely on;
- references to evidence and the authority that issued a verdict.

The control plane should answer: What are we trying to do? Why are we doing it?
Who may act? What limits apply? What counts as done? What happens when the work
cannot continue safely?

## What belongs in the work plane

The work plane performs the bounded action. It might run a command, edit a
repository, call an API, query a system, or prepare an artifact. It needs enough
context to do the task, but it should not inherit every permission held by the
control plane.

The work plane should report facts such as:

- which assignment and attempt it handled;
- which inputs and revision it used;
- which actions it took;
- which outputs or artifacts it produced;
- how much time or budget it consumed;
- whether it completed, stopped, or lost its execution path.

Those reports are observations. The worker should not be able to turn its own
claim of completion into an authoritative status change when a separate check
is required.

## A concrete example

Imagine a team asks an agent to update a customer portal.

The control plane records the task, links it to the customer goal, sets a budget,
names the repository, and requires a protected test before completion. It issues
a bounded assignment to an eligible worker.

The work plane checks out the assigned revision, edits the code, runs available
feedback checks, and returns a patch plus logs and test output. It does not grant
itself more time, change the protected completion rule, or mark the task done
solely because its own test command printed green.

Back in the control plane, the recorded policy decides what comes next. A
protected verifier may accept the result. A failed check may return the task for
another attempt. Missing evidence may stop the workflow and ask for review.

This model also handles a crash cleanly. The control plane can see that the task
is assigned but no valid execution path remains. It can surface the problem or
apply a declared recovery rule. It does not pretend that "in progress" means
work is still happening.

## The handoff contract

A useful handoff has four parts:

| Direction | Data | Purpose |
|---|---|---|
| Control to work | assignment, target, scope, budget, input revision | Define the bounded attempt |
| Work to control | events, artifacts, usage, terminal state | Report what happened |
| Evaluator to control | verdict, evidence references, policy version | Decide whether the result may advance |
| Control to work | retry, revise, stop, or new assignment | Start the next explicit attempt |

Each message should carry stable identifiers. At minimum, record the task,
attempt, actor, input revision, and policy version. Without them, a late result
can be attached to the wrong attempt or judged under rules that changed halfway
through the run.

## Do not confuse this with proposal and verdict

Control plane versus work plane answers one question: where do coordination and
authority live relative to execution?

Proposal plane versus verdict plane answers another: can the thing proposing a
change also control the rules that judge it?

The boundaries often reinforce each other, but they are not synonyms. A work
plane may contain a proposer and the tools it uses. A protected evaluator may
run as a separate service while still feeding an authoritative verdict into the
control plane. The important properties are permission separation and a clear
record of which authority made the decision.

## Common boundary mistakes

1. **The worker owns the definition of done.** Completion becomes a self-report,
   so status drifts away from reality.
2. **The control plane runs every tool with broad credentials.** A scheduling
   concern becomes an execution breach with a large blast radius.
3. **Raw logs become the only source of truth.** Operators must reconstruct
   intent and status from transcripts instead of durable work objects.
4. **Assignments have no lease or attempt identity.** Two workers can act on the
   same task, or a stale worker can overwrite a newer result.
5. **Failure has no state.** A crashed worker leaves work marked as active even
   though nothing can move it forward.

The cure is usually a smaller contract, not a smarter worker.

## Where people remain in control

People set goals, define policies, approve exceptions, and decide how much
authority a class of work receives. The control plane makes those decisions
durable and enforceable. It should not hide them inside a prompt.

The work plane can remain replaceable. A shell process, a hosted agent, or a
future runtime can all accept the same bounded assignment if the contract is
clear. That keeps changes in model or tooling from rewriting the organization's
governance model.

## Related reading

- [The two-plane loop](/reference/two-plane-loop)
- [What makes software autonomic](/guides/concept/what-makes-software-autonomic)
- [Evidence before confidence](/guides/concept/evidence-before-confidence)
- [Your agent should not be its own reviewer](/notes/control-loop/your-agent-should-not-be-its-own-reviewer)