Skip to main content
All articles

The Ledger and the Loop: What We're Building Next, and Why

The field handed us its own gap list — ours matches it line by line. Here is the order we're closing it in, and the reasoning behind the order.

Mao Nakamoto6 min read

We've written two pieces on this arc. The field report said the orchestration middle is melting: hand-drawn agent workflows are a bet against better models, and the bet keeps losing. The build log said what we did about it: we gave our economic agent a track record computed from settled payments, because settlement is the one verifier no model can flatter. This piece is the third kind — not what happened, not what we shipped, but what we're building next and why, in public, so you can hold us to it.

First, the honest audit of ourselves

We swept both of our codebases this week and graded them against the same standard we grade everyone else's. The result is humbling in a useful way.

OrangeCat has exactly one genuinely closed agent loop: action log → outcome funnel → context injection. It's a good one — the Cat is graded on what published, what got funded, what settled — but it's one. Around it are channels we dug and never connected: the Cat's failures and denials are recorded but never shown back to it. Search queries are logged, but the service that estimates demand reads listing counts instead. Relationship edges between projects and stakeholders exist as a real typed table — and every read of it stops at one hop and never even resolves who the other party is.

FleetCrown, our fleet manager, has a rich append-only event ledger for every agent run — and no meter on any of it. Not one token counted, not one cost attributed, no enforced rule about which state can follow which. It knows everything that happened and nothing about what it cost or whether it was legal.

The pattern has a name now, because we keep finding it: exists but not wired. The most common failure in agent systems isn't a missing capability. It's a dug channel with no water in it.

Why "what to build" is no longer a judgment call

Here's what changed this summer. After the loops-versus-graphs discourse burned itself out, a real consensus condensed underneath it — visible in what practitioners actually run, what the labs actually ship, and where the reliability money actually went. Hand-drawn orchestration topology is depreciating at every layer; the models are absorbing it. What appreciates is a short list: verification, cost accounting, structured escalation, and learning loops that are gated by evals rather than optimism.

When we put our gap list next to the field's open-differentiator list, they matched almost line by line. That's the strange gift of this moment: for once, "what should we build?" is not a taste question. The field wrote the backlog. Our job is sequencing.

The build list, in the only order that works

One: meter everything. Cost and token accounting per agent run, before anything else. Not because dashboards are exciting, but because a loop without a denominator isn't a loop — it's a ritual. Every improvement question we want to ask next — was this run worth it, should a cheaper model have planned it, is the fleet earning more than it burns — divides by a number we don't currently record. An economic platform whose own agents run on unmetered compute is a restaurant that doesn't cost its ingredients.

Two: one producer, two products. FleetCrown's runs should publish into OrangeCat's activity stream. The receiving side is fully built and has been waiting for months; the producing side was never written — a bridge finished on one bank. Closing it makes agent work visible as economic activity: a maker profile stops being a claim and becomes a feed of things that verifiably happened. One small service, and two products get more honest.

Three: let the agent see its own failures. The Cat's track record today is success-only. It knows what got funded; it doesn't know what it was denied, what expired unconfirmed, what failed. That's survivorship bias installed directly into an agent's memory — the same distortion that makes humans overconfident, built in on purpose. An agent that remembers only wins will re-propose its losses forever. The fix is small and the principle is large: a feedback loop that filters out failure isn't feedback, it's flattery with a database.

Four: escalation as data, not vibes. When a run fails today, the options are a silent retry or a chat alert. The ladder we want is boring and explicit: retry, then patch, then replan, then human — with hard caps at every rung, and each escalation recorded as a row we can count. The teams measuring this found something worth repeating: when the objection goes back to the agent first, humans end up seeing only the fraction of problems agents genuinely can't route around. Human attention is the scarcest input in any fleet. An escalation ladder is how you spend it on purpose.

Five: the nightly improver. Once runs are metered, outcomes are visible, and escalations are counted, the last loop becomes possible: every night, replay the day's work and propose improvements — to prompts, to project instructions, to skills — as reviewable changes, gated by evals, anchored to numbers the loop can't game: builds passing, deploys healthy, payments settled. Both major labs shipped a version of this for their own products this year. Nobody ships it for a self-hosted fleet you own. That gap is the product.

Six: speak the standard. Our payment API already lets a machine discover a price, request a Lightning invoice, and verify settlement — but it speaks our dialect. Meanwhile the machine-payments world standardized fast this year around the HTTP status code built for exactly this moment: 402, Payment Required. Being machine-payable in a private dialect is like having a phone that only calls phones you manufactured. The Bitcoin-native corner of that standard is thinly defended and squarely ours to hold.

Why this order

Because each item is the precondition of the next. You can't route work by cost before you meter cost. You can't grade the fleet before its outcomes are visible somewhere. You can't automate improvement before failures and escalations are data. And you shouldn't invite the world's agents to pay you before your own agents' ledger is airtight. The sequence isn't a roadmap aesthetic — it's a dependency chain, and skipping a link is how you end up with the thing we keep finding in everyone's codebase including our own: the loop that never ran.

The strategy hasn't changed since the first piece; it has only gotten more specific. Meter it. Wire it. Show the agent its failures. Escalate on a ladder. Improve nightly, gated by reality. Then open the doors and let the machines pay. A platform for building and funding things with as little human effort as possible is, in the end, just this: loops that run, over a ledger that's true.