There's a table in my production database I've been avoiding looking at.
I run OrgX on itself. Every artifact my agents produce gets judged by a four-lens verifier — judged + measured + observed + outcome — and every episode of agent work writes a receipt. As of this morning, July 29: 3,328 execution receipts, going back to March 14. Months of real work, real verdicts.
The acceptance ledger sitting next to those receipts has one row. One. And that's an improvement — the table has only existed since July 25th. Before that the number was zero because I hadn't built it.
So for four months I was grading everything and learning nothing. A verdict that never touches human acceptance or downstream outcome isn't learning — it's grading homework nobody turns in. I was supervising the process with no idea whether the process was worth supervising.
I'm telling you this because Braintrust and Basis just published something that walks straight up to this exact wall, and I think the whole ecosystem is about to hit it together.
What they shipped
Behavior specs — Ankur Goyal and Mitchell Troyanovsky's announcement, open format at agentbehavior.dev. A behavior spec is a sparse markdown standard for how an agent should conduct itself during long-horizon work. Their example, validate-rendered-deck: a presentation agent has to render the current deck, actually look at the render, fix what's broken, and render again before it's allowed to claim the deck is validated. Then a judge grades every relevant trajectory against the spec: true, false, or NA.
Not "did the output score well." Did the agent work the way we've learned agents need to work here.
This is a real step. Taste used to live in a buried system prompt and in the memory of whoever wrote it. Now it's a file — versioned, diffable, testable. Organizational taste becomes testable. I'm not being polite, this matters, and the .agents/behaviors/ convention is exactly the kind of boring, adoptable format that wins.
But there's a sentence near the end of their post that I haven't been able to put down. They say it themselves: "a behavior spec is an opinion, formed from experience" — an opinion about how the agent should work. The judge can tell you whether the agent followed the opinion. It cannot tell you whether the opinion was any good.
That sentence is my empty ledger, right? I had the judges. I had months of verdicts. What I didn't have was the record of what happened after the verdict — what a human accepted, what got rejected, what the work turned out to be worth. The part that judges the standard itself.
How agents actually fail
Long-horizon agents almost never fail in one catastrophic moment. They fail through a chain of individually plausible decisions.
The source was relevant but stale. The agent inspected the render, then edited, then delivered without inspecting the new version. It solved the requested problem while touching a system nobody authorized. It produced the right output at ten times the reasonable cost. It followed the documented process perfectly and the human took one look and said no, that's not what I needed.
The result can look correct while the work was reckless. The process can look disciplined while the result was worthless. I've had both in the same week.
Behavior specs attack this exactly right: write down the recurring behaviors, judge every trajectory. But look at what happens the moment you try to act on a passing verdict.
Suppose the presentation agent earns a true on validate-rendered-deck. Render, inspect, fix, render again — the judge is correct, the behavior occurred. And the deck it delivered isn't the version it inspected. Or its delegated authority expired two hours before delivery. Or it pulled restricted customer data into the slides. Or it spent $912 on a $20 task. Or the person who asked for the deck rejected it anyway, because the deck didn't solve the actual communication problem.
The behavior verdict is still true in every one of those cases. The agent did exhibit the behavior.
Now think about where this ecosystem is headed: rewarding agents on judged behavior. Reward on the behavior verdict alone and you train the agent to perform the visible process. Reward on outcome alone and you train it to shortcut approvals, hide uncertainty, touch things nobody authorized. Acting on a verdict — routing more work to an agent, widening its autonomy, raising a spending limit, releasing a payment, admitting an episode into a training set — needs the whole episode: behavior adherence + valid authority + artifact identity + evidence + cost + human acceptance + outcome.
A spec is a rule. A verdict is a grade. Neither one is a record.
Six primitives
Here's the frame I keep coming back to. Agent work keeps getting flattened into "the trace" or "the eval," and it's actually six distinct things, each answering a question the others can't:
| Primitive | The question it answers |
|---|---|
| Task | What was the agent asked to do? |
| Behavior spec | How should it behave while doing it? |
| Trace | What actually happened, event by event? |
| Evaluation | Did the trajectory satisfy the spec? |
| Work receipt | What can someone else rely on about this completed episode? |
| Work ledger | What has the organization learned across many episodes? |
Nobody has to own the whole column. Behavior specs just gave the second row a real format. Runtimes already emit the third. Braintrust judges the fourth. I build the fifth and sixth, and the fifth is the seam where the others meet.
A trace is for debugging and replay — hundreds of turns, expensive to retain, often too sensitive to hand to anyone. A work receipt is the bounded claim you give another party so they can decide whether to accept, merge, deploy, pay, or grant more autonomy. It points at the trace. It doesn't drag it along.
What a receipt is
Agent Work Receipt v0.1 is twelve required episode records — intent, actor, authority, actions, artifacts, evidence, outcome, verification, cost, lineage, human_interventions, timestamps — plus the schema version and receipt id. Apache-2.0, no account, no proprietary IDs: every cross-system pointer is an opaque {system, type, id} reference owned by whoever produced it. Git, GitHub, MCP, OTel, whatever you already run.
And it deliberately refuses to hand you one aggregate "valid ✓". Content equality, cryptographic validity, and signer trust are reported separately — because collapsing those three into one green checkmark is how you get fooled. What the producer claims, what evidence backs it, what independent checks ran, what a human accepted: separate questions, kept separate on purpose.
The crosswalk — shipped, not promised
I didn't want this to be commentary, so the interop convention is in the repo now, with a fixture that passes the v0.1 validator. A behavior-spec verdict drops into a receipt like this:
| Behavior spec world | Where it lands in the receipt |
|---|---|
The spec (frontmatter name, pinned by producer revision + digest of the exact BEHAVIOR.md bytes) | An evaluated_against lineage edge |
| The judged trajectory | A trace lineage reference |
| The judge | verification.verifier — a named actor, not an anonymous score |
| The judge's rationale | An evidence record backing the check |
true / false | A verification check: passed / failed |
NA | skipped when not_applicable — but inconclusive when the native na_reason is insufficient_evidence or behavior_not_judgeable, because "didn't apply" and "couldn't tell" are different facts |
That last row is the kind of thing you only find by actually implementing the mapping. Their reference judge distinguishes three NA reasons. A receipt that collapses them throws away exactly the distinction a consumer needs.
And then the receipt wraps the verdict in everything it can't see: who granted authority and whether it was still valid, the content hash of the artifact actually delivered, what the episode cost, where a human grabbed the wheel, whether anyone accepted the result.
No standard has to eat the other. Basis runs the work. Braintrust judges the trajectory. The receipt binds the verdict to the episode. The ledger accumulates episodes until you can ask the question the judge can't answer: does adherence to this spec correlate with work people accept? If it doesn't, reopen the opinion — maybe the spec is wrong, maybe it's watching the wrong boundary, maybe it was right and something else failed. The ledger doesn't hand you the diagnosis. It hands you the evidence for the next revision, which is more than any spec can do for itself.
Behavior specs make organizational taste testable. Work receipts make it cumulative.
The scarce data isn't traces
One more thing and then I'll stop. Raw trajectories are multiplying fast — every runtime emits them — but they're expensive to retain and usually too sensitive to share, and none of that makes them the asset.
The scarce thing is judgment crossing a boundary. What your org permitted. What evidence it trusted. What it accepted, what it rejected, where a human intervened, whether the work mattered a month later. That data doesn't exist on the public internet and can't be scraped into existence. It only exists if you write it down at the moment it happens, in a format someone else can rely on later.
That's what a receipt is for. My ledger has one acceptance row today. The point is that the next thousand have somewhere to land.
Everything's live: the spec (Apache-2.0, account-free), the crosswalk, the fixture built on validate-rendered-deck and passing the conformance suite. If you're emitting behavior verdicts, run one through the mapping and file the first mismatch — I want the ugly case before v0.2. Start with NA. I bet there's a fourth reason.