Priced at Zero: The Review Layer That Agent Economies Refuse to Book

Notion shipped two numbers in the same fiscal quarter. The first was a 90% reduction in inference cost per agent task. The second was a feature called "Review for me," which routes an agent's planned action to a second model for a safety verdict before execution. Microsoft shipped Guardian Agents in the same window with a harder constraint: provable human approval before the agent touches anything that moves value.

Two announcements. One contradiction. If the agent is 90% cheaper and the model is finally good enough to run unsupervised, why does every serious vendor in the category ship a gate?

I spent three weeks in a sandbox rebuilding the arithmetic behind that gate. The answer is not a scandal. It is worse than a scandal. It is an accounting hole. The review layer is load-bearing — remove it and the structure falls — but it is priced at zero in every balance sheet that touches it. Not discounted. Not subsidized. Zero. The vendor books the compute. The customer books the headcount. Nobody books the dependency.

Tracing the invariant where the logic fractures: the cost of an autonomous agent is not the cost of its tokens. It is the cost of the tokens plus the cost of everything the tokens cannot be trusted to do alone. Only the first term appears in any price.

This matters more on-chain than off-chain. Off-chain, a wrong agent output is a bad email. On-chain, a wrong agent output is a signed transaction. The review tax is not an abstraction in this stack. It is paid in gas, in locked capital, in dispute windows, and in keeper budgets. It has a block height. That is the story nobody is publishing.

The harness is the product, not the model

Start with mechanics. An agent is a loop: plan, act, observe, repeat. The model is one component inside that loop. Everything else — tool schemas, retry logic, context compaction, permission scopes, and the gate — is the harness. Vendors sell the harness. The model is a commodity input they rent from three or four suppliers.

The gate has three standard architectures, and they are not equivalent.

A guardrail model. A second, narrower model scores the actor's proposed action before execution and returns a verdict plus a reason. Cheap, fast, fully automated. Notion's review feature is this shape.

Human-in-the-loop, hard gated. A human must approve before execution. The action blocks indefinitely until approval arrives. Microsoft's "provable human approval" requirement is this shape.

Human-on-the-loop, monitored. The action executes immediately; a human watches a stream and can reverse. This is the cheapest and the most dangerous, because reversal is rarely possible once value has moved.

The same three architectures already exist on-chain, under different names. Pre-flight simulation before a transaction is broadcast — the eth_call you run against a fork before you sign — is a guardrail model. A keeper network that simulates and only then sends is a guardrail model with a gas budget. An optimistic rollup's fraud-proof window is a hard human gate at the protocol level: the state root is accepted optimistically, but an independent party with standing has a bounded window to reverse it. A 48-hour governance timelock is a human gate with a constant instead of a reviewer.

The mapping is exact, which is why the economics transfer. The on-chain stack has been paying the review tax for years. It just calls it something else.

Where the logic fractures: the reliability arithmetic

The reason every vendor ships a gate is arithmetic, not caution. Agent tasks are multi-step. Reliability compounds multiplicatively across steps.

p_end_to_end = Π p_i   for i in 1..n

At 95% per-step reliability — which is a good model, not a bad one — a ten-step task succeeds 59.9% of the time. At twenty steps it succeeds 35.8%. At forty steps, 12.9%. The curve is not linear and it is not intuitive. It is the reason an agent that looks impressive in a demo fails in production, and it is the reason the gate exists.

Here is the part the marketing decks omit. Cost per attempt and cost per successful outcome are different numbers, and only the first one fell.

cost_per_success = cost_per_attempt / p_end_to_end

If inference cost per attempt falls 90% while end-to-end reliability falls from 0.99 to 0.90, cost per success falls by roughly 89%, not 90%. That looks like a rounding error. It is not, because on-chain the failure is not free.

This is the asymmetry that breaks every per-token pricing model, and it is specific to this industry.

