Control plane versus work plane

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
• What makes software autonomic
• Evidence before confidence
• Your agent should not be its own reviewer