# Advanced Agents From First Principles 43: Who Controls the Agent? Build an Explicit Agent Control Plane
# Book: Advanced Agents From First Principles
# Chapter URL: https://programmer.ie/books/advanced-agents-from-first-principles/43-chapter/
# Prose fingerprint (sha256, normalized): 1f8a8135b2ad421b868ce7ee513aad7896f58f69005503f0aa36244cb82f1846
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

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.