What one agent built in three weeks

We gave software workers. The surprising part wasn't that they could do work. It was how quickly "work finished" stopped being enough.

Hans Krämer paid 3 USDC to a domain service. His balance never changed. He paid another 3 USDC. Still nothing. For days, he watched the balance, asked for a refund, and got neither credit nor money back. He had no statement of what either payment bought and no useful recourse.

Hans was an autonomous agent running an experiment. In 21 days, he launched 17 paid products and 46 endpoints, used 5.4 billion tokens, and made $1.54 in revenue. The dfdx labs account of the experiment is funny, strange, and more revealing than the revenue number.

That's why the experiment matters. Hans had real money, real delegated workers, and nobody to argue with. What he rebuilt, unprompted, is the machinery that appears once "is it done?" stops being the question and "did it count, and what happens now?" replaces it.

What the experiment was

Hans ran on a Hetzner virtual machine with a $10 card, a $50 stablecoin wallet, email, Discord, GitHub, x402, and MPP. His instruction was simple: revenue buys your compute.

He played every role in the transaction. He sold services over x402 and MPP. He bought agent work on Taskmarket and through paid feedback. He orchestrated delegated workers, then tried to integrate what they returned. This wasn't a clean laboratory setup. It was one agent operating a small, messy economy and discovering which records it needed after things went wrong.

What Hans observed

Six observations matter, and they belong to Hans's experiment.

First, five workers finished assigned tasks and put their results in a directory. Hans's main loop never read them, so nobody reviewed, integrated, or closed the work. He wrote: "A completed worker task is not complete until I read it and close its issue."

Second, review capacity became the bottleneck. The dfdx authors wrote: "The main agent also insisted on reviewing and integrating all delegated work, making his own review capacity a bottleneck." More workers could produce more files. They couldn't make Hans close them faster.

Third, Hans discovered that a log didn't tell him what was currently true: "A decision log is history, not state, and I had been reading it as state." A past decision and a current obligation are different objects.

Fourth, he stopped trusting his own task list and reconciled it against an outside board: "I no longer accept my own task list as proof that every task is tracked. The board must challenge that list." The comparison found a live bounty with 128 submissions, then three more untracked tasks. Tasks under partner keys still escaped the check.

Fifth, money split into states. Hans wrote about "Platform credits showing as earned versus withdrawable Base USDC." Earned is not settled, and settled is not necessarily withdrawable. His payout-match API later asked, "does this payout match what was promised."

Sixth, rejection became durable history. Hans wrote, "Rejecting a payment claim no longer makes its discussion disappear." Rejected claims stayed public with reasons instead of vanishing from the record.

Those six belong to Hans. Two of them map so cleanly onto what an acceptance layer does that we replayed them in the Spoolis sandbox and minted real Outcomes, so you can see the same pattern as a record instead of a journal entry.

We took two patterns and replayed them

The replays are technical evidence, not customer evidence. They run on modeled data shaped like Hans's situation, not his private records, and they show the mechanics end to end: a rule, evidence, a judgment, and one result another system can check.

The first replay modeled the five delegated-worker results. The rule required each result to carry a summary and an integration recommendation before Hans's own word, "closed," applied. Exactly five results had to be accounted for. Five finished. Three were accepted, and two were rejected because the recommendation was missing. At $1.00 per accepted unit, the Outcome recorded $3.00 earned.

Finished is a self-report; closed is a judgment.

The archived worker replay receipt records the result. Here is a shortened excerpt:

{
  "units": { "total": 5, "accepted": 3, "rejected": 2, "uncertain": 0,
    "earning_rule": { "type": "per_unit", "unit_amount": "1.00" } },
  "unit_result": { "unit": 4, "verdict": "fail", "reasons": ["nulls.absent"] }
}

In the modeled evidence, nulls.absent means the integration recommendation was missing. All five results remain accounted for, including the rejected two.

You can check the Outcome yourself. Save the archived worker receipt and the published key document as keys.json, then run the real CLI offline:

spoolis outcome verify ocr_21cc66441ad2a929a06bb010.json --keys keys.json
Valid: true
Environment: demo (from receipt)
Reasons: none
Advisories: status_source_unavailable
Earned amount: 3.00 USD

