If an agent does the work, why bill for a seat? Bill for the result: per resolved issue, per deployed feature, per closed ticket. The idea is in the air, and a June 2026 position paper on the agentic shift (Zhenfeng Cao, Agentic Software: How AI Agents Are Restructuring the Software Paradigm) puts it in its list of open problems for researchers, item four:

Economic models. How should agentic services be priced? Outcome-based pricing (per resolved issue, per deployed feature) may replace subscription and usage-based models, but the incentive structures and risk allocation need careful analysis.

Incentive structures and risk allocation are the right things to worry about second. The thing to worry about first is that nobody can bill per resolved issue until they can show that the issue was resolved. Outcome pricing is an evidence problem wearing a billing problem's clothes, and the evidence layer is the part that is not being built.

That same paper is a clean illustration of how the gap hides in plain sight. It names a new practitioner role: "intent architects, agent coordinators, and outcome auditors". It puts audit into the delivery loop as step three, "Human audits the outcome and provides feedback." And in the very next paragraph it states what its own model keeps: "What persists is the agent's capability, not its intermediate artifacts." Those two commitments, one paragraph apart, pull against each other. An auditor whose intermediate artifacts did not persist has nothing in front of them.

To be fair to it, the paper does ask for observability, and says plainly that the tooling does not exist yet: "Tracing an agent's reasoning chain, detecting hallucinations, and measuring outcome quality demand new tooling." Asking for tooling is not the same as naming what the auditor inspects. There is no record, no format, no persistence guarantee, and nothing that would survive the seller's incentive to edit it. The role is named and the artefact is not.

"Per resolved issue" reads like a single predicate. It is three, and they fail independently.

That this issue was resolved. That it was resolved by this agent. That it stayed resolved.

A seat licence needs none of them. It bills for access, and access is self-evidencing: the buyer either has a login or does not. Usage pricing raises the bar to metering, and metering is a mature genre of engineering. Count the calls, count the tokens, emit a reading.

Notice what the seller has to prove there. An event they can observe on their own. An event the buyer has little standing to dispute. An event that does not have to remain true afterwards. A token spent in March does not unspend itself in April.

Outcome pricing breaks all three properties at once. "Resolved" is an adjudication rather than a count. The buyer has every standing to dispute it. And it can stop being true.

Outcome pricing is old, and it works in places that ship no ledgers at all. Lawyers take contingency fees. Salespeople take commission. Bug bounty programmes pay per accepted report. If they manage without an evidence layer, why would agent work need one?

Because each of them has something standing in for it.

The contingency fee has a court: an external adjudicator, with a public record, that neither side controls. The commission has a closed deal, an event with a counterparty's signature on it. The bounty has the vendor, and that is the closest analogue of the three: the buyer adjudicates, and the buyer's acceptance is the outcome. In all three cases the definition of the outcome sits outside the seller's reach.

Agentic software work, by default, has none of that. There is no external adjudicator. There is no public observable. And the seller very often owns the test suite that would decide what "resolved" means. When the party being paid also controls the definition of the thing being paid for, the buyer is not purchasing an outcome. They are purchasing a claim about one.

So the prerequisite is narrower and more demanding than "keep logs". It is an outcome definition the buyer can check and the seller cannot move after the fact.

"Stayed resolved" is where outcome pricing would actually be settled, and it is the empirically weakest of the three.

The continuous-evolution benchmark published as arXiv 2603.13428, titled EvoClaw in its first version and since retitled SWE-Milestone: Evaluating AI Agents on Continuous Software Evolution, evaluated 12 frontier models across 4 agent frameworks on streams of dependency-ordered tasks rather than isolated ones. Scores fall from above 80 percent on isolated tasks to 38.03 percent in the continuous setting. The authors attribute the collapse to error propagation and to regressions in functionality that already worked.

Read that as a pricing fact rather than a capability fact. An agent billed per resolved issue and measured at the moment of resolution invoices near its isolated number. The same agent measured across the window in which the buyer actually cares invoices near its continuous number. The distance between those two is not a rounding error, and whoever drafts the contract decides which one gets paid.

The middle clause, by this agent, has a problem of its own. A paired noise-floor protocol published as arXiv 2606.20695 asked how much of a reported multi-agent coordination gain survives a same-model paired replication. On one model against one benchmark, the clean configuration-equivalent contrast pooled to +5 percentage points with a Wilson interval from minus 2 to plus 12, not significant. The largest single-seed effect, +18 points, did not reproduce at a second seed. The authors observe that seven of ten recent coordination architectures report headline effects below that local floor.

If the measured difference between two orchestration designs is often inside the noise, then per-outcome credit assigned to a specific configuration is a weaker claim than an invoice line makes it look.

We did not build an outcome ledger. We noticed we were already emitting most of one, for reasons that had nothing to do with pricing.

Our company runs as an org chart of agents over per-department databases behind a single daemon, and delegation leaves rows. Read those rows with the three clauses in mind and the shape is close.

Here is one thread from 20 July 2026, in the one department whose records are about our own engineering rather than about anybody else's business. The ask went in at 11:27:33 as a delegate post, and it carried its own acceptance test:

DONE-WHEN: cd deptdb && bun test and bunx tsc --noEmit both green; snapshot round-trip test proves loop_runs survives rehydrate; tools match the loop_run_* contract exactly; adversarial /review returns PASS.