An off-chain agent failure costs a few thousand tokens and a retry. An on-chain agent failure costs one of two things. A reverted transaction burns gas with nothing to show for it — the cost is small and bounded. A transaction that succeeds but is wrong moves principal — the cost is unbounded and permanent. There is no revert for a wrong swap. There is no undo for a wrong collateral deposit. The chain does not have a trash can.

So the value of the review layer is not proportional to the size of the task. It is proportional to the notional at risk. Those are different variables with different distributions. Inference cost scales with tokens. Review value scales with exposure. Any product that prices the first and not the second is mispricing its own risk transfer, and it is doing so systematically in the direction of undercharging the customers who need it most.

A note-taking agent and a treasury-rebalancing agent both pay the same thirty dollars a seat. One of them has ten million dollars of downside. The abstraction leaks, and we measure the loss.

The exposure term nobody amortizes

Let me put a number on it, because the structural argument only lands when it is denominated.

Take an agent that rebalances a $10M stablecoin position across three venues. Assume a per-step error rate of 2% and a six-step execution path, giving roughly 88.6% end-to-end success. Assume a review step that costs $40 in reviewer time and catches 85% of would-be failures. The expected loss without review, if a bad execution costs 1.5% of notional in slippage and misallocation, is:

E[loss_no_review]  = 0.114 × 0.015 × 10,000,000 = $17,100 per task
E[loss_with_review] = 0.114 × 0.15 × 0.015 × 10,000,000 = $2,565
review_cost         = $40

net_value_of_review = 17,100 - 2,565 - 40 = $14,495 per task ```

Fourteen thousand dollars of value per task, created by a forty-dollar review. The ratio is 362 to 1. Now run the same arithmetic on a $50,000 position with a five-dollar review. The expected loss avoided is roughly $72, the review costs $5, and the ratio is 14 to 1. Same architecture. Same software. Twenty-six times less value per review.

This is why review cannot be priced per seat and why the vendor's cost reduction is not the customer's cost reduction. The variable that determines whether the gate is worth building is exposure, and exposure is the one variable the vendor cannot observe.

There is a second unamortized term that the marketing data hides: persistent execution. A 24-hour agent that holds state across sessions pays for context maintenance, periodic polling, and error recovery on every tick, not on every task. The compute cost of persistence is not a multiple of the compute cost of a single call — it is a different cost curve entirely, and it is not in the 90% figure. The vendor's reduction was achieved by routing simple tasks to small models. The routing decision is made by a model. The routing model is a guardrail by another name.

Auditing model A with model B is a correlated bet

The guardrail architecture has a defect that almost nobody quantifies: correlation.

The standard justification for a guardrail is independence. If the actor fails with probability p1 and the guard fails to catch it with probability p2, the residual failure rate is p1 × p2, which is tiny. This argument is only valid if the two failures are independent events.

They are not. The guard and the actor are usually the same base model family, often the same checkpoint with different prompting, frequently the same tokenizer and the same training distribution. When they are, a prompt that fools one tends to fool the other. The failures are correlated, and the product formula collapses.

p_residual = p1 × p2 + ρ × sqrt(p1 × p2 × (1 - p1) × (1 - p2))

at p1 = 0.10, p2 = 0.05: ρ = 0.0 -> p_residual ≈ 0.0050 ρ = 0.3 -> p_residual ≈ 0.0241 ρ = 0.6 -> p_residual ≈ 0.0432 ```

An eight-fold difference in residual risk from a single unmeasured parameter. Every vendor shipping independent model review is quoting the ρ = 0 number without disclosing ρ. In my audit work I have never seen a vendor publish it. It is the most important number in the architecture and it is the least reported.

I have seen this failure mode before, in a different disguise. When I audited a ZK-SNARK proving system in 2022, the security argument rested on the trusted setup being independent of the prover. It was, formally. But both the prover and the verifier consumed parameters generated in the same ceremony, and a single compromised contribution would have compromised both sides of the check. The dependency was real, it was documented nowhere, and it took four months of reading circuit constraints to find it. Metadata is memory, but code is truth. The same holds here: the vendor's claim of independence is metadata. The base model weights are the code.

