What Governance Actually Sees

Most claims about agentic governance are made in adjectives.

Policies are enforced. Agents are governed. Guardrails are runtime. Adjectives are unfalsifiable, and the enterprise buying them has no way to test the claim before the audit tests it for them.

A schema is different. A schema is a commitment. Omnigent publishes its policy engine — the events a policy receives, the verdicts it may return, and the state it is permitted to keep [1] [2]. It repays a close reading, because it answers the question the adjectives cannot: what does the governing layer actually see, and what does it keep?

The answer has two halves, and only the second one is the argument. But before either, a distinction that most commentary collapses and that decides everything downstream.

Two corridors

Omnigent ships in two forms, and an enterprise does not get to choose which one it is reading about. It gets the one it deploys.

The open-source project. Apache 2.0, on GitHub. You run the server, you bring your own model credentials, and you can author your own policies — the documentation walks you through writing a handler, registering it, and composing it with the builtins [1].

Omnigent on Databricks. A managed Beta in the product documentation: a Databricks-operated server, workspace identity, Databricks Sandboxes, and model access through the Foundation Model APIs and Unity AI Gateway [7] [16].

The policy engine is the same engine in both. Most of what follows is therefore true of both. But two differences separate the corridors, and both of them cut against the one an enterprise is actually on.

On the managed corridor, model access is not optional. A Databricks Sandbox host always routes model access through AI Gateway, and you cannot bring your own model API keys [7] [16].

And on the managed corridor, you cannot write a policy. The product documentation states the limitation plainly: only built-in contextual policies are supported, and custom YAML-based policies are not available [7].

Hold on to that second one. It is the most consequential sentence in the product documentation, and it reframes everything that follows.

What the layer sees

A great deal.

An Omnigent policy is a function invoked at enforcement points, and those points are not limited to tool calls. Policies intercept tool calls and their responses, file operations, and — this is the part that matters — the inputs and outputs to the model itself [2] [3]. The policy documentation is explicit that a handler abstaining on a tool call is abstaining on one phase among several [1].

So the model-facing stream passes through the governing layer. The assembled prompt goes past it. The completion comes back past it. A policy positioned there can read both.

That is a far wider surface than a gate on tool names, and any reading that says otherwise is wrong. The layer is not blind.

It is, however, still outside. The announcement is explicit about the design premise: each wrapped harness is treated as a component whose interface is messages in, tool calls out [9]. The layer observes what crosses that interface. It does not participate in what happens behind it.

Which makes the real question sharper, not softer. If the stream passes through — what does the layer retain?

What the layer keeps

Here the schema is unambiguous, and it is the whole argument.

A policy carries session state, and that state is the layer’s memory. The permitted operations on it are four: set, increment, delete, append [1]. A handler receives the prior state and the incoming event, and returns state updates and a verdict.

Now read what the builtin policies actually persist. The cost policy keeps a running spend total [1] [3]. The rate-limit policy keeps a count of tool calls [1]. The risk policy keeps an accumulated score — in the authors’ own words, “a single number” [3]. The Drive policy keeps a set of document identifiers [3]. The intent policy keeps the user’s opening request [3].

A number. A count. A number. A set of IDs. A string.

The stream passes through, and a scalar stays behind.

And on the enterprise corridor, the scalar is a ceiling

Now put the corridors back on.

In the open-source project, the scalar is a default. A determined engineer can author a handler that accumulates more. The state model still bounds them — set, increment, delete, append — but they choose what to keep. The ceiling is the schema.

On the managed corridor, the scalar is a ceiling. You cannot write a policy that retains more, because you cannot write a policy [7]. The enterprise gets the builtins. And every builtin persists a number, a count, or a set of identifiers.

So on the path Databricks sells to enterprises, a scalar is not what the governing layer happens to keep.

A scalar is all you are permitted to keep.

This is Compression Debt shipped as a product boundary — coverage aggregated into a value that cannot be decomposed [8]. And the loss is not incidental to the design. It is the design: a governing layer that persisted the full stream would be storing a second copy of every session it governs. Nobody builds that on purpose, and Omnigent has not.

