Nobody Was Watching. The Run Is Still Running.

Start with what holds, because most of this release does.

Omnigent v0.11.0 extends two governed controls onto scheduled execution: a per-firing spend cap denominated in dollars, max_cost_usd, and a per-task Claude Code permission mode that may be set as permissively as bypassPermissions [01]. Both arrive as net-new nullable columns on the scheduled_tasks table, in two adjacent migrations chained one on the other — the cap first, the permission mode on top of it [08][09]. This is not a refactor. Across the policy engine and the scheduled path, the diff from v0.10.0 is six files, and the fire path itself is eighty-five insertions with zero deletions [10]. The release is purely additive.

And the additions are defended. Setting a permissive native permission mode does not buy an agent a way past the approval gate: the server-side ASK park is explicit that a permissive acceptEdits or bypassPermissions cannot skip it, and that the action stays blocked until a real human verdict arrives [05]. Timeout and upstream disconnect fail closed to deny. The permission-mode flag is injected only for a confirmed Claude-native agent, so a mis-stamped row degrades to no flag rather than failing the entire firing [02]. Each of those is the right call. An architecture that ships a bypassPermissions setting and then refuses to let it bypass the thing that matters has understood something real about where authority has to live.

So the gate holds. That is settled, it is worth saying plainly, and it is not what this Dispatch is about.

The control assumes a reader

max_cost_usd does not stop a session. The cost policy is unchanged in kind at v0.11.0 — the policies/ tree is entirely absent from the release diff [10] — and its documented behavior remains a downgrade gate rather than a hard stop. Once spend reaches the limit, the policy denies while the session is still on an expensive model; once the session has switched to a cheaper one, it is allowed again [04]. The remedy is a model switch, and the deny text instructs the agent to relay the message to the user verbatim, then stop and wait for them.

On an interactive session, that is a reasonable design. The person who owns the budget is sitting there, reads the message, and decides. It is worth noting in passing what that decision costs, because this cluster has already read it: a model switch is not a neutral act, and swapping the model swaps the control set that governs the rest of the turn [14].

On a scheduled firing there is no person. The control was written for a session with a human in it, and v0.11.0 routes into it the one class of session defined by having none. That is the whole hinge, and it is not a defect in the cost policy — the cost policy is doing exactly what it says. It is a mismatch between a control’s assumed reader and a caller that supplies no reader.

The same shape governs the permission mode. Fail-closed-to-deny is correct when a human is present to be asked. On an unattended firing, the ASK has no addressee. The gate holds, and holds, and nothing arrives to resolve it.

What the record says

Here is where the reading turns from control to record, because the two exits above should at least be legible afterward. They are not.

Exit one: the cap never attached. The fire path attaches the cost policy by writing a synthetic policy row named __scheduled_task_cost_budget against the new session. The attachment is explicitly non-fatal by design — its own docstring states that an uncapped session is preferred to a dead run — so a failure logs a warning and the firing proceeds [02]. That is a defensible availability trade, stated openly. The problem is downstream of it. The attach happens at line 431; the run row is written at line 472. Every other failure branch on that path — seven of them — pairs its log line with a run record carrying a status and an error_code. The cap-attach failure is the sole exception: it logs, falls through, and the run is recorded as an ordinary running. The run record’s field set has no slot for policy attachment at all [02]. A firing that ran with no spend cap is, in the record, indistinguishable from one that ran fully capped. The divergence exists only in a server log line, which is not an audit record and carries no stated retention contract.

Exit two: the run parks. The fire path records the run as running and returns immediately, without waiting for the turn to finish. Completion is event-driven, flipped when the conversation reaches a terminal edge [03]. A run parked at an approval gate never reaches a terminal edge. There is deliberately no startup sweep and no periodic poll of any cadence — the module says so — and the sole backstop is a pure age check that executes lazy on read, force-failing stale runs only when someone calls the scheduled-task list or detail endpoint. The threshold is six hours, chosen generously so a legitimately long turn is never killed. The module’s own characterization of the interim state is that it is harmless until someone looks [03].

Read that as an architect and not as a maintainer. The completion state of an unattended governance run is not materialized by a timer. It is materialized by an act of human observation. Until a person opens a screen, the run that a governance control stopped is, in the system of record, still running.

And when the observation finally happens, the record it writes cannot name what happened. The force-fail sets error_code to incomplete, with a message reporting that the run did not reach a terminal state within the window [03]. That string is identical whether the host died mid-turn, the server restarted in flight, or a permission gate correctly refused an action and waited for an operator who was never going to arrive. The control worked. The record cannot say so.

The path nobody documented

One more absence, reported as a negative finding with its method. Searching the policy reference for the scheduled path returns nothing: grep -c "scheduled" docs/POLICIES.md yields 0 at v0.11.0 [06]. The document enumerates builtin policies by category — safety, cost, GitHub, Google Workspace, working directory, risk score, routing — and documents cost_budget and user_daily_cost_budget directly. It does not mention scheduled tasks anywhere. The __scheduled_task_cost_budget policy that the fire path synthesizes on every capped firing has no entry in the reference that describes the policy surface.