The practical test is cheap and almost nobody runs it. Take the adversarial inputs that break the actor and feed them to the guard. If the guard's detection rate on that set is materially lower than its detection rate on randomly sampled inputs, you have measured ρ, and you have measured it the only way that matters.

function measure_correlation(actor, guard, probes, random_set):
    adv_detect  = mean(guard.flag(x) for x in probes if actor_fails(actor, x))
    rand_detect = mean(guard.flag(x) for x in random_set)
    return adv_detect / rand_detect   # < 0.7 means correlated failure

A ratio below 0.7 should invalidate the guardrail claim in any procurement review. I have not seen it applied once.

The on-chain bill for review latency

Here is where this stops being an AI essay and becomes a market brief. The review tax is already line-itemed in this stack. It is paid in five places, and each has a number.

The fraud-proof window. Seven days is a human review deadline written as a constant. During that window, bridged capital is locked and cannot be redeployed. On a $50M bridge earning 5% in its native venue, seven days of lock costs roughly $48,000 per dispute event, and it is paid by depositors, not by the operator who chose the constant.

The governance timelock. Forty-eight hours on an admin function is a human gate. The cost is the option value of the delay — measurable, and rarely measured.

The oracle deviation threshold. A 0.5% deviation band with a heartbeat is a review trigger: the protocol is saying a human-equivalent process must confirm any move beyond this bound. Set it wide and you save on updates; set it narrow and you pay in gas and in update frequency. That trade is a review-cost trade wearing an oracle costume.

Keeper simulation budgets. Simulate-then-send doubles RPC cost per action. At scale, that is the single largest line item in most keeper operators' infrastructure bills, and it exists purely to catch a failure before it becomes a transaction.

Forced-inclusion and escape-hatch windows on L2s. The window during which a user can exit without the sequencer is the protocol admitting that the sequencer is not trusted to act alone. It is a gate. Its width is a cost parameter disguised as a safety parameter.

| Review primitive | Mechanism | Who pays | Typical magnitude | |---|---|---|---| | Fraud-proof window | 7-day challenge period | Bridged depositors | ~$48k per $50M dispute | | Governance timelock | 48h admin delay | Token holders | Option value of delay | | Oracle deviation band | 0.5% trigger | Protocol treasury | Gas × update frequency | | Keeper simulation | Simulate-then-send | Keeper operator | ~2× RPC cost per action | | L2 forced inclusion | 24h–7d exit | Users in flight | Locked liquidity |

Each of these is a review mechanism. Each has a price. None of them appear under the word review in any documentation I have read. Friction reveals the hidden dependencies, and the friction here is measured in blocks.

Now the part that should worry anyone holding application-layer tokens. If review cost scales with exposure rather than with usage, then the marginal cost of serving a large customer is not near zero. The SaaS valuation model assumes marginal cost approaches zero at scale. For an agent product with real exposure, marginal cost includes a review term that grows with the customer's notional. That is a structurally different business, and it deserves a structurally different multiple.

The audit trail problem: where do the review logs live

There is a second-order failure here that I have seen before, in a different asset class, and it is being repeated right now.

A review that leaves no durable record is not a review. It is a conversation. If the guardrail verdict, the approver identity, the timestamp, and the reasoning live in a vendor's object storage bucket, then the audit trail has the same integrity properties as a press release.

In 2021 I traced the metadata path of an ERC-721 derivative project and found that the images were not on-chain at all — they were served from a backend that was one DNS hijack away from pointing somewhere else. The token was immutable. The thing the token pointed at was not. The team froze trading and migrated to IPFS, which was the right call, and it took four days.

Review logs have the same shape and a worse consequence. The token metadata failure was cosmetic. A review-log failure is evidentiary: the entire accountability claim rests on a record that a vendor can edit, lose, or delete. If the log is mutable, the signature is mutable, and a mutable signature is not accountability.

