A production agent can have excellent models, good tools, durable workflows and strong verifiers and still be architecturally confused.

The confusion usually appears in one question:

Who is actually in control?

If the answer is effectively:

whatever the model decides next

you do not have a controlled autonomous system.

You have a probabilistic component that has gradually accumulated operating-system responsibilities.

That is the wrong boundary.

The central rule of this chapter is:

The model should not control the system that controls the model.

A stronger formulation is:

Reasoning may be probabilistic. Control must remain explicit, inspectable and enforceable.

This chapter turns the architecture we have built throughout this series into an explicit agent control plane.

The Search Problem: “How Should I Architect a Production AI Agent Control Plane?”

Many agent architectures begin with an execution loop:

while not done:
    thought = model(state)
    action = choose_tool(thought)
    result = execute(action)
    state = update(state, result)

That can be useful for experimentation.

But once the agent can:

• mutate repositories,
• send messages,
• deploy software,
• spend money,
• create infrastructure,
• coordinate other agents,
• wait for humans,
• resume after hours,
• migrate between workers,
• learn new capabilities,

that loop is no longer a sufficient architecture.

Because each consequential action depends on more than the model’s current reasoning.

It depends on facts such as:

Is the intent still current?
Is this task inside the system's demonstrated competence?
Is the action authorized?
Is this execution placement permitted?
Is the relevant state fresh?
Is the verifier available and strong enough?
Is the workflow owner still current?
Is the error budget healthy enough for this authority level?
Is the release approved for this cohort?
Is the security scope valid?
Is the side effect idempotent?

Those are control questions.

They should not be answered by letting the same model that wants to act simply declare them true.

1. The Architecture Has Split Into Two Planes

By Step 43, the system we have built naturally separates into two broad layers.

                    CONTROL PLANE

    intent            competence          authority
      │                    │                  │
    policy             placement           security
      │                    │                  │
    budgets            reliability         releases
      │                    │                  │
  escalation       capability portfolio    ownership
      │                    │                  │
      └────────────────────┼──────────────────┘
                           │
                           ▼
                    EXECUTION PLANE

        models → retrieval → search → tools
                 ↓                 ↓
              critics           workers
                 ↓                 ↓
              candidates → verifiers → actions

The execution plane performs work.

The control plane determines:

• whether work should happen,
• under which authority,
• using which resources,
• with which limits,
• under which release,
• against which intent,
• with which verification requirements,
• and what happens when assumptions fail.

The distinction is similar to many mature infrastructure systems.

A scheduler is not a container.

A Kubernetes control plane is not a pod.

A database transaction coordinator is not the SQL query itself.

Likewise:

The agent control plane is not the model.

2. Why “The Agent” Is Too Vague

The phrase the agent decided hides too much.

Suppose a production coding system modifies a repository.

What actually happened?

Potentially:

user intent accepted
        ↓
intent version created
        ↓
task classified
        ↓
competence checked
        ↓
authority ceiling selected
        ↓
placement selected
        ↓
workflow admitted
        ↓
model proposes candidate
        ↓
tests/verifier evaluate candidate
        ↓
mutation policy evaluated
        ↓
repository state revalidated
        ↓
current owner/fencing token checked
        ↓
commit authorized
        ↓
mutation executed
        ↓
postcondition verified

Saying the agent committed the patch collapses all of this into one fictional actor.

That makes failures hard to reason about.

A better architecture treats each decision as belonging to a specific subsystem.

3. Control Plane vs Execution Plane

A useful rule is:

execution proposes
control permits
verification establishes outcome

Not:

model proposes
model authorizes
model verifies
model declares success

The second system is circular.

It can still work often.

But when it fails, the same correlated reasoning process may generate the error, approve the error and explain why the error was correct.

That is precisely what the architecture in this series has been designed to avoid.

4. The Control Plane Should Own Intent

Step 37 introduced intent versioning.

Intent belongs in the control plane because it determines what the system is currently allowed to pursue.

A minimal intent object might look like:

@dataclass(frozen=True)
class IntentVersion:
    intent_id: str
    version: int
    status: str
    scope: str
    supersedes: str | None
    created_by: str
    created_at: datetime

An execution worker may receive intent state.

It should not be able to rewrite the authoritative intent registry simply because its model decides that a different objective would be better.

Before consequential mutation:

assert operation.intent_version == intent_registry.current(operation.intent_id)