Meanwhile the README presents max_cost_usd in its policy example under an inline comment calling it a hard spend cap [07], which the cost policy’s own documentation contradicts at the same tag [04]. That gap is not new and is not the argument here; it is noted because a reader reaching for the documented behavior of the unattended path has the README, and the README is the wrong end of the discrepancy.

And here the corridors invert again

Everything above reads the open-source project. Put the corridors back on, because the reading changes — and it changes against the corridor an enterprise actually deploys.

Start with the documentation. The Omnigent-on-Databricks overview is stamped last updated July 28, 2026 [18]; the quickstart, July 24 [19]. v0.10.0 shipped August 19 and v0.11.0 on August 25. The managed corridor’s documentation therefore predates both releases, and neither page mentions scheduled tasks or automations anywhere. Set that alongside the policy reference, which returns nothing for the same search [06]: two documentation surfaces — the open-source policy reference and the managed product documentation — and the unattended path appears in neither.

Next, the constraint that has not moved. The managed limitation is unchanged and stated plainly: only the built-in contextual policies are supported as policy handlers, and custom policy functions that run arbitrary code are not [18]. So the built-in cost_budget that the fire path attaches is permitted on managed — the cap works. What is not permitted is authoring anything that keeps more. The scalar-as-ceiling reading from July now reaches the run record: on this corridor the enterprise cannot write the policy that would retain what incomplete drops [17].

Then the part that inverts. The sole record that a scheduled run fired with no cap attached is a warning line in the server log [02]. On the open-source corridor the enterprise operates that server, so the record is thin, unretained, and theirs — recoverable if someone thought to collect it. On the managed corridor the server is Databricks-operated [18]. The one place the divergence is written is on the far side of a boundary the enterprise does not control, and it cannot author a policy that would put the fact anywhere it can reach.

And the aggravating detail is in the sales pitch, not the code. The managed documentation recommends the Databricks Sandbox on the grounds that it keeps running when the laptop is off and stays on while the laptop is asleep [19]. Unattended operation is the corridor’s advertised advantage. It is also the corridor with the least ability to instrument it.

One question this Dispatch does not answer. Managed routes all model access through AI Gateway, and bringing your own model keys is not available on a Sandbox host [18]. AI Gateway carries spend controls of its own, so a scheduled task’s max_cost_usd and a Gateway limit are two cost controls over one run. No first-party source states how they compose or which takes precedence. That is a live question, recorded as open rather than answered.

The hard claim

Two things can go wrong on an unattended run in Omnigent v0.11.0, and they are not the same kind of thing. The first is control-state divergence: the intended cap never attached, and execution continued without it. The second is governance-induced noncompletion: a control executed exactly as designed, and the reason the run stopped was not retained. The run record answers neither — it cannot show that the cap was absent, and it cannot distinguish a correctly held gate from a dead host.

That the gap appears on both sides is what makes it architectural rather than incidental. When governance fails to attach, the record does not say so. When governance succeeds, the record does not say why.

Name the three things an assurance case actually needs, because the corpus will reuse them. Presence: was the intended control attached? Execution: did a control fire? Causality: was that control the reason the run stopped or changed state? The uncapped firing is a presence failure. The parked run is an execution and causality failure. incomplete is a causality failure.

This is the same architectural property the cluster has now found at every layer it has read — the seam rather than the trace [16], the manifesto against the product [15], the policy schema and its scalar [17], the intent check [13], the approval gate [12], and the human in the approval path [11]. Naming it once is an observation. Naming it at the seventh artifact, four of which the vendor published after the observation was made, is a finding: the enforcement is real and the retention is thin. The gate holds a verdict and keeps a scalar. The cap denies a turn and keeps a status. The run row records that something did not finish. None of them keeps the cause.

What makes that a finding rather than a conviction is that this release contained a place it could have broken. A governing layer that ships a setting named bypassPermissions and then honors it on an unattended run would have been the read-path architecture behaving exactly as its critics assume. It does not. The server-side park refuses the bypass and fails closed [05]. That is the write-path-correct answer, chosen deliberately, and the thesis survives the release because the engineering got that part right rather than in spite of it. The claim is about what the position can retain, not about whether the team is careful. They are.

Be precise about how far that goes, because the obvious version of it overreaches. Given the boundary Omnigent currently exposes, incomplete is all this layer has retained enough information to assert — the reasoning that made a stop correct was produced inside a runtime belonging to someone else, and the layer governing from above it holds only what crossed the seam [15]. That is a finding about this architecture at this tag. It is not a proof that a control plane can never carry causal evidence; an executor that surfaced structured governance events across the boundary could supply one.

And the narrower reading is the harder one to answer, because the schema here does not need a richer boundary. The run record already carries an error code, and the reconciler already writes into it. A distinct value for a governance stop is an unused field, not a missing capability. The cap-attach failure branch already sits beside seven siblings that each write a status and a code, and does not. So this is not a limit the position imposed. Following the distinction this cluster drew at the approval gate [12], the authority questions need a finer model and the evidence questions do not: recording which control stopped a run is an evidence choice, available at this boundary, and not taken.