The research says the difference is decisive. In the Stanford Meta-Harness ablation, a system reading full execution traces reaches 56.7 best accuracy; one reading only scores reaches 41.3 — roughly a fifteen-point gap, with the authors concluding that raw traces are the ingredient that matters and that compressed summaries do not substitute for them [6].

The governing layer sits on the scores side of that line. Not because its engineers chose poorly, but because a policy is a decision point, not a record. It is invoked to decide. Its memory is whatever the policy author needed in order to decide — and on the enterprise corridor, the author was not the enterprise.

And notice what the retained state is: a thinner, re-derived shadow of state the wrapped harness already holds more richly [12]. Two sources of truth about what the session did, and the one doing the governing is the impoverished copy.

Observation is not retention.

Four verdicts, and none of them is attest

The documented verdict set is three: allow, deny, ask [1] [2]. The authors describe a fourth capability — transforming the messages before they reach the model [3].

And the fourth one is not like the other three.

First, an honest note on the evidence, because it matters. The published verdict enum lists three values — ALLOW, DENY, ASK [1]. Transform appears in the authors’ own description of what a policy may do [3], not in the documented return set, and no builtin we can find exercises it. So what follows is a claim about what the policy model permits, not an allegation about what is running in anyone’s estate today. That distinction is the difference between an argument and an accusation, and the argument is enough.

Allow, deny, and ask are arbitration. The layer stands outside the decision and rules on it. Transform is authorship. The layer reaches into the context window and edits what the model will see.

And composing the model’s context is not a thing a harness does. It is the thing a harness is [9].

The last mile

The Omnigent architecture holds its design premise for most of the journey. Wrap the harness. Treat it as a black box whose interface is messages in, tool calls out. Govern the seam between them. Every step of that is consistent, and every step of it is defensible.

Then, in the last mile, the layer reaches into the context window.

That step is the harness function. A policy model that admits transform is a policy model that admits the harness function — and at the moment it is exercised, the layer is not sitting above the harnesses. It is one of them.

And having crossed, it takes nothing else a harness carries. It composes context without holding the loop. It authors the decision basis without keeping the plan, the alternatives, the retries, or the record. It crosses into the harness in the last mile, and arrives without the trace.

Look at what that means for the stack. Every wrapped harness holds its own execution record. Claude Code has one. Codex has one. The component that rewrote what the model saw would be the only one in the stack with nothing but a counter.

The meta-harness does not cease to be a meta-harness because it wanted to be a harness. It ceases to be one in the last mile, on a single verdict — and takes on the harness’s authority without the harness’s accountability.

The prompt is the decision basis

There is nothing illegitimate about the capability itself. Redacting a credential, neutralizing untrusted content before it can carry an injection, stripping identifiers from a prompt — these are exactly what security teams have asked for, and an enterprise should want them. The engineering instinct is sound.

The problem is the accounting.

A model does not reason over what the harness intended to send. It reasons over what arrived. So the prompt is not a transport detail. It is the decision basis, and whoever writes it authors the decision. A layer holding transform is not adjusting a route around bad weather. It is rewriting the reason the aircraft is flying at all.

The harness composes a context. A policy rewrites it. The model reasons over the rewritten version and answers. Whether both versions survive is not a property of the layer — it is whatever the policy author thought to keep, out of set, increment, delete, append [1]. Nothing in the state model requires the original. Nothing in the verdict requires a diff.

So the architecture permits a causal chain in which what the model saw and what the harness believes it sent are not the same object, and no component is obliged to reconcile them.

And here the corridors invert

This is where the open-source project and the managed product come apart, and the asymmetry runs the opposite way from what the marketing implies.

On the open-source corridor, an engineer holds three powers. They choose which policies to install, so a policy that rewrites messages is one they can simply decline. They can author a policy that appends the pre-transform context to session state — ugly, expensive, and possible [1]. And so they can have the rewrite and the diff. Transform and accountability can coexist, if someone builds for it.