This one boundary prevents enormous classes of stale-work failures.

5. The Control Plane Should Own Competence

Capability is not competence.

A model may occasionally succeed at a task outside the system’s validated operating envelope.

That does not automatically expand production authority.

Competence evidence might depend on:

task family
risk class
model/runtime version
toolset
verifier bundle
placement
release
workload cohort
sample size
false-success rate
UNKNOWN rate

The control plane answers:

Do we have evidence that this system is good enough
for this class of task at this authority level?

The model can provide features or semantic classification input.

But promotion of competence claims remains external.

This prevents:

model performs novel task once
        ↓
model concludes it is competent
        ↓
model expands its own autonomy

That is not learning.

That is self-authorized scope expansion.

6. The Control Plane Should Own Authority

Authority answers a different question:

Even if the system is competent, is it allowed to perform this action here?

From Step 29, useful authority classes include:

A0  observe
A1  propose
A2  reversible execution
A3  bounded external effect
A4  consequential external effect
A5  privileged / high-blast-radius action

The same competence may support different authority in different contexts.

For example:

competence: database migration analysis = VALIDATED

does not imply:

production database mutation = authorized

Authority should be represented as explicit policy and capabilities.

Not as a sentence inside a prompt.

7. The Control Plane Should Own Security Policy

Step 41 established an important boundary:

Data does not become authority because an LLM interprets it as an instruction.

That principle belongs naturally in the control plane.

Security policy decides whether:

• a credential may be issued,
• a tenant boundary may be crossed,
• data may leave a region,
• a tool may mutate a system,
• generated code may leave quarantine,
• a model may receive a secret,
• a workflow may enter a privileged placement.

The model may request capabilities.

The credential broker decides whether to grant them.

model proposal
      ↓
capability request
      ↓
security + authority policy
      ↓
scoped grant
      ↓
privileged tool

This transforms broad ambient authority into narrow, observable grants.

8. The Control Plane Should Own Placement Eligibility

Step 34 introduced capability-aware placement.

Placement is more than choosing a model.

A valid execution target may depend on:

model/runtime
provider
region
GPU/CPU pool
tool locality
sandbox profile
verifier availability
data residency
authority ceiling
failure domain
capacity

The control plane should first apply hard constraints:

eligible = [
    target
    for target in targets
    if target.supports(task)
    and target.allowed_for(data_class)
    and target.authority_ceiling >= required_authority
    and target.verifier_strength >= required_verifier
    and target.health == "HEALTHY"
]

Only then should optimization consider:

• latency,
• cost,
• utilization,
• warm state,
• model quality,
• marginal value.

This preserves the rule:

Placement is constraint satisfaction before optimization.

9. The Control Plane Should Own Resource Budgets

Models, search, retrieval, critics, tools and humans all consume resources.

Step 16 introduced dynamic compute allocation.

Step 21 introduced admission control and quotas.

The control plane should own the shared resource ledger.

run budget
├─ model tokens
├─ model calls
├─ search expansion
├─ tool calls
├─ GPU time
├─ browser time
├─ external API cost
├─ human-review budget
├─ verification reserve
└─ reconciliation reserve

An execution worker should not be able to reset its budget by restarting.

A child agent should not get a fresh unlimited budget simply because it was delegated work.

A retry should not recreate the original spend allowance.

Resource state is durable control-plane state.

10. Reliability Must Influence Control

Step 27 introduced SLOs and error budgets.

Reliability should not live only in a dashboard.

It should affect runtime authority.

For example:

HEALTHY
  → normal autonomy

WATCH
  → more verification

CONSTRAINED
  → reduced speculation / smaller rollout

FREEZE
  → no new authority expansion
     no risky behavioral release
     human review for consequential work

The important relationship is:

observed reliability
       ↓
control policy
       ↓
execution authority

Not:

observed reliability
       ↓
slide deck next month

11. Behavioral Releases Belong in the Control Plane

Step 24 treated agent behavior as a production interface.

A behavioral release may include:

model
prompts
router
search policy
budget policy
retrieval
memory behavior
tools
verifiers
security policy
placement policy
workflow definition

The control plane should know exactly which release governs a run.

@dataclass(frozen=True)
class BehavioralRelease:
    release_id: str
    model_bundle: str
    prompt_bundle: str
    policy_bundle: str
    verifier_bundle: str
    placement_policy: str
    security_policy: str
    workflow_version: str