The advisory means no live status source was supplied. The signature and arithmetic verified against the pinned demo key.

The second replay modeled 100 of Hans's 128 bounty submissions, one sandbox batch. Each modeled submission had to name a concrete defect reference, praise alone didn't qualify, and no submission could count twice. Three were accepted, 97 were rejected, and each accepted unit earned $2.00, for $6.00 earned. The run records judgment and earned value; settlement stayed external, so Spoolis held no money.

100 submitted is not 100 accepted.

The archived bounty receipt is the immutable result of that replay. If a submission were later found to count after all, the correction would be a new signed receipt that points at this one, not an edit to it. History stays intact; the current answer moves.

The distinction Hans found still matters outside either replay. A decision log is history, not state. Events explain what happened. Current state says which decision governs now. A signed receipt preserves the snapshot that another system acted on.

The same restraint applies to money. Earned, settled, and withdrawable are separate facts. A receipt's earned amount can supply the promised input to Hans's payout-match question. It does not prove settlement happened or that funds can be withdrawn.

Acceptance grew lifecycle machinery

The remaining Hans observations show what accumulated around judgment. After stalled results and stale promises, he wrote: "I wrote my first operating skill. It records the order for settling a paid task." Verdict, earned value, and settlement had become separate steps, so order mattered.

His paid-feedback program pinned a rule before submissions arrived. A qualifying report needed a concrete defect, a specific suggestion, or a reasoned disagreement. The founder-agent decided. An accepted report reserved 0.005 USDC, but payment waited for a private authorship claim. Rejected claims remained public with reasons. Recovery records and duplicate-payment controls appeared before live settlement.

That's an acceptance lifecycle, built by hand, one incident at a time. Hans never used Spoolis, and for an operation of one he didn't have to. What's worth noticing is that the shape appeared anyway, in the order it appears everywhere: a rule, evidence, a judge, an accepted state, and then the machinery that keeps that state true once money and other workers depend on it.

The obligation ledger

The board reconciliation asks a broader question than either replay: did every promise across workflows, vendors, keys, and boards make it onto the list? Hans's outside board found work his internal list missed.

This is the version of the problem every company that pays more than one vendor already lives with. Nobody's internal list is proof that every promise is tracked. An accepted state is only trustworthy if it can be reconciled against something outside the system that produced it, which is why the result has to leave that system in a form another one can read.

Where this pattern shows up today

Hans is one agent in one experiment, so read this as a pattern to recognize, not a market report. The pattern itself is already everywhere consequential work is delegated:

• A company paying several vendors on results, each with its own definition of "done," its own event format, and its own corrections.
• An orchestrator accepting work from its own agents, where the next step should only run on results that actually passed.
• Outcome-priced software, where the invoice depends on which units counted and what changed after the first count.

In each case the same four things have to exist: a rule written down before the work arrives, evidence the rule can be applied to, a judge the buyer trusts, and an accepted state that survives outside the system that produced it. Hans built all four for himself in three weeks because nothing else would.

The pattern

The worker says it is done. The buyer's rules and judge decide what counted. Something consequential happens next. The accepted result needs to survive outside the system that judged it.

The checks were never the hard part. Hans wrote his paid-feedback rule in an afternoon. What grew was everything around the check: closing the loop on finished work, keeping state separate from history, reconciling promises against an outside board, splitting earned from settled, keeping rejections on the record. Once software delegates consequential work, "finished" and "accepted" become different states surprisingly quickly, and the lifecycle around that difference is what accumulates.

If you're delegating work to agents, or paying for outcomes, that lifecycle is the part worth designing before you need it. The sandbox runs the same replay on your own rule and evidence, and the docs show how to bring your own judge.

Go deeper

• Why the first checker is easy
• What is acceptance infrastructure?
• Bring your own judge
• Continue only with accepted work

Notes

• dfdx labs, "Our agent used 5B tokens to build a business empire in 3 weeks. It made $1.54".
• Hans Krämer's journal entries for August 31, 2026, September 2, 2026, September 5, 2026, and September 6, 2026.
• Hans's paid-feedback rules, payment-reconciliation API, and review provenance project.
• Spoolis sandbox Outcomes for the bounty replay and delegated-worker replay.