On the managed corridor, the enterprise holds none of them. It cannot decline a builtin it was never shown. It cannot author a retention policy, because custom policies are not available [7]. And the most natural builtin any enterprise platform eventually ships — redaction of sensitive data before it reaches a model — is a transform.

So the claim is not that anyone is rewriting your prompts today. It is narrower, and harder to answer:

The architecture permits the decision basis to be rewritten, and on the corridor an enterprise actually deploys, that rewrite cannot be instrumented even in principle.

An enterprise’s assurance story rests on one sentence: we know what we asked the model. That sentence is the floor. Everything above it — the logs, the gates, the scores, the attestations — assumes it holds.

An editor who keeps no draft history is not a governor. He is an unaccountable author.

Now notice what none of the four verdicts is. Every one of them is an action on what happens next. Allow it. Block it. Ask a human. Rewrite it. Each answers the same question: may this proceed, and in what form?

Attestation answers a different question: why did this happen, and what did the system know when it permitted it? [11]

There is no verdict for that, because a verdict is not an account. An auditor arriving after an incident does not ask whether the gate opened — the log already says it opened. The auditor asks why the action was reasonable at the moment it was taken. And “allow” is not an account of anything. It is a record that a condition was met.

Enforcement is not attestation. The layer can act on the stream with real force. It cannot testify about it, because it did not keep it.

This is the distinction the enforcement lifecycle turns on: where a control lives determines what it can guarantee [13]. A control at the seam guarantees the seam.

The control that creates the seam

The cost policy is the sharpest instance, and it is not a bug.

At its hard limit, the spend cap does not stop the work. It blocks further calls to the expensive model and lets the session carry on with a cheaper one — a downgrade, chosen deliberately over a halt, so that the work is not lost [1] [3].

Read that as architecture. The governing layer’s remedy for overspend is to induce a model swap in the middle of a live task. The control’s own enforcement action produces exactly the discontinuity that makes end-to-end provenance hard to reconstruct: the executor that finishes the task is not the executor that started it, and the layer that swapped them kept a spend total, not a trace.

The control creates the condition the control cannot attest to. That is not carelessness. It is what happens when the only lever you own is on the outside — and when the humane choice, keeping the work alive, is also the one that fragments the record.

The layer has since taken more of that lever. In v0.5.0, the router can override a model the orchestrator explicitly named [10]. The executor is now something the governing layer selects, not merely something it observes.

“But the gateway sees everything”

This is the strongest objection to everything above, and it deserves a direct answer rather than a footnote. It also lands on exactly one corridor.

On the open-source corridor, there is no gateway. You bring your own credentials, calls go to the provider, and no Databricks surface logs the payload. The scalar in session state is not an impoverished summary of a fuller record kept elsewhere. It is the record.

On the managed corridor, the payloads exist. A Databricks Sandbox host always routes model access through Unity AI Gateway, and you cannot bring your own keys [7] [16]. Every inference call crosses a boundary Databricks owns, and is logged there. That is a real and valuable position — and it is how their own benchmark team measured context volume across two harnesses in the first place [5].

Three things follow, and none of them rescues assurance.

First, the surfaces are disjoint. The gateway is an observability boundary at the model call. The policy engine is an enforcement boundary at the agent action. A policy’s state model is set, increment, delete, append [1]; it does not query the gateway’s logs. You can log the prompt and you cannot gate on it. You can gate on the action and you do not keep the prompt. Governance is split across two surfaces, and neither one holds both halves — and on the managed corridor you cannot write the policy that would bridge them, because you cannot write a policy [7].

Second, a proxy log is not a decision trace. The gateway sees a sequence of inference calls. It does not see the harness’s control flow — what was retrieved and discarded before the prompt was assembled, what plan the call served, what was retried, how the result was used. A transcript of calls, stripped of the loop that produced them, tells you what was sent. It does not tell you what was considered.

Third, their own experience makes the point better than I can. When the benchmark team needed to know whether an agent had gamed the evaluation by reading git history, no metric surfaced it. They found it by inspecting traces — a human being, reading the record, reasoning about intent [5]. That is not a governance surface enforcing a policy. That is forensics, performed once, by the people who built the system.