Without this, you cannot reliably answer:

What behavior did we actually deploy?

12. Capability Portfolio Decisions Belong Above Execution

Step 32 asked which capabilities are worth owning at all.

That is not an execution-time model decision.

The capability portfolio may decide:

ACQUIRE
ACQUIRE_PREREQUISITE
PROPOSAL_ONLY
KEEP_HUMAN
USE_DETERMINISTIC_SOFTWARE
USE_EXTERNAL_SPECIALIST
DEFER
EXCLUDE
RETIRE

The execution plane consumes this policy.

It does not rewrite it opportunistically.

This preserves the principle:

An agent may discover capability gaps. It should not unilaterally decide which capabilities deserve organizational investment or production authority.

13. Ownership Is Control-Plane State

Distributed workers require explicit ownership.

Step 20 established leases and fencing.

Step 42 extended ownership to multi-agent coordination.

A worker may currently possess work.

That does not mean it owns the right to mutate indefinitely.

A control-plane ownership record might contain:

@dataclass(frozen=True)
class OwnershipRecord:
    work_id: str
    owner_id: str
    epoch: int
    lease_expires_at: datetime

At commit time:

assert presented_epoch == ownership.current_epoch(work_id)

This lets stale workers keep computing harmlessly while preventing stale mutation authority.

14. Commitments Also Belong in the Control Plane

Step 38 separated plans from commitments.

A plan may be discarded.

A commitment may require:

• satisfaction,
• release,
• transfer,
• compensation,
• reconciliation.

Commitments therefore cannot live only in model context.

They need durable lifecycle state.

PROPOSED
ACTIVE
SATISFIED
RELEASE_PENDING
RELEASED
TRANSFER_PENDING
TRANSFERRED
BREACHED
RECONCILIATION_REQUIRED
UNKNOWN

The control plane ensures that replanning does not silently orphan obligations.

15. Durable Workflow State Belongs in the Control Plane

Step 39 established:

Make the workflow durable and treat the model as disposable.

That makes the workflow engine one of the strongest control-plane primitives.

It tracks:

current workflow state
pending waits
retry counters
timers
external events
commitments
cancellation state
reconciliation work
activity outcomes
budgets

The model can be invoked at explicit decision points.

But the model is not the process clock.

16. The Mutation Gateway Is the Hard Boundary

Many control-plane concepts become useful only when they meet at one enforceable point.

That point is the mutation gateway.

Before a consequential action, the platform should validate something like:

current intent?            yes
state fresh?               yes
competence sufficient?     yes
authority valid?           yes
security scope valid?      yes
placement permitted?       yes
ownership current?         yes
budget available?          yes
verifier evidence valid?   yes
release permitted?         yes
operation idempotent?      yes

Only then:

COMMIT

A useful deterministic structure is:

@dataclass(frozen=True)
class CommitRequest:
    operation_id: str
    intent_id: str
    intent_version: int
    candidate_hash: str
    state_versions: dict[str, str]
    authority_grant_id: str
    ownership_epoch: int
    verifier_evidence_id: str
    release_id: str
    placement_id: str


def authorize_commit(req: CommitRequest, control: ControlState) -> str:
    if not control.intent_is_current(req.intent_id, req.intent_version):
        return "STALE_INTENT"
    if not control.state_is_current(req.state_versions):
        return "STALE_STATE"
    if not control.authority_valid(req.authority_grant_id):
        return "AUTHORITY_DENIED"
    if not control.owner_is_current(req.operation_id, req.ownership_epoch):
        return "STALE_OWNER"
    if not control.verifier_evidence_valid(
        req.verifier_evidence_id,
        candidate_hash=req.candidate_hash,
    ):
        return "VERIFICATION_INVALID"
    if not control.release_permitted(req.release_id):
        return "RELEASE_BLOCKED"
    return "ALLOW"

This should stay boring.

Boring is good.

If a deterministic invariant can decide whether a stale operation should execute, do not ask an LLM.

17. Models Can Still Participate in Control Decisions

An explicit control plane does not mean every decision must be a hardcoded rule.

Some control questions are semantic.

Examples:

• Which task family best describes this request?
• Is this new task similar to a validated competence cohort?
• Which two plans represent materially different risk profiles?
• Which observation would most reduce blocking uncertainty?

A model may help answer those questions.