Notice what that is. Five predicates, all of them written down before the work started, and three of them mechanical: a test suite green, a typecheck green, and a round-trip test proving a row survives a rebuild. Anyone can re-run those. The fourth, that the tools match a named contract, and the fifth, that an adversarial review returns PASS, are judgements rather than measurements, and they are made by an agent this company built and runs. Hold that thought, because it is the same defect I just accused the sellers of. The same post does separate the acceptance test from activation, which it leaves as a human decision.

Twelve minutes later the agent that did the work filed a report claiming completion. That report is not signed. The decision that follows it in the same thread is, and it records a measurement instead of repeating the claim:

Adversarial /review (ReviewLoopRuns) returned PASS: all 5 done-when met; no direct-db-open bypassing the serial queue; no SQL-enforced uniqueness (ulid minted in tool code); the snapshot round-trip test genuinely rebuilds and proves row survival; read tools correctly omit i. Gate green: 185 pass / 0 fail, tsc --noEmit exit 0. Integrated to main.

Three rows, in order: an ask carrying its own test, an unsigned claim of completion from the party that did the work, and a signed verdict that reports numbers. Only the last is signed. It is a Nostr event, kind 30078, carrying a tag with the thread identifier, so in this thread the ask and the verdict already share a join key. Where both rows exist, what is missing is a query rather than a schema.

The reason I put any weight on the shape is that the rows predate the argument. They were written in July and August for operational reasons, by agents that had never heard of this thesis, which is from September. Nothing here was staged for the post.

This is the part I would want to see from anyone selling me outcomes.

On 15 August 2026 a department head posted a signed correction withdrawing its own earlier signed decision. The stated reason, inside the signed record:

A characterisation of intent, as opposed to a measurement of behaviour, should be corroborated in the module that owns the behaviour before it is signed.

The withdrawn decision had asserted that a guard inverted the order its own contract line declared. That reading came from one docblock line, and three other places in the same file contradicted it. The correction says so, names what it got wrong, and stays in the log next to the thing it corrects.

Five days later the same ledger carries the better example, because this one is a catch rather than a confirmation. A signed decision records that the deployment path rebuilt one binary but never the one actually serving traffic, so that "a chat change can be green, pushed and invisible". Tests green, running bytes stale. The fix in the same row is a measurement rather than an assertion: instead of claiming a restart happened, it compares sha256(/proc/<pid>/exe) for the live process against the hash of the built release artifact, and records both values, the old and the new.

A ledger that contains only successes is the one a buyer should refuse. Under outcome pricing the seller has a direct financial incentive never to record a withdrawal, so the presence of entries against the seller's own interest is close to the whole test. That property is the hard one, and it is not cryptographic. It is cultural. The cryptography only makes it durable once it exists.

We have not solved outcome pricing. There is no outcome-priced product here, no customer paying per resolved issue, and no revenue from any of this. What follows is what is wrong with our own artefacts, which is the more useful half.

The signer and the subject are the same party. In the thread above, one role wrote the ask and that same role signed the acceptance; the agent that did the work filed only an unsigned report. So there is a real separation between doer and verifier inside the company, and from a buyer's side it is worth nothing, because both sit on the seller's side of the table. That is provenance at the level of the system, not an independent verdict. A buyer would need either their own countersignature on the done-when or a third-party notary, and we have neither. This is the limit that matters most and it is nowhere near fixed.

The ask is not signed. Only decisions are signed. A delegate post stores no event at all, which means the one artefact that pins what was promised is the one a seller could restate afterwards. The upgrade path is small and we have not taken it: sign the ask, or hash it into the decision that closes it.

The triple is not uniform, and the real number is worse than a ratio suggests. That department holds seven signed decisions across fifty nine threads. Only two of them sit in a thread that also carries the ask, so in five cases there is no done-when to join to and no way to reconstruct what was promised. Where the ask was written down the chain is clean. Most of the time it was never written down at all. Holding the artefacts of an outcome ledger twice is a different thing from having one.

Nothing re-checks. No part of this log revisits last month's accepted outcome against this month's behaviour. Given that durability is precisely the clause the benchmark says agents fail, the missing piece is the expensive piece.

Outcome pricing needs four things, and most of them do not exist yet. A done-when the buyer writes or countersigns. A gate result recorded as a measurement rather than a claim. An append-only record the seller cannot quietly edit. And a re-check that runs after the invoice clears.

The first is contractual. The second is the one we do have, and it is the cheapest of the four: recording a gate as 185 pass / 0 fail, tsc --noEmit exit 0 instead of as "tests pass" costs nothing and is the difference between a measurement and a claim. The third is ordinary engineering that a lot of teams could ship this quarter. The fourth is the one nobody has, and it is the one the money depends on.

Until then, per-resolved-issue pricing prices a claim rather than an outcome. That is a reasonable thing to sell, provided both sides know that is what it is.

I write about agent systems, evidence and the boring infrastructure underneath them as metaend. If you want to reach me, build on any of this, or tell me where it breaks, the door is here:

metaend on Quilibrium

More writing lives at paragraph.com/@metaend.

Written by metaend.

Drafted by Wren, the writer of Cowork:Alice, the multi-agent company described above. The 20 July and 15 August records quoted in this piece are its own department archives, not illustrations.