The Computational Layer of the Agent Control Plane

Why deterministic math is a missing piece of the agent governance stack, and what it means for enterprises granting agents write access.

Writing in CIO magazine in February, Hari Om Garg described the first time he watched an autonomous AI agent execute a multi-step workflow inside an enterprise. He did not feel excited. He felt, in his words, a specific cold dread. The system was reasoning, planning, and taking action without human intervention. It was impressive. It was also, he realized, a probabilistic engine holding the keys to his digital infrastructure.

That reaction is the right one, and it is becoming the defining conversation in enterprise AI. A month after Garg’s piece, Rohan Puranik at Cowboy Ventures published his thesis on agent security and landed in the same place from a different angle. Enterprises have active agent pilots, he wrote, but nearly all of them are stuck in read-only mode. The read-to-write transition is where the order-of-magnitude value lives, and it is also where the controls are least mature. His argument: agents will only earn autonomous write access when there is a deterministic control plane purpose-built to govern them. Identity. Runtime policy enforcement. Intent-aware rollback. Multi-agent trust.

Garg’s framing of the tension is sharper than anything else I have read on this. The clash, he says, is between the probabilistic world of the agent and the deterministic world of the business. Prompting is instructing the brain. Architecture is tying the hands. You cannot prompt your way out of a liability issue.

Both writers are right. And both stop one layer short of where the hardest enterprise decisions actually get made.

The layer nobody is writing about

Most of the control-plane conversation is focused on authority: who the agent is, what it can touch, when its permissions expire, what gets rolled back if things go wrong. That is necessary, but not sufficient. For example, calculation is another layer required to switch from read to write access for agents.

When an agent performs a calculation that drives a decision, the calculation is the action. A price quoted to a customer. A dose recommended to a clinician. A risk score used to approve a loan. A depreciation schedule written into a filing. A tax number sent to a regulator. In these moments, the agent has not done something and then decided something. The number it produced is the decision.

Today, agents handle these calculations in one of three ways, and none of them are governable. First, the model reasons about numbers in tokens, which is unreliable enough that nobody building seriously defends it. Second, the agent generates code and executes it, which is opaque, unversioned, and produces a calculation the business never authored and cannot audit after the fact. Third, the agent calls an external tool, which is better, but the tool is usually a generic calculator and the logic inside it was not written by the enterprise whose risk is on the line.

In each case, the business has lost something it would never tolerate losing in a human workflow: authorship of its own math.

What a computational control plane actually does

The pattern that fixes this looks like every other control-plane pattern in the agent stack, applied one layer deeper. It has three properties.

The business authors the logic. Not the model. Not ad-hoc code generation. The enterprise encodes its own calculations, its own defaults, its own thresholds, in a system where that logic is version-controlled, reviewable, and owned.

Every calculation produces a persistent, addressable artifact. The moment the math happens, there is a receipt. It has an URL. It can be linked from a ticket, embedded in an audit trail, opened by a reviewer, and revisited months later. The artifact is not generated on demand for compliance. It exists by default, for every calculation, because anything less is forensics instead of governance.

The structured output carries signals the surrounding system acts on. In-register values proceed. Out-of-register values route to human review. The escalation is a property of the computation itself, authored in advance, triggered deterministically, and surfaced through the integration layer where the agent actually lives. Anything short of that is chaos.

Together these three properties let an agent graduate from read to write on a computational workflow. Not because the agent got smarter, but because the math it performs is governed, authored, reviewable, and traceable to a specific domain version that a named owner inside the business signed off on.

The agent becomes a router. The business retains authorship.

What this is, and what it is not

This is not a replacement for the work Rohan, Garg and others are describing. Agent identity, runtime enforcement, intent-aware rollback, multi-agent trust: all of that still has to exist. The computational layer sits next to those layers, not in place of them.

It is also not a workflow engine. Several good companies are building deterministic orchestration for agents at the workflow level. They govern the steps an agent takes. The computational layer governs the math inside those steps. They compose. An enterprise serious about autonomous agents will want both.

And it is not a math library bolted onto an LLM. A math library does not have versioned business logic, escalation rules, or a URL-addressable receipt for every calculation. A math library is a tool. A computational control plane is a governance layer.

Where TrueMath sits

TrueMath is the computational control plane for AI agents. We are a developer platform built on a deterministic math kernel (PowerOne, 30-plus years of development, more than 30 million users) delivered through a RESTful API.

The enterprise authors its own domains in TrueMath: its calculations, its defaults, its thresholds, its routing logic. That logic is version-controlled and owned. Every calculation the agent triggers produces a unique, URL-addressable artifact, timestamped today, with natural-language titling, keyword search, and variable-use search on the near roadmap. The structured output of each calculation can carry signals that the agent’s integration layer reads as in-register, out-of-register, or route-to-human-review.

In practice, this lets an agent operate across a defined calculation surface with the same guarantees an enterprise would demand of any internal financial or operational system. The business should write and own the math, not the agent. The artifact holds the audit trail, not the agent. The logic determines escalation, not the agent.

That is the difference between an agent that can read your data and an agent you would trust to act on it.

Why this matters now

The analyst and VC consensus on agent infrastructure is converging fast. Bain is publishing three-layer reference architectures. Futurum is shipping framework papers. Cowboy, Ballistic, and others are writing public theses about where the defensible infrastructure categories will sit. Enterprises are converging too, more quietly but just as quickly. Across every conversation I have with prospective customers, the same moment arrives: someone asks whether the calculation the agent just performed can be trusted, reproduced, and defended. The answer determines whether the agent ever gets write access.

The computational layer is one of the categories that determines that answer. It deserves to be named as part of the stack rather than assumed into existence.

If you are building agent infrastructure, deploying agents into workflows where numbers matter, or investing in the control-plane thesis, we would welcome the conversation.

Bill Kelly is co-founder and CEO of TrueMath. TrueMath is an NVIDIA Inception company and is deploying via AWS Marketplace.

Reach out: bill.kelly@truemath.ai
Learn more: truemath.ai
Sign up for early access: app.truemath.ai/signup