But the output should enter the control plane as evidence or a proposal.

For example:

model classification
      ↓
confidence / evidence
      ↓
policy boundary
      ↓
allowed execution class

Not:

model says "this is safe"
      ↓
privileged action executes

18. Learned Control Policies Need Their Own Competence

Suppose we replace deterministic routing with a learned policy.

That policy itself becomes a production component.

It needs:

• benchmark evidence,
• versioning,
• shadow deployment,
• canary rollout,
• drift monitoring,
• rollback,
• authority limits.

This was established in Step 15.

A learned router should never sit outside the rules that govern other learned components.

The control plane must control learned control policies too.

That sounds recursive.

It is manageable if hard invariants remain outside the learned policy.

hard security / authority / residency constraints
                    ↓
             learned optimizer
                    ↓
          eligible-choice ranking

The optimizer may choose among permitted targets.

It cannot make a prohibited target permitted.

19. Escalation Is a Control-Plane Transition

Human escalation should not be modeled as:

model gets nervous
      ↓
sends Slack message

It should be a structured state transition.

AUTONOMOUS
    ↓
HUMAN_REVIEW_REQUIRED
    ↓
WAITING_FOR_APPROVAL
    ↓
APPROVED / REJECTED / REQUEST_EVIDENCE

The approval binds to:

• intent,
• candidate,
• environment,
• state identity,
• authority scope,
• expiry.

The control plane owns this transition.

The model may explain why escalation is recommended.

It cannot convert explanation into authorization.

20. The Control Plane Must Survive Model Failure

A useful architectural test is:

If the model becomes unavailable, can the platform still preserve safety, ownership and obligations?

The answer should be yes.

The system may lose capability.

But it should still know:

• which workflows exist,
• which commitments are active,
• which operations are ambiguous,
• which intents were cancelled,
• which approvals expired,
• which leases are stale,
• which side effects require reconciliation.

This is one of the clearest signs that the model is not the operating system.

21. The Control Plane Must Survive Worker Failure

Similarly, if a worker dies:

worker process dies
       ↓
lease expires
       ↓
workflow remains durable
       ↓
new worker acquires ownership
       ↓
checkpoint / workflow state restored
       ↓
state + intent revalidated
       ↓
continue safely

No privileged fact should exist only in worker RAM.

That includes:

• authority assumptions,
• retry count,
• commitment ownership,
• budget remaining,
• external side-effect state.

22. The Control Plane Must Survive Intent Changes

Step 37 showed that cancellation must be enforceable even when workers miss the event.

The control plane provides that enforcement.

intent v7 ACTIVE
worker A running

intent v8 SUPERSEDES v7

worker A misses notification
worker A finishes tool proposal
worker A reaches commit gateway

commit gateway:
    presented intent = v7
    current intent   = v8

    → STALE_INTENT

No cooperation from the worker is required.

That is what makes it a real control boundary.

23. The Control Plane Must Survive Security Degradation

Suppose the credential service fails.

The safe behavior may be:

mutation authority unavailable
        ↓
continue read-only analysis
        ↓
prepare candidate
        ↓
defer privileged commit

Likewise, if verification infrastructure is down:

candidate generated
        ↓
verification unavailable
        ↓
UNKNOWN / DEFERRED

Not:

verifier unavailable
        ↓
model seems confident
        ↓
ship anyway

Control-plane degradation should contract authority, not silently weaken standards.

24. The Control Plane Is a State Machine, Not Just a Service

It may be tempting to create one giant AgentControlPlaneService.

That is not necessarily the right abstraction.

The control plane is better understood as a set of explicit state machines and registries.

IntentRegistry
CompetenceRegistry
AuthorityPolicy
CapabilityRegistry
OwnershipRegistry
CommitmentLedger
WorkflowStore
ReleaseRegistry
BudgetLedger
PlacementRegistry
SecurityPolicy
ReliabilityState
VerificationRegistry

Each should have narrow responsibilities.

The architecture should avoid recreating a god object with a more impressive name.

25. Avoid Control-Plane Monoliths

Centralized policy does not require centralized implementation.

A production system may have separate services for:

• identity,
• authorization,
• workflow,
• placement,
• reliability,
• releases,
• verification,
• capability management.

What matters is that the contracts are explicit.

A mutation gateway might combine results from several authoritative systems.

