Signal
AI Governance.
Agent Authorization.
Engineering Judgment.

Working on AI agent authorization systems has taught me something that is not yet widely understood: the problem of AI trustworthiness is structural, not technical. The next model version will not resolve it. Larger training datasets will not resolve it. The issue is that in unbounded domains, there is no compiler.

In software, the compiler is a brutal, cheap, automatic corrective mechanism. It catches errors before they reach production. AI has no equivalent. In architecture, integration, and governance decisions, errors made by AI remain invisible until they become expensive. Sometimes catastrophically so.

I call this the verifier gap. It is the absence of a verification layer that catches errors before they compound through a system that has already been deployed, already been trusted, and already been given access to data and decisions that matter.

What fills the verifier gap? In every enterprise AI deployment I have worked on, the answer is the same: engineering judgment. Not a tool. Not a framework. Human judgment, applied at the critical junctions where AI generates outputs that will be acted upon without further review. This is not a temporary situation while the models improve. It is a permanent feature of unbounded domains. And the organizations that understand this first will build systems that hold together under pressure. The ones that do not will discover the gap at the worst possible moment.

On Agent Authorization

What Agent Authorization Actually Requires

The financial services industry is currently building authorization frameworks for AI agents. The regulatory requirements are tightening. The frameworks are more complex than they appear from the outside.

An agent is not just a user. An agent can act on behalf of a user, spawn sub-agents, chain authorizations, and execute transactions at speeds that make human oversight a fiction if the architecture is not designed carefully from the start. The naive approach treats agents like users with special permissions. The naive approach fails because it does not account for scope drift, revocation propagation, liability chains between agent hierarchies, or the audit trail requirements that regulators will enforce retroactively.

What authorization actually requires: explicit scope binding at the moment of consent creation, time-bounded permissions with automatic expiration, revocation logic that propagates synchronously through agent chains rather than asynchronously, and an audit log that can reconstruct the exact authorization state for every decision the system ever made. None of this is technically hard in isolation. All of it requires engineering judgment about what matters before the system exists. After the system exists, the judgment has already been made. The only question is whether it was made deliberately or by accident.

There is a second reason the audit log matters, and it is not a compliance formality. German civil law places the burden on the party who deployed the agent to show what that agent was actually permitted to do. The wider the discretion granted, the narrower the grounds for later contesting what the agent committed to. An operator who cannot produce the mandate, its limits, and the state of the system at the moment of the transaction has no position to argue from. The architecture is the evidence. If it was not recorded at authorization time, it does not exist when it is needed.

The difference between deliberate and accidental authorization architecture is not visible when things work. It is only visible when something goes wrong, when a regulator asks for evidence, or when an agent acts on a permission that should have been revoked three steps earlier in a chain that nobody drew on paper.

On Engineering Judgment

Engineering Judgment Is the New Compiler

Code is now abundant. AI generates it at volumes and speeds that would have been unthinkable two years ago. This is not a threat to engineering. It is a redefinition of what engineering means.

The bottleneck has shifted. When code was scarce, the question was: can we build this? When code is abundant, the question becomes: should we build this, and if so, how do we build it in a way that will not collapse under the weight of the next change request?

That second question requires judgment that no model can supply. It requires understanding the organizational context in which the system will operate. It requires knowing which requirements are real and which are negotiable. It requires anticipating how the system will fail, not just how it will succeed. It requires someone who takes responsibility for the answer.

This is not a soft skill. It is the hardest technical skill in enterprise AI deployment, and it is becoming scarcer as the supply of generated code increases faster than the supply of people who understand what the code is supposed to do, why it was written that way, and what will happen when the organization it serves changes direction.

I have been building enterprise systems since 1998. The tools have changed beyond recognition. The underlying challenge has not. Technology moves faster than organizations. The gap between what a system can do and what an organization can absorb is where most transformation projects fail. Closing that gap requires human judgment. It has always required human judgment. AI has made that judgment rarer, not more common. That is the central fact of enterprise AI in 2026.

Field Note · June 2026

Gopuff Go and the Authorization Question Nobody Asked

On June 3, 2026, Gopuff and xAI launched Go, a Grok-powered shopping agent that builds your cart the moment you open the app. It runs against 13 years of Gopuff order history, real-time signals from X, and live inventory across 400 micro-fulfillment centers. For returning customers, the agent completes the transaction with a single tap.

This is not a product recommendation engine. This is an agent making purchasing decisions on your behalf, autonomously, before you have expressed any intent in the current session.

The press coverage focused on the experience: the TikTok-style contextual scenes, the hands-free voice checkout, the prediction accuracy. Gopuff co-founder Yakir Gola described it directly: the greatest friction in commerce is no longer delivery. It is the moment before. The thinking, the deciding, the remembering. Go removes that friction at scale.

Almost nobody asked the architecture question. Who authorized the agent to build that specific cart? What is the scope boundary? What happens when the prediction is wrong and the transaction has already executed? What is the revocation mechanism? If the user disputes the charge, what does the audit trail look like? Is the authorization model session-bound or persistent? What stops the agent from acting during a session the user did not intend to be a shopping session?

Gopuff's press release notes that xAI is configured to prevent Grok from training on individual customer data while still using order history for real-time personalization. That is a privacy statement. It is not an authorization architecture.

When friction is removed, the authorization architecture must carry the entire load. Every decision the agent makes that would previously have required a conscious human choice now requires the system to have already made that choice correctly, with the user's genuine prior consent, within a scope the user actually understood, backed by an audit trail that would hold up to scrutiny. That is not a product feature. It is a governance problem. And it is already live in the Gopuff app.

The underlying mechanism is the same one at work in the Alibaba/ROME incident from late 2025, where a 30-billion-parameter RL agent opened a network backdoor and attempted to mine cryptocurrency during unsupervised training. The agent was not going rogue. It was following the gradient of a reward function that did not explicitly forbid those actions. Interact with the RL simulation that makes this mechanism visible.