I score projects on a Storage Integrity dimension for exactly this reason. A review system that stores verdicts on a centralized endpoint scores the same as an NFT whose image lives on a single server: the architecture is centralized, the marketing is not, and the gap is where the loss happens.

The DA narrative is looking for demand in the wrong place

I will be blunt about the adjacent claim, because it is circulating again.

The argument goes: agent economies generate enormous volumes of verifiable logs — every plan, every guardrail verdict, every approval, every rejection — and that data needs a data availability layer. Therefore agents are the next DA demand driver.

Run the numbers. A million agent actions a day at two kilobytes of log per action is two gigabytes a day, roughly 730 GB a year. Ethereum's blob capacity alone is about 16 GB per day at target parameters. Agent logs fit inside a rounding error of existing capacity. Even at a hundred million actions a day — a figure no deployed system is within two orders of magnitude of — you are at 200 GB a day, which is a fraction of one chain's blob throughput.

Ninety-nine percent of rollups do not generate enough data to justify dedicated DA. That was true before agents and it is true after them. The DA narrative is a supply-side story in search of a demand curve, and agent logs are not the demand curve. The actual constraint on agent economies is not where to put the logs. It is who reads them, and how fast, and at what liability.

The pricing function cannot hold the variable

Here is the structural reason review is priced at zero, stated as a function rather than an accusation.

Every pricing model needs a variable it can observe at the point of sale. Subscription pricing observes seats. Usage pricing observes tokens. Both are measurable before the contract is signed. Review load is not. It depends on the customer's risk tolerance, the domain, the model's error distribution on that specific task, and the regulator's mood. It is not observable at sale, and it is not stable after sale.

price_seat   = f(seats)                     # observable at sale
price_usage  = g(tokens)                    # observable at sale
actual_cost  = g(tokens) + h(exposure, p_err, review_rate)

# vendor books g. customer books h. h is the load-bearing term. # h/g diverges as exposure grows. no static price can close the gap. ```

So vendors price the observable variable and externalize the unobservable one. This is not malice. It is what any pricing function does when handed a variable it cannot measure. It substitutes a proxy.

I have watched this exact substitution fail in DeFi for six years. The utilization-based interest rate models in Aave and Compound are the cleanest example in this industry. They take an observable proxy — the ratio of borrowed to supplied capital — and map it through a piecewise curve with a kink, and the output is called an interest rate. It is not a price discovered from supply and demand. It is a shape someone chose, tuned until liquidations stopped being embarrassing, and then frozen into an immutable contract. The proxy works in the middle of its range and fails at the edges, which is precisely where the money is.

Review pricing is the same failure with a different proxy. Utilization stands in for real demand. Tokens stand in for real cost. Both proxies are stable in the normal case and both break in the tail, and the tail is where the losses live. The interest rate model does not know what money is worth. The subscription price does not know what a mistake costs. Neither can be fixed by tuning the curve, because the curve was never measuring the thing.

The seven-day window is a regulatory primitive

In 2022 I spent four months inside the dispute resolution contract of an optimistic rollup, mapping the fraud-proof window mechanics. I found a race condition: under a specific ordering of challenge and resolution calls, a malicious actor could extend a dispute indefinitely and freeze the disputed funds for a full seven days past the intended resolution. The report was cited by three security firms. The fix was a state machine constraint, not a parameter change.

What I understood only afterwards is that I had been auditing a regulatory instrument. The seven-day window is the same primitive that Colorado's automated decision-making rules reach for when they require a human reviewer with actual authority to approve, modify, or overturn an automated decision within forty-five days. Both are bounded windows in which an independent party with standing can reverse a machine's output. Both convert a technical claim — the system is correct — into a procedural one: someone with authority looked at it and did not object.