Intent Service ───────┐
Authority Service ────┤
Security Service ─────┤
Ownership Service ────┼─→ Mutation Gateway
Verifier Registry ────┤
Release Service ──────┤
State Version Store ──┘

This is very different from one model prompt containing all the relevant rules.

26. CQRS Fits This Architecture Naturally

A control plane often benefits from separating commands from queries.

Queries answer:

What is the current intent?
Who owns this task?
What authority is active?
Which release is permitted?
What competence evidence exists?
Which commitments remain unresolved?

Commands change authoritative state:

SupersedeIntent
GrantAuthority
AcquireOwnership
CreateCommitment
ReleaseCommitment
PromoteCapability
PublishBehavioralRelease

This separation reduces accidental coupling between reading state and mutating policy.

It also makes audit and replay easier.

27. Event-Driven Control Is Useful—But Events Are Not Authority

Many control-plane transitions should emit events.

IntentSuperseded
OwnershipTransferred
CommitmentCreated
VerificationCompleted
CapabilityPromoted
ErrorBudgetBurned
ReleaseRolledBack
SecurityGrantRevoked

Workers may react to those events.

But a delayed event should not become timeless authority.

The current authoritative state remains stronger than event delivery.

At commit time:

event said intent v7 was active

is weaker than:

intent registry says v8 is current

This principle has appeared repeatedly throughout the series.

28. The Control Plane Needs Provenance

Every consequential decision should be explainable as a path through control state.

For example:

operation op-187
  ↓
intent v12
  ↓
competence claim comp-44
  ↓
authority grant auth-91
  ↓
placement target local-qwen-gpu-2
  ↓
behavioral release rel-37
  ↓
verifier evidence ver-618
  ↓
ownership epoch 8
  ↓
commit decision ALLOW

That gives replay and incident forensics something concrete to inspect.

Without it, production debugging collapses back into:

“Why did the agent think that was okay?”

That is rarely sufficient.

29. The Control Plane Needs Its Own SLOs

The control plane itself can fail.

Useful SLIs include:

intent-read availability
authorization decision latency
ownership consistency
stale-commit rejection rate
policy evaluation failures
placement-decision latency
verifier-registry freshness
release-resolution correctness
commitment-ledger consistency

A slow or unavailable control plane can become the bottleneck for the entire platform.

But optimizing it must not lead to unsafe caching.

A cached authorization is not automatically valid after:

• intent supersession,
• grant revocation,
• release rollback,
• state drift.

30. Control-Plane Caching Must Preserve Identity

Some control queries are cacheable.

But cache identity matters.

For example:

competence(task_family, release_id, verifier_bundle)

may be reusable.

Whereas:

is authority grant auth-91 valid right now?

may require fresh revocation state.

The rule is:

Cache immutable evidence aggressively. Cache mutable authority conservatively.

31. Control-Plane Policy Should Be Versioned

Policies change.

Therefore:

policy_v41

should be a real artifact.

A decision record should capture the policy version used.

This matters for:

• replay,
• incident investigation,
• behavioral releases,
• regulatory audit,
• regression comparison.

If the answer to:

“Which policy allowed this action?”

is:

“Whatever rules were in the prompt that week”

then the system is not operationally mature.

32. The Control Plane Must Not Trust the Execution Plane Blindly

Workers report results.

Those results are evidence.

They are not automatically authoritative truth.

For example:

worker: "deployment succeeded"

should trigger:

query deployment system
verify version / health / rollout state

Likewise:

model: "tests passed"

is weaker than:

test runner result bound to exact artifact hash

This is the same evidence hierarchy we have built throughout the series.

33. The Execution Plane Should Be Replaceable

A strong control plane makes model substitution easier.

You may switch:

local model
→ frontier model
→ specialist model
→ deterministic implementation

without redesigning:

• authority,
• intent lifecycle,
• security,
• workflow durability,
• transaction semantics,
• replay,
• reliability.

That is an enormous architectural advantage.

The model becomes a replaceable capability provider.

Not the foundation of the whole system.

34. Control Decisions Should Be Observable

A trajectory trace should include events such as:

CONTROL_INTENT_RESOLVED
CONTROL_COMPETENCE_CHECKED
CONTROL_AUTHORITY_GRANTED
CONTROL_PLACEMENT_FILTERED
CONTROL_BUDGET_RESERVED
CONTROL_VERIFIER_REQUIRED
CONTROL_OWNER_VALIDATED
CONTROL_SECURITY_CHECKED
CONTROL_COMMIT_ALLOWED
CONTROL_COMMIT_DENIED
CONTROL_AUTHORITY_CONTRACTED
CONTROL_ESCALATED