You cannot own the write path by proxying it. A toll booth on the road is not the road.

Both corridors arrive at the same place by different routes. One keeps a scalar and nothing else. The other keeps a scalar, plus a transcript it cannot enforce on, in a policy you are not permitted to write.

Throughput is billable. Retention is overhead.

There is a reason the layer keeps a number, and it is not a failure of imagination.

Databricks reported annualized revenue of $6.9 billion in June 2026, growing more than 80% year over year, with gross margins slipping to roughly 74% from above 80%. Ali Ghodsi’s own account of the compression is that agents generate far more queries than human users do, that this is what a consumption-based business model looks like as agentic AI arrives, and that he expects margins to fall further [17].

Take him at his word, because it is the honest description of an intermediation business. Volume through the boundary is the product.

Now ask what assurance costs. Assurance is not throughput — assurance is retention. It is keeping the stream: the context assembled, the alternatives discarded, the version before the transform and the version after. Every one of those is storage, and none of it is billable.

Passing tokens through a gateway is revenue. Storing what they meant is cost.

This is not an accusation about anyone’s motives, and it does not need to be. It is the incentive geometry of every intermediation position ever built. A toll booth counts cars. It does not know where anyone is going, and it has no reason to find out.

The one thing the architecture cannot afford to keep is the one thing the auditor needs.

The harness is a one-line field

The last piece is the smallest, and it may be the most revealing.

In an Omnigent agent definition, the harness is a single field in a YAML file — one string, swapped for another [4]. The architecture models the harness as an interchangeable executor: a configuration value, a commodity, a detail.

Now set that against the same company’s benchmark. Running the same model through two different harnesses produced a cost difference of more than two times at equal quality, and the reported cause was how much context each harness fed the model — the lighter harness sending roughly a third as much [5].

The decisive variable — the one their own measurement identifies as moving cost and quality most — is encoded in the architecture as a string you can change without thinking. Whatever a system models as a swappable field is, by construction, not where that system believes the architecture lives.

The benchmark found the architecture. The schema had already filed it under configuration.

What governance means here

One word has been doing two jobs, and the piece cannot close until they are separated.

Governance, as the policy layer defines it, takes the fleet as its object: which harness runs, what it may call, what it may spend, when it must stop and ask, what may be rewritten before the model sees it. That is real, and it is coordination-grade [18]. Governance, as an auditor or a risk committee defines it, takes the decision as its object: why this action, on what basis, under whose authority, and show me. That is assurance-grade. The distinction is not a Luminity construct — the same vendor’s own architecture manifesto argues the intrinsic side of it, that governance belongs inside the system producing quality [15].

Now read the sequence the architecture runs. Federation makes the estate ungovernable in the second sense: a fleet of mutually opaque harnesses, none able to see inside the others. The policy layer is what makes that arrangement sayable — no risk committee accepts a fleet of black boxes on its face, but a fleet with a central gate in front of it can be presented as governed. And the gate can only ever govern what federation exposes.

The gate is not there to make the enterprise defensible. It is there to make the federation adoptable. Those are different jobs, and the enterprise is buying the second while being told it is the first.

And notice what the primitives are. Spend caps, tool-call ceilings, approval prompts, sandbox enforcement — every one is a harness function. They already exist inside a governed harness, where they run with the execution trace attached. The meta-harness does not introduce them; it re-implements them at the seam, where they keep less.

So state it plainly: the ring is not a capability. It is technical debt. Federation created the need; the gates service it. The enterprise pays again for control it already had — in a place that can no longer explain it.

And the next question is not whether the gates work. They do. It is who wrote them, on what evidence, and what record exists of that authorship — because a control authored inside the session it governs needs a provenance of its own [14]. On the enterprise corridor, that question has an answer the enterprise did not choose: the policies were authored by the vendor, and the enterprise may not write its own [7].

Assurance is not a ring you add above the system. It is a property of the system that writes the state.