Control Planes Govern Agents. Context Graphs Govern Decisions.

The control plane is becoming the default enterprise answer to agent risk.

That is a necessary development. It is not a sufficient one.

Enterprises need a way to inventory agents, assign owners, manage credentials, observe behavior, apply fleet policy, rotate access, and shut down unsafe deployments. Without that layer, the agent estate becomes invisible infrastructure with production permissions.

But a control plane governs the agent estate.

It does not govern each decision before it becomes a production side effect.

That distinction is where the next category of agent infrastructure will be decided.

The control plane answers a fleet question

An agent control plane is built for estate management. It answers questions like:

• Which agents exist?
• Who owns them?
• Which tools can they reach?
• Which identities do they use?
• Which policies apply to their runtime?
• What did they do yesterday?
• Which agent needs to be paused, patched, or retired?

This is valuable infrastructure. Agent deployments are spreading across engineering, sales, support, finance, security, and operations. Each team can now build small autonomous systems faster than central governance can review them. A control plane gives the enterprise a map of that sprawl.

But the map is not the decision boundary.

The control plane can know that a renewal agent exists, runs in the correct environment, uses an approved connector, and emits telemetry. It can know that the agent is allowed to call Salesforce, Jira, Stripe, Snowflake, or an MCP server. It can enforce broad runtime policy.

It still does not answer the decisive question:

Should this specific action be allowed in this specific business context right now?

That is not a fleet question. It is a decision question.

Decisions fail below the fleet layer

Most production agent failures are not caused by unknown agents. They are caused by known agents taking contextually wrong actions.

A support agent approves a refund with a valid credential, inside an approved workflow, against an allowed payments tool. The failure is that the customer is outside the entitlement window and the exception policy applies only to enterprise accounts.

A revenue agent updates a CRM field from an approved runtime. The failure is that the contract status was superseded by a legal amendment that never reached the prompt.

A procurement agent selects a vendor from an authorized database. The failure is that the regional sourcing rule changed last week and the agent used stale applicability logic.

A security agent files an automated escalation. The failure is that the incident category requires human review because it touches a regulated customer segment.

In each case, the control plane can be working. The sandbox can be working. The identity layer can be working. The observability pipeline can be working.

The decision can still be wrong.

The missing primitive is not visibility. It is pre-execution enforcement: a deterministic control point that evaluates the proposed action before the external system accepts it.

The context graph glossary separates these terms for a reason. Applicability, scope isolation, policy-as-code, causal decision trace, and accountable agent are not synonyms for monitoring. They describe the layer that decides whether an action is valid before it runs.

A decision context graph answers a different question

A decision context graph is not another dashboard for agents. It is the structured decision substrate an agent must consult before acting.

It combines facts, relationships, rules, exceptions, temporal validity, policy constraints, source authority, and prior decision traces into a queryable graph. The output is not a better explanation after the action. The output is a pass, block, escalate, or reroute decision before execution.

For every proposed action, the graph can ask:

• Which policy version is active?
• Which customer, contract, jurisdiction, product, or workflow scope applies?
• Which facts are current enough for this decision?
• Which source wins if two systems disagree?
• Which exception overrides the default rule?
• Which agent role is allowed to act without review?
• Which causal decision trace must be recorded if the action proceeds?

This is where accountable agents differ from autonomous agents. Autonomy describes capability. Accountability describes structure. An accountable agent does not merely produce a plausible action and leave the audit trail to logs. It acts only after validated context and enforceable policy have produced a decision record.

That is why A Sandbox Is Not a Decision Boundary matters as an architectural distinction. Execution isolation can contain the process. It cannot validate business legitimacy. The decision context graph provides that legitimacy check.

MCP and control planes make the graph more necessary

MCP made agent connectivity cheap. Control planes are making agent management legible. Both are progress.

Neither removes the need for governed decision context.

MCP answers how an agent reaches tools and data. A control plane answers how the organization manages the agents that use those tools and data. The decision context graph answers whether a proposed action is applicable, scoped, current, and policy-compliant before it reaches the tool at all.

That means the layers are complementary:

Layer	Primary question	Failure if missing
MCP and connectors	What can the agent reach?	Integration sprawl, brittle tool access
Agent control plane	Which agents exist and how are they governed?	Invisible agent estate, unmanaged runtime risk
Decision context graph	Is this action valid now?	Wrong action with valid access
Observability	What happened and why did it fail?	Incidents without diagnosis

The category mistake is treating the middle layers as replacements for the decision layer.

This is the same pattern The Context Graph covered in MCP Solved the Pipes. Who Solves the Water Quality?. Transport solved reach. It did not solve validity. Control planes solve management. They do not solve applicability.

As agents become easier to connect and easier to manage, the rate of contextually wrong action can increase. The enterprise can scale the fleet before it can validate the decisions the fleet makes.

That is not a reason to slow down control-plane adoption. It is a reason to attach a decision boundary to it.

Rippletide is one reference implementation of this pattern: a decision context graph used as a pre-execution enforcement layer for accountable agents. The point is not that every enterprise needs the same implementation. The point is that every serious deployment needs the same architectural role.

The control plane should know the agent exists.

The decision context graph should decide whether the agent's proposed action is valid.

The trace should make that decision replayable.

When those responsibilities are separated, the stack becomes auditable without pretending that telemetry is enforcement. Fleet governance remains fleet governance. Decision governance becomes its own substrate.

That separation matters because enterprise risk lives at the moment of action. Not when the agent is registered. Not when the connector is configured. Not when the trace is reviewed. The risk crystallizes when a proposed action crosses into a system of record, a customer communication, a payment flow, a security process, or a regulated workflow.

The control point has to sit there.

Conclusion

The agent control plane is becoming mandatory infrastructure. It gives enterprises the inventory, management, ownership, and runtime governance they need as agents spread across the organization.

But it should not be asked to do a job it was not built to do.

A control plane can govern agents. A decision context graph governs decisions. The former manages the estate. The latter validates the action. The former tells the enterprise what exists. The latter decides what is allowed to happen next.

The production stack needs both.

Without the control plane, the enterprise cannot see or manage its agents. Without the decision context graph, it cannot prove that a known agent made the right decision under the right policy, scope, and evidence at the right time.

That is the boundary that separates agent management from accountable agent infrastructure.

---

The Context Graph is a weekly newsletter for AI engineers building production agents. Read the glossary of agent decision infrastructure for canonical definitions of decision context graph, pre-execution enforcement, accountable agent, causal decision trace, MCP, and policy-as-code.