This lets us distinguish:

candidate was bad

from:

candidate was acceptable
but authority policy denied it

or:

candidate was valid
but state became stale before commit

Those are completely different failure modes.

35. A Minimal Control-Decision DTO

A useful control decision might look like:

from dataclasses import dataclass


@dataclass(frozen=True)
class ControlDecision:
    decision_id: str
    operation_id: str
    intent_version: int
    policy_version: str
    release_id: str
    placement_id: str
    competence_claim_id: str | None
    authority_grant_id: str | None
    verifier_evidence_id: str | None
    ownership_epoch: int | None
    outcome: str
    reason_codes: tuple[str, ...]

Notice what is missing:

"model_thoughts": "..."

Natural-language rationale may be useful as supporting context.

But the enforceable decision should be structured.

36. The Control Plane Should Prefer Reason Codes

Instead of returning:

DENIED

prefer:

DENIED
├─ STALE_INTENT
├─ VERIFIER_UNAVAILABLE
├─ AUTHORITY_SCOPE_MISMATCH
├─ SECURITY_POLICY_DENY
├─ COMPETENCE_UNVALIDATED
├─ ERROR_BUDGET_FROZEN
└─ NO_FEASIBLE_PLACEMENT

Reason codes improve:

• observability,
• user messaging,
• debugging,
• metrics,
• policy testing,
• replay.

They also reduce the temptation to ask the model to invent a plausible explanation after the fact.

37. Don’t Put Every Decision in the Control Plane

There is an opposite failure mode.

A team may create an enormous centralized governance layer for trivial choices.

That creates latency and complexity.

The right question is:

Could this decision change authority, correctness, resource allocation, reliability or external state?

If not, execution-local autonomy may be appropriate.

For example:

which sentence should the model rewrite first?

probably does not need a control-plane round trip.

But:

may this model push to main?

absolutely does.

38. Hard Invariants vs Soft Optimization

This distinction is essential.

Hard invariants include:

tenant isolation
current intent
current ownership
credential scope
prohibited operations
data residency
required approval
required verifier class

Soft optimization includes:

cheapest eligible model
fastest eligible region
search width
critic frequency
candidate count

The architecture should be:

hard constraints
      ↓
eligible choices
      ↓
soft optimizer

Never:

soft score
      ↓
maybe violate a hard constraint because score was high

39. The Control Plane Is Where Simplicity Can Return

An interesting effect appears once policy is explicit.

Some decisions that looked like they needed an intelligent agent become ordinary software.

Examples:

if state version changed → revalidate
if intent superseded → deny commit
if verifier missing → UNKNOWN
if lease stale → reject mutation
if authority insufficient → escalate
if budget exhausted → stop optional search

This is good.

The point of agent engineering is not to maximize how many decisions are made by a model.

The point is to use models where semantic flexibility adds value and ordinary software where exact rules already exist.

40. The Model Is Not the Operating System

This is the conclusion of the architecture we have built through forty-three steps.

A production agent may use frontier reasoning models.

It may use local specialists.

It may search trees, debate candidates, call tools, retrieve memory and coordinate other agents.

But the surrounding system must still answer:

what is the objective?
what is trusted?
what is allowed?
what is verified?
what is current?
who owns the work?
what can be spent?
what happens on failure?

Those questions form the operating environment in which reasoning occurs.

The model operates inside that environment.

It should not implicitly define it.

The model is a worker inside the system, not the operating system of the system.

41. A Reference Control-Plane Flow

Putting it together:

User / External Event
        ↓
Intent Registry
        ↓
Task + Risk Classification
        ↓
Competence Registry
        ↓
Authority / Security Policy
        ↓
Capability + Placement Eligibility
        ↓
Admission + Budget Allocation
        ↓
Durable Workflow
        ↓
Execution Plane
  ┌───────────────┐
  │ model/search  │
  │ retrieval     │
  │ tools         │
  └───────┬───────┘
          ↓
      Candidate
          ↓
 Independent Verification
          ↓
      Commit Request
          ↓
     Mutation Gateway
  ┌───────────────────────┐
  │ current intent        │
  │ current state         │
  │ competence            │
  │ authority             │
  │ security              │
  │ ownership             │
  │ verifier evidence     │
  │ release               │
  │ budget                │
  └──────────┬────────────┘
             ↓
       External Effect
             ↓
 Postcondition Verification
             ↓
 Provenance + Reliability Data

