Every serious ML platform now has an answer for agents: allow-lists on which tools a model may call, sandbox permissions, on-behalf-of tokens, an identity registry so you can finally see your fleet. It is real engineering, and it governs one thing with precision — what an agent is allowed to reach. It says almost nothing about the deed that follows: whether releasing this payment, on this prediction, under these conditions, was actually permitted.
Reach is not the deed
Two questions hide inside "govern the agent," and they are not the same question. The first is about reach: may this agent invoke this tool, with these arguments, holding this token, from inside this sandbox, under this registered identity? The second is about the deed: given the prediction the model just returned, should this specific business action commit at all?
The agentic-era pivot across the MLOps and AI-gateway vendors has largely answered the first question and quietly reframed the second as a forensics problem. Reach is enforced at the boundary in real time; the deed is reconstructed afterward — drift detected, decision paths replayed, lineage assembled into an explanation of what already happened. That is a meaningful capability. It is also, structurally, an account of the past. The action had already committed by the time the reconstruction ran.
What the platforms genuinely solved
Give the category its due, because the reader who buys this evaluates it every day. Feature stores, model registries, and end-to-end lineage genuinely make a model reproducible and auditable as an artifact. One-click serving really does compress deployment from weeks to minutes. Drift and quality monitoring, and agent-evaluation where an LLM judge scores accuracy, factuality, and cost, are real and valuable instruments.
And the newest AI gateways are the most advanced of all: they extend a permission, policy, and audit model from the artifact to the act of inference and tool use — rate-limits, guardrails, credential management, inference logging — and they can do it even for agents running off-platform. That is genuinely impressive, and I want to be precise rather than dismissive about it. It is a governed proxy sitting in front of model-serving. It governs the call — the inference request, the tool invocation — and it captures that call faithfully. The limit is not the quality of the proxy. The limit is where the proxy sits.
The deed is a composite
The consequential deed is rarely a single call. It is a composite condition. Take an illustrative one: release the payment only if amount < X, and model confidence > Y, and a second control has passed. That "and" is the entire business rule — the thing a controller would actually sign off on.
Reach-governance gives you two cleanly governed events on either side of that rule. The gateway logs the inference call. The tool policy allows or denies the disbursement call on its name and arguments. But the composite — the conjunction that decides whether the deed is legitimate — lives in ordinary orchestration code between the two governed events. The gateway saw an inference. The tool policy saw a permitted call. Neither evaluated the "and" as a unit, because the "and" sat in a function nobody governed. This is the two-governed-events-with-ungoverned-reasoning-between problem, and it is architectural, not a maturity gap. You can reconstruct the composite from logs afterward. You did not gate it before it committed.
Four versions of the same gap
The public positions differ in sophistication but share one shape. Each governs a call or a boundary; none governs the composite deed, because in that architecture the deed executes in a system the governor sits beside, not inside.
- "Governing hundreds of agents is an infrastructure problem." The agent-workforce framing is honest about scale but resolves to detect-and-reconstruct — and its own tell is that it discovers several times more agents already running than it had on its books. Discovery-after-the-fact is monitoring, not gating.
- A service-policy DENY on tool name and arguments. Real and useful, but coarse and boundary-bound. It evaluates the call at the perimeter; the calling code that composed the decision stays outside its view.
- Per-character content scanning of prompts and outputs — the kind you are advised to keep minimal to protect latency. It screens text. It does not decide whether the business action should commit.
- A sandbox perimeter that promises an agent "cannot exceed its approved permissions." It bounds reach. But within those permissions, the composite deed is still assembled by orchestration the perimeter never inspects.
Frame it structurally and it stays true regardless of roadmap: governing the call and governing the boundary are both necessary and neither is the deed. The deed is what the process does with the prediction, and that lives one layer in from where all four of these govern.
Make the composite the governed unit
Entroid moves the model to a different place in the topology. It is not an endpoint the process calls out to and logs. It is a Function inside a Deterministic Workflow. The prediction is consumed by the next step of that workflow, and that step is an inline deterministic gate — the composite condition itself. Amount threshold and confidence and segregation-of-duties and, where the process demands it, a required human decision handled by an Atomic Agent with human-in-the-loop as a first-class state rather than a bolted-on escape hatch.
Only if the composite passes does a Connector — the single primitive permitted to touch an external system — commit the action. And it is the action that is permissioned and written to the immutable per-action audit, not merely the call that preceded it. Model-to-action closes on one runtime. There is no interval between "inference logged" and "action taken" for ungoverned reasoning to occupy, because the reasoning is the gated step.
Be clear about what this is not. It is not a claim that ES replaces your estate or needs no integration. The Connector runs over the systems of record you already have; those systems keep committing the transaction. What changes is that the decision to act on them stops being orchestration glue and becomes a governed step on the fabric — evaluated, permissioned, and recorded as a unit, before it fires.
Why shadow agents become structurally impossible
This is the boldest claim in the argument, so let me make it carefully rather than loudly. The shadow-agent problem is definitional in a reach-governed world: you govern the agents you have registered, and you discover the rest. That gap exists because an agent can acquire reach through paths the registry never issued — a credential here, an unmanaged tool there — and the governor's only recourse is to find it after it is already acting.
On the fabric, an Atomic Agent has no capability to touch an external system except through a Connector, and a Connector is a governed step on the one runtime with per-action audit. There is no side door — not because something is watching for one, but because the runtime exposes no other path to the outside world. So for anything running on the fabric, an unregistered, unaudited action is not an incident you detect later; it is a state with no execution path. Discovery is not how the fabric learns what its agents did. Construction is.
The honest boundary: this governs what runs on the fabric. A script someone runs entirely outside ES is outside ES, the same as it would be for any platform — ES is not magic, and it is not omniscient about code it does not run. The differentiator is the consolidation. Put the execution on the fabric through Connectors, and the "known versus discovered" gap collapses, because the fabric does not sample its agents — it is the only place they can act.
An allow-list tells you which doors an agent could open. Only an inline gate decides, before it commits, whether it should open this one.
See what this looks like for your enterprise.
Not a demo. A strategic conversation about how your enterprise could operate
when every process runs on one governed fabric.
