> ## Content Index > Fetch the complete content index at: https://www.decisioncrafters.com/llms.txt > Use this file to discover other available public pages before exploring further. # The Control Plane for Human–AI Production Decisions - URL: https://www.decisioncrafters.com/control-plane-human-ai-production-decisions/ - Published: 2026-10-16T13:10:56.000Z - Updated: 2026-10-16T13:10:56.000Z - Author: Tosin Akinosho A practical architecture pattern for separating what an agent can do from what it is allowed to do AI systems do not become production systems when they can call more tools. They become production systems when the organization can answer five questions after every material action: What state was authoritative? Which capability was invoked? Who or what authorized the action? What evidence shows what happened? How can the action be stopped or reversed? That is the role of a control plane for human–AI production decisions. It is not one product, dashboard, or model. It is the operating layer that keeps state, capability, authority, execution, and evidence from collapsing into the same opaque agent loop. # The production problem is not autonomy. It is collapsed responsibility. A demonstration can succeed with a prompt, a model, a few tools, and a human watching the screen. Production is different. The system may run longer, cross more data boundaries, act through delegated accounts, and encounter states its designers did not anticipate. If the same component proposes an action, decides it is permitted, executes it, and declares success, the architecture has no independent basis for trust. The failure is organizational as much as technical. The business cannot reconstruct which rule applied, whether the input was current, whether a person approved the relevant decision rather than a vaguely related plan, or whether a retry created a duplicate external action. A useful control plane therefore does one thing above all: it separates decision responsibilities so each can be inspected, constrained, and evidenced. # Five separations the control plane must preserve ![](https://www.decisioncrafters.com/content/images/2026/10/data-src-image-fa8c8602-b105-4bdc-9a88-635ab0a2fc24.png) Figure 1\. A governed human–AI control plane separates canonical state, agent capability, human authority, reversible execution, and evidence receipt. ## 1\. Canonical state is not agent memory The agent’s context window, scratchpad, or conversation history may help it reason, but none should silently become the system of record. The control plane resolves the current task, owner, lifecycle state, dependencies, accepted artifact, and stop conditions from the authoritative source before action. Cached context can assist; it cannot overrule fresh canonical state. This prevents a common production error: an agent acts correctly on yesterday’s truth. A published article is redrafted, a closed ticket is reopened, or a prior approval is reused after the underlying revision changed. ## 2\. Capability is not authority A tool connection answers “Can this runtime call the system?” It does not answer “May it take this action for this organization, on this record, at this time?” The control plane binds capability to an identity coordinate, an authority source, a permitted action set, and explicit prohibitions. This distinction matters even when the protocol layer is working as designed. The Model Context Protocol documents a host–client–server architecture for exposing tools and context; business authority still has to be supplied by the application and its governance model. A reachable tool is only a capability surface. For a deeper treatment of this boundary, see “[MCP Gives Agents Tools. Who Gives Them Authority?](https://www.decisioncrafters.com/mcp-gives-agents-tools-who-gives-them-authority/)” ## 3\. Policy is not a paragraph in a prompt Prompts can state intent, but consequential limits need independent enforcement. Policy should be evaluated against typed facts: action class, target, data sensitivity, spend or commitment, current approval, revision, and retry state. The result should be allow, deny, or require review—with a reason that survives the run. Recent qualified market evidence points in the same direction. NVIDIA’s September 28, 2026 Open Agent Safety Platform announcement describes enforcement outside the model and agent harness, including action tracing, runtime policy, and an out-of-band watchdog. That is vendor-reported implementation evidence, not independent proof of production outcomes, but it is a concrete example of the control boundary moving below the agent loop. ## 4\. Human review is a decision gate, not an audience “Human in the loop” is too vague for production design. The architecture should name the exact decision a person owns: approve a public release, accept a financial exception, authorize access to a restricted dataset, or choose among irreversible alternatives. Review should be bound to the exact artifact revision and expire when the artifact or circumstances materially change. A person copied on a thread is not an approval. A prior approval for one article is not standing authority for the next. A request for review is not evidence that review occurred. ## 5\. Execution evidence is not a success message A provider acknowledgment shows that a request was accepted; it may not prove the intended external state. The control plane correlates each consequential action with a unique run identifier and idempotency key, then reads the destination back. The receipt should record the target, effective revision, result, timestamp, and any executor-owned identifier without asking the preparing agent to invent those fields. When an external write outcome is uncertain, the safe state is “unknown pending readback” (often recorded as POST\_WRITE\_UNKNOWN): inspect the destination before retrying. Blind replay is how duplicate posts, duplicate payments, and conflicting records appear. # A minimal decision record The smallest useful control-plane record is not a transcript. It is a compact decision object with enough structure to reconstruct and govern the action: - Decision key and current canonical source - Actor, runtime, and identity coordinate - Requested action and target - Authority source, ceiling, and prohibited actions - Artifact or input revision - Policy result and reason - Human gate, when required - Idempotency key and retry rule - Execution receipt and independent readback - Stop, revoke, and recovery path A small-team example makes this boundary concrete. Imagine a 20-person services company using an AI assistant to draft customer follow-up messages from approved project notes. The assistant may read designated notes and prepare a draft, but a designated employee owns the decision to send it. The workflow records which notes and revision produced the draft, which customer channel would receive it, and the exact draft approved. If delivery times out, it checks the sent-message record before trying again; it does not send a second copy because a status message said 'failed'. The company can revoke the assistant's drafting permission without losing its client records. That is a control plane in practice: the tool connection creates capability, while explicit ownership, permission, approval, and readback govern the business consequence. This record can live across existing systems. Notion, a ticketing platform, or another governed registry may own canonical task state. A source-controlled repository or document may own the artifact. A provider owns execution identifiers. The control plane does not require one database to own everything; it requires explicit ownership and reliable links between records. # What the control plane should refuse A production control plane is defined as much by refusal as by throughput. It should stop when the current authority source is missing, the artifact revision is ambiguous, the target belongs to the wrong brand or client, a protected field would be changed without authority, or a prior external write cannot be read back. It should also make “no action” a successful result. NIST’s AI Risk Management Framework is intentionally a risk-management framework rather than an automation mandate; it asks organizations to incorporate trustworthiness into design, development, use, and evaluation. In practice, that means some decisions should remain human, some workflows should stay non-agentic, and some proposed actions should be rejected because the evidence is weak. # Design review questions - Which source is authoritative for the decision right now? - Which runtime identity is acting, and on whose behalf? - What can the runtime technically do, and what is it actually authorized to do? - Which action changes money, access, public state, customer data, or external commitments? - What exact revision did a human approve? - What prevents a duplicate if the first result is uncertain? - Which receipt proves the destination state rather than request submission? - How is authority revoked, and how is the action reversed or contained? If a team cannot answer those questions, adding another agent, memory layer, or orchestrator will not solve the production problem. It will only make responsibility harder to locate. # The architecture decision The control plane is the boundary between useful autonomy and unowned consequences. It lets agents propose and prepare broadly while reserving consequential execution for verified authority. It lets humans approve named decisions instead of supervising every keystroke. And it gives operators evidence that can survive outside the model’s narration of events. The design goal is not maximum autonomy. It is the smallest governed operating structure that can make the decision safely, show its work, and recover when reality differs from the plan. If you are designing the authority boundary for an agentic system, subscribe to Decision Crafters for evidence-grounded architecture reviews and practical decision frameworks.