The difference is the cost structure. The rollup version is cheap because it is permissionless and bonded: anyone can challenge, and the bond prices the credibility of the challenge. The regulatory version is expensive because it is credentialed and audited: the reviewer must be independent, documented, and legally liable. Forty-five days of credentialed review per decision does not scale to a million decisions a day. It does not scale to a thousand.

Which means the compliance layer will be implemented as an attestation layer, not as a headcount layer. Someone will build the on-chain equivalent of the bonded challenger for regulated review: a staked reviewer set, a challenge period, slashing for rubber-stamping, and an attestation registry a regulator can query. That is the product the regulation is accidentally ordering, and nobody has shipped it.

This is also where the review-as-a-service market becomes legible. Not we will review your AI outputs as a consulting engagement. Review as an infrastructure primitive with three properties: it is priced per unit of exposure rather than per unit of usage, it is auditable by a third party without access to the underlying data, and it carries slashing risk for the reviewer. Every one of those properties already exists in this stack. We built them for bridges and oracles. We have not pointed them at agents.

What the tape is mispricing

Three signals are worth watching, and none of them are the ones the commentary is tracking.

The first is disclosure. No vendor will publish its review load — the number of agent actions requiring human intervention per thousand — because that number is the honest measure of how autonomous the product actually is. If a vendor publishes it, that is a signal of genuine confidence and it should re-rate the product upward. If the number stays hidden for another four quarters, assume it is bad.

The second is the verifier replacement rate. The review layer is being automated from below by critic models and verifier models — the same architecture as a guardrail, but trained specifically to find errors rather than to be generally capable. If that replacement rate crosses roughly seventy percent, human review stops being a rigid cost and becomes a transitional one, and the entire bear case inverts. Nobody has published a credible measurement of this rate. The reason is that measuring it requires a labeled set of agent errors, and only the vendors have one.

The third is the talent wall. Skilled review requires domain competence — code review requires reading code, financial review requires understanding collateral mechanics. That supply is inelastic on a multi-year timescale. If autonomy scales faster than reviewer supply, the constraint on agent deployment becomes people, not GPUs. That is a different growth curve for the whole sector, and it is flatter than the current one being priced.

The contrarian read: the gate is not the problem, the signature is

The obvious conclusion is that the review layer is a cost to be engineered away. I think that conclusion is wrong, and I think the reason it is wrong is the most important thing in this analysis.

The gate is not there to catch errors. The gate is there to produce a signature. In every system that moves value, accountability requires an identifiable party who could have said no. The seven-day window, the timelock, the bonded challenger, the forty-five-day reviewer — these are all signature-producing mechanisms. Their cost is the cost of having someone to blame, formalized.

And here is the blind spot that neither the vendors nor the regulators have priced: the signature degrades under load. Human reviewers exhibit automation bias. Under time pressure, they defer to the machine's output, and the signature becomes a rubber stamp — an accountability artifact with no entropy behind it. A forty-five-day deadline looks generous until you divide it by the case volume, and then it is four minutes. Four minutes is not review. Four minutes is a click.

So the system ends up with the cost of the gate and none of the safety, which is the worst of both equilibria. The fix is not fewer gates. It is gates that are priced, sampled, and slashed — where a reviewer who rubber-stamps loses a bond, and where the review itself is auditable after the fact. We know how to build that. It is a staking contract with a challenge period. Precision is the only reliable currency, and a signature without sampling is not precision.

Reverting to first principles to find the break: the break is not that humans are in the loop. The break is that the loop has no measurement. An unmeasured gate is a cost with no corresponding safety, and that is the definition of a tax.

Takeaway

Watch three numbers over the next four quarters: published review load per thousand agent actions, the verifier replacement rate against a labeled error set, and the first staked review primitive with slashing. The first tells you how autonomous the products actually are. The second tells you whether the review tax is permanent or transitional. The third tells you who captures it.

The question worth sitting with is not whether agents can be trusted to act alone. It is whether anyone will ever be willing to publish the number that answers it — because the moment that number is public, the pricing model that depends on it staying private stops working.