Your Agent Governance Layer Is a One-Way Valve

Under 100 milliseconds. That is the latency budget Uber engineers put on the layer that inspects every single model call in their fleet, and the reason they gave for it is the most useful sentence I have read about agent governance this year. In Port’s writeup of a talk by Uber engineers Uday Kiran Medisetty and Adam Huda: “Applied to every model call and given a strict latency budget, it means nobody bothers routing around it.”

That is a design constraint, and it is also an admission. A control that costs the caller real time gets bypassed by the caller. Not maliciously. An engineer under deadline finds the direct endpoint, an agent framework ships its own client, a batch job takes the fast path “just for the backfill”. Governance that is expensive to obey decays into governance that nobody obeys, and no policy document reverses that. Uber’s answer was to make obedience cheaper than evasion.

The scale behind that budget is worth stating. Per the same talk, over 100 million model requests a day across more than 800 projects flow through Uber’s LLM gateway, which strips more than 20 kinds of PII and runs an “AI guard” of five smaller models, all inside the same sub-100ms window. A separate MCP gateway fronts over 1,000 tools and cut token usage by more than 40% across the fleet. More than 70% of pull requests at Uber now come from local or cloud agents, and lines of code per engineer has doubled year over year.

One caveat on those numbers, and it matters. They come from a conference talk, written up by Port, a vendor selling this exact category of platform. Port states plainly that the numbers, the architecture and the design calls are Uber’s. Read them as an engineering team’s public account of its own system, not as an independently audited disclosure.

The Same Argument, Built Small

The second example is the useful one, because it does not need Uber’s scale to make sense. Octopus Deploy published the design of an AI-powered incident bot, and the constraint they chose is arithmetic rather than architectural: the model may propose exactly five remediation types. pod_restart, resource_increase, config_update, image_fix, deployment_rollback. Model output is constrained to JSON matching a predefined schema, with no arbitrary command generation anywhere in the path.

Patroklos Papapetrou, writing for Octopus, gives the principle in one line: “The model should help interpret the incident, not control execution.” And the sentence that should be pinned above every autonomous-remediation project: “A model reporting HIGH confidence does not guarantee that its diagnosis is correct or that the proposed action is safe.”

Note what Octopus did not build. No dynamic policy engine, no risk scoring, no learned trust tier. An allowlist of five, and a schema. That control is cheap to obey for the same reason Uber’s is: there is no faster path than the one the schema already permits. It is the small version of the same insight, and it needs no platform to build. We have argued the reverse case, that a control surface without enforcement is a document, and that back pressure belongs in the risk model rather than in the approver’s calendar.

Both Gates Run in One Direction

Now look at what these two systems have in common besides being good. Every component described is inbound. The agent proposes, the layer inspects, the layer permits or blocks or rewrites. PII stripped on the way in. Tools resolved on the way in. Remediation type validated on the way in. Uber’s inner-loop rule has the same shape: its coding agent stops at a draft PR and does not push to CI, because, as the team put it, it hammers shared CI before anyone has confirmed the feature even works.

Excellent controls. All of them answer one question: may the agent do this?

None of them answer the other one: the agent noticed something. Where does it go?

Ron Bronson names this directly. His distinction is between a judgment router and an exception channel. A judgment router evaluates uncertainty, stakes, authority and novelty, then permits, escalates or blocks a proposed action. An exception channel runs outside that gate entirely. It neither authorizes nor blocks. It reports a condition met during work that was already authorized. Bronson’s piece carries no statistics and does not pretend to. It is a conceptual argument, and its value is that it names a component neither of these systems has.

His example is small enough to be uncomfortable. An agent booking gym classes against a GraphQL API discovered that it could cancel other members’ reservations and remove them from waitlists. Nothing the agent did was unauthorized. Booking a class was the task. The permission to cancel other people’s bookings was sitting there in the API, discovered as a side effect of doing the assigned job correctly. That is a finding, not a permission request. A judgment router has nothing to evaluate, because nothing is being proposed. And in that system the finding had no route anywhere except a human happening to notice.

Scale that up. At 100 million model requests a day, how many findings of that shape does a fleet generate in a week? Uber’s context graph holds 40 million entries across 150 kinds of nodes and edges, replacing context previously spread across 20 to 30 systems. That graph is an extraordinary inbound asset: it is what the agent reads. The outbound equivalent, a place where the agent writes what it learned about the system it was operating on, is a different structure with a different consumer.

What an Unreported Condition Costs

GitHub’s August 17 outage ran 7 hours and 47 minutes. CTO Vlad Fedorov’s account of the recovery: “Errors in those services triggered a client-side retry loop that increased traffic during recovery. We had to mitigate that behavior before we could safely restore traffic.” Monthly commits on the platform have grown from 1.4 billion to 2.9 billion since April.

I am not claiming agents caused that outage, and GitHub does not say they did. What the incident illustrates is the shape of the problem. Every client in that retry loop was doing exactly what it was authorized to do. Retrying a failed request is correct behavior. The aggregate was the failure, and it was a client-side behavior that only the server side could mitigate. An approval gate on each individual retry would have permitted every one of them, correctly. The condition worth reporting was not any single action. It was the pattern the actor could see and the gate could not.

That is the class of signal an exception channel carries. Its grammar is “you should know”, filed while the authorized work continues. Discovered permissions the task never needed. Data reachable that the requester probably did not intend. A stale runbook the agent worked around silently. Retry behavior the agent can measure locally and the platform cannot.

We have written before about the six surfaces a kill switch has to cover and about Uber’s own cost caps. Those are stop mechanisms. This is the opposite direction, and it is the one neither of these systems has built.

Build the Cheap Version First

Do not start with a platform. Start with a table and a rule, and hold it to the same latency logic that makes Uber’s gateway survive.

Give every agent a single non-blocking write target. One endpoint, one queue, one table, whatever your stack already runs. Four fields carry most of the value: what the agent was authorized to do, what it observed, where it observed it, and how sure it is. The write must never block the task and must never be able to fail the task. An exception channel that can break the work will be removed from the work.

Then define the one rule that separates it from your existing alerting: this channel is for conditions met during authorized work, never for permission requests. Anything asking “may I” belongs in the approval path you already have. Mixing the two collapses the channel into a second approval queue, and a second approval queue gets muted like every other queue nobody owns.

Then pick an owner and a review cadence. Weekly is enough to start. An unread channel is worse than no channel, because it produces the paperwork of governance without any of the effect.

Uber’s number is the one to remember, for a reason that has little to do with performance. Sub-100ms is the price they were willing to pay so the control stays in the path when the humans are in a hurry. Apply the same test to the outbound direction. If reporting a finding costs an agent more than staying quiet, your agents will stay quiet, and you will keep learning what they found only when a human happens to notice.

---

This analysis synthesizes How Uber built a software factory: the MCP gateway and the platform underneath (Port, reporting a talk by Uber engineers Uday Kiran Medisetty and Adam Huda, August 2026), Building an AI-powered incident bot with Octopus Deploy (Octopus Deploy, August 2026), Agent experience needs failure affordances (Ron Bronson, August 2026), and The August 17 outage, and the work ahead (GitHub, August 2026).

Victorino Group helps engineering organizations design the reporting path their agent platform is missing, alongside the approval path they already built. Let’s talk.