How it works
A control plane sits around the path that performs the work. The agent may propose an action, but the control plane decides whether that action is permitted under the current run state. It should make this decision from explicit policy and authoritative state, not from the model's own description of what it intends to do.
A typical control sequence is:
- Identify the actor, run, task, and delegated authority.
- Resolve the applicable policy, permission scope, and execution limits.
- Inspect the proposed tool call and its expected effects.
- Allow, deny, constrain, or route the action through an approval checkpoint.
- Record the decision and resulting state transition.
- Expose interrupt, cancellation, retry, rollback, or recovery controls.
The control plane may enforce budgets, tool allowlists, credential scopes, approval policies, stop conditions, concurrency limits, and state-transition rules. It also provides the operator with a legible account of what the harness allowed and why.
This logic must remain outside the agent's discretionary reasoning. A prompt that asks the model to stay within budget is guidance. A counter that rejects the next call after the budget is exhausted is control.
Why it matters in an agent harness
An agent can generate useful plans while remaining a poor authority over its own execution. It may misunderstand a tool, repeat a failed action, follow injected instructions, or continue after the operating assumptions have changed. The control plane contains those failures by placing deterministic checks between a model decision and an external effect.
That separation improves several engineering properties at once. Permission checks reduce the blast radius of a mistaken tool call. Execution limits prevent an unproductive loop from consuming unbounded time or resources. Approval policies reserve sensitive transitions for an operator. Interrupts and checkpoints make long-running work recoverable without pretending that every operation can be cleanly reversed.
A control plane also makes autonomy adjustable. Increasing autonomy should mean changing an explicit policy for a defined class of actions, not making a prompt more permissive. The same task might run unattended when it reads a repository, require approval before changing files, and be prohibited from publishing. Those boundaries should survive prompt changes and model replacements.
Observability is necessary but insufficient. A trace can show that an agent invoked a destructive tool. A control plane determines whether the invocation was allowed in the first place. The trace then supplies evidence that the policy executed as expected.
The hardest boundary is the unknown outcome. If a tool call times out after submission, the control plane must not assume failure and retry blindly. It needs an idempotency key, a reconciliation step, or a recovery contract that distinguishes safe retry from possible duplicate effect.
Control plane vs control surface
The terms are related, but they answer different design questions.
| Concept | Primary role | Engineering question |
|---|---|---|
| Control plane | Applies policy and governs execution | What is allowed now, under which authority and limits? |
| Control surface | Exposes ways to inspect or change control state | What can an operator view, interrupt, approve, or reconfigure? |
A dashboard with pause buttons is a control surface. The policy engine and state transitions that make pausing authoritative belong to the control plane. A polished surface over advisory commands is not sufficient: the executor must recognize and enforce the resulting state.
The distinction affects testing. Test a control surface for clarity, access, and operator error. Test a control plane for enforcement, race conditions, stale state, bypass paths, and fail-closed behavior at consequential boundaries.
The Rifty take
We treat control as executable policy around model behavior, not a behavioral request made to the model. We optimize for narrow authority, visible decisions, and recoverable execution, accepting extra state and coordination work where external effects justify it. If a boundary matters, the harness must enforce it even when the agent is confused.
Common failure modes
- Encoding critical limits only in the system prompt, where compliance remains probabilistic.
- Giving the agent credentials broader than the authority delegated for the current task.
- Logging actions without recording the policy decision, policy version, and run state that authorized them.
- Offering an interrupt that updates a user interface but does not stop queued or in-flight execution.
- Checking permissions when a run starts but not when each consequential action is attempted.
- Treating timeout as failure and retrying an operation whose external outcome is unknown.
- Letting alternate tool paths bypass the approval or validation applied to the primary path.
- Failing open when policy state, identity, credentials, or the approval service cannot be resolved.
- Combining policy evaluation and execution so tightly that denied actions can still produce partial effects.
- Changing control policy without versioning it, leaving operators unable to explain past decisions.
Frequently asked questions
Is a system prompt part of the control plane?
A system prompt can express operating guidance, but it is not an enforcement boundary by itself. Control-plane rules should be checked outside model reasoning and should reject, constrain, or route disallowed actions even when the model ignores, misreads, or is induced to override the prompt.
What state should a control plane maintain?
A control plane should maintain the authoritative state needed to govern execution: run identity, delegated authority, permission scope, policy version, budgets, approvals, checkpoints, interrupts, and terminal status. It should avoid duplicating business state unless that state is required to make or explain a control decision.
Does every agent action need human approval?
No. Human approval should be reserved for actions whose risk, ambiguity, or irreversibility exceeds the authority already delegated to the harness. Low-risk actions can proceed under deterministic policy, while sensitive transitions such as publishing, spending, deleting, or widening permissions can require an explicit checkpoint.
How should a control plane handle provider or policy-service outages?
It should fail closed at consequential boundaries and surface an operational block. Replacing missing identity, policy, quota, or permission data with a plausible default silently changes the agent's authority. Read-only or otherwise harmless work may continue only when an explicit, recorded policy permits that degraded mode.
How do you test an agent control plane?
Test enforcement with adversarial action proposals, stale state, concurrent interrupts, expired approvals, missing credentials, exhausted budgets, alternate tool paths, and unknown outcomes. Verify both the decision and the absence of forbidden effects. Then confirm that the audit record explains which policy and state produced each result.