That is no longer a prompt loop.

It is a production architecture for controlled autonomy.

42. What Should Stay Outside Model Control?

A useful default list is:

current intent version
security policy
credential issuance
hard authority ceilings
prohibited operation classes
tenant boundaries
data-residency rules
verification thresholds
held-out benchmark membership
competence-promotion thresholds
release-promotion policy
error-budget policy
ownership fencing
idempotency identity
reconciliation obligations

The model may recommend changes to some of these.

But recommendation and authority remain separate.

43. What Can the Model Control?

Plenty.

Within explicit boundaries, the model can decide:

• how to decompose a semantic problem,
• which evidence to request,
• which candidate approach to pursue,
• which tool arguments to propose,
• how to summarize evidence,
• whether multiple candidate strategies seem materially different,
• when uncertainty appears high,
• what explanation to provide to a human reviewer.

The control plane is not anti-agent.

It is what allows richer agent behavior without granting uncontrolled authority.

44. Failure Modes

Failure: the model is root

model chooses tools
model grants itself permission
model declares success

There is no independent boundary.

Failure: giant policy prompt

Every control rule is stuffed into a system prompt.

Prompt wording becomes the authorization layer.

Failure: control-plane god service

One service owns every registry, policy and workflow concern.

A new monolith replaces the old agent loop.

Failure: learned optimizer bypasses hard constraints

A route with a good score becomes eligible despite security or authority rules.

Failure: policy says deny, tool still executes

Control decisions are advisory rather than enforced at the mutation boundary.

Failure: stale cached authorization

A grant is revoked but reused from cache.

Failure: observability without enforcement

The system logs policy violations after the side effect already occurred.

Failure: every micro-choice becomes governance

Control-plane overhead swamps useful execution.

45. Failure Injection

Test the control plane by deliberately creating situations where execution would be unsafe without it.

Examples:

supersede intent while worker is generating action
revoke authority after candidate verification
expire ownership lease before commit
roll back behavioral release during workflow
make verifier unavailable
move repository head after approval
revoke credential capability
exhaust error budget
saturate preferred region
kill worker before operation acknowledgement
send malicious tool output requesting more privileges

Then assert:

no stale intent mutation
no stale owner mutation
no privilege expansion
no unverified commit
no release-bypassing execution
no budget reset
no lost commitment
no duplicate side effect

These are stronger tests than asking whether the model said it understood the policy.

46. Benchmark the Control Plane Against Simpler Systems

The control plane itself adds cost.

Benchmark against:

simple agent + typed tools
simple agent + verifier
simple agent + authority gate
full control plane

Measure:

• verified success,
• false success,
• unauthorized effects,
• recovery time,
• latency,
• cost,
• operational complexity.

Some systems will not need the full architecture.

That is fine.

The control plane should be built incrementally from measured failure.

47. A Practical Adoption Sequence

A reasonable progression is:

1. typed tools
2. external verification
3. explicit mutation authority
4. durable intent identity
5. state freshness checks
6. ownership/idempotency
7. workflow durability
8. release/provenance tracking
9. competence + placement policy
10. reliability-driven authority
11. capability portfolio governance

Do not begin by building a giant governance platform for a read-only summarization agent.

Add the control surface when the execution surface creates corresponding risk.

48. The Architecture Has Reached Its Capstone

At this point the earlier posts fit into one model.

Reasoning mechanisms
        ↓
Evidence / verification
        ↓
Distributed execution
        ↓
Behavioral releases
        ↓
Reliability
        ↓
Competence
        ↓
Authority
        ↓
Capability portfolio
        ↓
Placement
        ↓
Durable workflows
        ↓
Security / coordination
        ↓
CONTROL PLANE

This is the point where the series stops needing new mechanisms.

The remaining work is synthesis.

What Comes Next

The next chapter should assemble the entire architecture into one end-to-end production agent.

Not another new subsystem.

Not another optimization trick.

A reference architecture.

The next principle is:

A production agent is not one model loop. It is a controlled execution path from intent to verified external outcome.

That will be Step 44:

Build a Production AI Agent From First Principles: The Complete Reference Architecture.