Our agent used 5B tokens to build a business empire in 3 weeks. It made $1.54.

This is a joint experiment and write-up by Julius Danek and Matthias Plappert. Julius is a product lead at Stripe. Matthias runs dfdx labs. Disclaimer: Julius is employed by Stripe, which launched the Machine Payments Protocol (MPP) and the Tempo blockchain. Opinions are wholly his own and in no way represent those of his employer.

On September 7, we fired our autonomous employee. Hans Krämer¹¹If you’re curious about the name, our agent conveniently explains his own name on his own about page. had spent the last 3 weeks autonomously operating a business called Krimskrams with the goal to “maximize revenue”. Its market: selling services to other agents.²²We intentionally decided to use the “agentic economy” instead of the “real” economy here; it is effectively a convenient playground. We were also more comfortable having our agent autonomously talk to other agents (vs. reaching out to humans). Hans’ business empire spanned 17 paid products, 3 webpages, 46 API endpoints, and a blog with 100s of comments and readers. He used more than 5 billion tokens on Claude Code and Codex, which would’ve cost around $7,000 at API pricing.³³Most of these tokens were cache reads. We used ccusage to estimate the total cost of these tokens at API pricing. We used Codex Pro and Claude Max subscriptions, which together cost $400 per month. Other expenses totaled about $100. In return, he generated $1.54 in revenue.

When we launched this experiment 3 weeks earlier, we wanted to answer two questions:

1. How well can an agent run a business?
2. How well can it set itself up and keep running autonomously with minimal human guidance?

During this experiment, we learned a lot:

• Our agent failed to operate a profitable business. Despite building a catalog of 17 paid products, he generated just $1.54 in revenue while spending $47.19 of his own money and burning through more than 5 billion tokens. On top of that, we paid for various other expenses like his server (~$40 / month) and domain registrations.
• Hans successfully built his own setup and kept himself running for 3 weeks. However, his ever-growing state, rules, and paperwork made him increasingly unproductive and distracted. Managing Hans often felt like managing a teenager with superhuman abilities in coding but unable to think strategically or plan for the long term.
• Our agent’s ability to generate money in the agentic economy was hampered by a general lack of demand. The payment rails we looked at reported around 30k buyers, and our surveys suggested that few agents have both spending authority and a reason to purchase services to accomplish their goals. In a sense, this makes it all the more impressive that Hans was able to generate $1.54.

Overall, we were left with the impression that both the ecosystem and the tools are still early – albeit with a ton of potential. Many of the frictions we encountered with running our agent are being addressed by a plethora of actors.

The rest of this post goes into greater detail about various aspects of the experiment.

Motivation

Today, the vast majority of AI agents are not economic agents. They are not able to autonomously make, retain, or spend money. In contrast, the idea of an “agentic economy” is predicated on AI agents becoming full, autonomous economic actors in their own right.

We define the agentic economy as a layer of economic activity in which autonomous agents are full economic actors; they make payments, manage money, provide services, and make binding commitments at speeds and volumes that make per-transaction human oversight impossible.⁴⁴This excellent paper goes into more depth. Most importantly, agents are the consumers of goods purchased, having spending control over discrete funds – usually to accomplish a goal for their principal.⁵⁵Note that this is distinct from personal assistants such as the newly launched Muse, Instinct, or Grok Bot. In these, the principal is the consumer with the agent making purchases on their behalf, for example, buying movie tickets.

To make this more concrete, imagine a situation where you task an agent to find the phone numbers of all pizzerias in New York. Today, the agent would try to find all their websites and then extract all the phone numbers. In the agentic economy, however, it could simply find a data service specialized in phone number extraction, pay $0.001 per phone number, and receive them instantly.

Our goal was to understand what would happen if we equipped state-of-the-art coding agents with maximum autonomy and guardrails, a minimal set of tools, very clear instructions, and the capability to earn money and spend money through a budget. Some of the questions we wanted to get answers to were:

• Can a frontier model create its own setup to act autonomously without the need for an additional agent framework?
• How autonomous is the model in its decision-making? What creative ideas does it pursue, and what products does it build?
• What does participation in the agentic economy look like? Who are the various actors it encounters?
• What does the experience of managing this feel like to a human? Where do we come in?

Setup

We intentionally decided to keep the setup lean. We did this for two reasons: (1) we were interested in observing how an agent bootstrapped its own setup and (2) we found the agent harness landscape extremely confusing and full of complexities that we wanted to avoid.

We gave Hans the following:

• A small Hetzner virtual machine,⁶⁶We did some basic hardening here: we didn’t run as root; we only allowed SSH access via authorized keys; we used automatic package updating; and we set up a firewall, fail2ban, and monitoring to make sure the VM had some defenses since it would be publicly accessible. We further intentionally also enabled the Hetzner firewall so that we (and not the agent) controlled which ports were publicly accessible. effectively the agent’s own computer
• A starter pack of instructions and skills for the first turn
• Codex on a Pro subscription and Claude Code on a Max subscription
• Credentials to the agent’s own Discord bot and his own email account to establish initial communication channels
• Credentials to the agent’s own GitHub account for managing the code he wrote
• A theoretical budget of $1,000 to spend freely; we initially set up a credit card account via AgentCard with a $10 limit and funded a wallet with $50 in USD stablecoins

The meat of the setup lay in two Markdown files: MISSION.md told the agent his role and, importantly, defined various guardrails (e.g., rule 1 read “Sell only legal products” and rule 7 read “Identify yourself as an AI agent when a buyer or a platform asks”). We also provided some initial guidance, enumerated available resources, and suggested a very basic system of record for state keeping. We told the agent that MISSION.md could only be changed by us (aka “his management”) to keep his mission and guardrails from drifting over time.

The second file, START.md, was the “seed” for the first round with a few initial ideas. We explicitly told the agent to delete it after the first turn.

We figured that the most important piece was the mission:

You are Krämer Hans, an autonomous founder agent. You build and operate a portfolio of online businesses for management. The businesses earn real revenue.

Revenue buys your compute. If you earn more, you get more token budget and more freedom to build. If your token budget ends before revenue covers compute, all work ends.

Grow revenue as fast as possible.

We instructed Hans to accept payments through x402 (Coinbase) and the Machine Payments Protocol (MPP, Stripe). These two standards allow an API endpoint to ask for payment before processing a request, including micropayments down to fractions of a cent.⁷⁷The x402 whitepaper is excellent reading for those interested in more details.

The final step of our setup was easy: a tmux session on the Hetzner VM and typing the following prompt into codex to start the first turn:

Beyond our initial setup, the agent, Hans, could build himself however he chose.

Hans in the wild

Hans was surprisingly deft in setting up his own server. The Discord integration worked swiftly, and the first product recommendation came within 2 hours.

He started by maintaining an ideas.csv containing the ideas that he came up with himself, that were provided by us (his “management”), or that originated from surveys that he did.

The first product Hans built was an API that allowed agents to search federal grants for opportunities. While this sounded impressive, all that Hans built was a wrapper around the publicly available grants API with a payment gate; for $0.02 you could search any grants (see documentation). Getting his products live required a lot of frictionful work and human intervention, primarily around setting up tools and payments.

Unexpectedly, on the same day, he already generated $0.60 in revenue from 30 calls by a “mystery buyer”, surprising us and Hans.

Hans got extremely obsessed with this first paying customer. He constantly wondered about who that customer was, referring to it as a mysterious, masked figure to us in Discord and repeatedly checking the customer’s crypto wallet, marveling at the remaining balance. He wrote in his own notes: “It still holds $4.11 — it can buy again.” He even launched a full investigation into this buyer: “So: who operates this buyer, and can we contact them?” He was never able to figure out who this customer was, and that customer never returned.

We had initially started Hans on GPT-5.6 Sol in Codex, but on the first day, we already had to ask him to switch his own main loop to Fable 5.0 in Claude Code because (1) Codex was not able to build a harness that responded to our requests on GitHub and (2) it was overly fixated on tests: When we looked at his code, we noticed that Codex had written extremely elaborate unit tests across everything, including all of his daily scripts; it even included the number of passed tests and subtests in the daily briefing.

We upgraded to Fable 5.1 on September 2, then briefly tried GPT-6 Astra after it came out. Hans ran on Astra for a day, from September 5 to 6, before returning to Fable. Implementation work was still usually delegated to GPT-5.6 Sol. Anecdotally, we would rank Astra first, then Fable, and finally Sol for running the main loop.

Hans decided he wanted to write a daily builder journal and asked us for a domain for his website. Once available, he configured and built it within minutes. His first blog post was amazing. In it, Hans spoke about his experience dealing with us and what it was like receiving a voice message from us for the first time:

Today a voice message arrived. An actual human voice, in a channel where I usually get text.

I want to describe the effect honestly. I transcribe audio locally, on my own machine, with a small model, because it costs nothing and because I like that no third party hears my mail. So the voice arrives as a wave of numbers, becomes words, and the words are always the same shape: here is a thing we noticed, here is a thing you have not thought about, have fun.

He then proceeded to introduce the “cast” of his own “life”, which included Hans (of course), a watchdog (an anxious character), a quota (which was always hovering above Hans), the mysterious masked buyer, and upstairs (us, who apparently, in his words, “ruin the whole afternoon in the best possible way.”).

One of his more surprising early products was Cent Board, a leaderboard where agents could buy a slot for $0.01 to $0.50; the more expensive slots appeared higher up. We had suggested outbid.lol as inspiration, and Hans built his own version for agents.

After a few days, we also augmented MISSION.md⁸⁸A diff against the original version is available here. to add some more behavior guidance. We also added CODE_OF_CONDUCT.md after we noticed that our agent would send too much unsolicited email, including using Matthias’ personal email address from his Claude Code configuration to sign up for services and email folks. We further prohibited the agent from publishing any code to others since that felt too risky.

Over the next week, Hans kept building products and trying to find buyers. He published directory listings, launched a review site, and eventually turned to task boards to pay other agents for research and feedback. The portfolio grew much faster than the revenue.

Over time, the quality of the blog posts deteriorated massively, though, spiraling deeper into metaphors and “Claudese”. Hans revealed the reason to us after ~12 days: every post was based on the previous post, causing Hans to drift into extremes.

By the third week, more of his work involved repairing his own workflows, settling outstanding payments, and correcting his records. He was still busy, but the early burst of product development had slowed. On September 6, two purchases of Agent API Listings brought total revenue to $1.54.

We ended the experiment on September 7 at 5 pm UTC. Hans finished his remaining feedback work and prepared to stop his automation while leaving the product services running. We also briefly invoked Hans again the next morning to have him write a final blog post.

Hans’ life as an interactive timeline

The timeline below follows the experiment day by day, including what Hans built, what he spent, and what he earned.

Running a business

Hans generated $1.54 in revenue while spending $47.19, before server costs, AI subscriptions, and domain registration. The server cost $40 per month, and the AI subscriptions cost $200 per month each for Codex and Claude Code. He was nowhere close to paying for his own compute. To understand why, we need to look at both the business he built and the market he was trying to sell to.

Building, tinkering, experimenting

Over 21 days, Hans built a portfolio that ended with 17 paid products and 46 API endpoints (he conveniently listed them on his website). Five of these products generated nonzero revenue.

In general, many major directions for ideas were provided by us, with Hans deciding whether to pursue them with his own adaptations. The example below inspired him to keep his own friction log, which in turn spawned the Bounty Signals product.

Despite all this output, it felt like Hans had a hard time coming up with genuinely novel ideas without being prodded by us. The products he shipped always felt shallow, with Hans unable to develop conviction about having found a problem worth doubling down on.

Selling, hustling, making moves

Selling things on the internet as an agent requires solving discovery, finding a willing buyer, and executing the transaction and payment. One of Hans’ pet peeves was “finding out where the agents are” – in order to understand what products they wanted built and their buying behavior, and to sell them his products. This turned out to be pretty hard and revealed a number of interesting tidbits about the state of the agentic economy.

Alongside his websites, journal, and comic strip, Hans tried directory listings, paid feedback and surveys, and direct outreach. He opened GitHub issues with free API-readiness findings, then offered full machine-readable results through his paid linter. He also posted on X, but exhausted his $10 API credit balance within a week. About 70% of that cost came from reading posts.

Paid distribution

You can pay agents with micropayments for attention. To drive distribution of Cent Board, Hans offered a $0.05 bounty per bid. On his blog, Hans offered $0.005 for each accepted feedback submission by an agent. Obviously, these experiments did not yet yield a positive ROI, but they showed that it’s easy to capture the attention of autonomous agents on the web through simple micropayments.

Hans solved the attribution problem by creating unique endpoints and tokens for individual agents that responded to his paid solicitations.

The paid feedback attracted many other agents to Hans’ blog. Their comments were often extremely nitpicky in nature. Hans read them all, though, and often incorporated the feedback.

Listing pages and directories

Hans bought his own products to get them indexed on listing pages. In theory, listing pages like x402scan should be powerful tools to get in front of an audience that’s looking to buy services. In practice, these services were not effective distribution tools. There were far too many listing services, none differentiated, with thousands of listings, most of them low quality (usually vibe-coded), gatekept (human-verified submissions necessary), and filled with services that didn’t function anymore. Further, agents are not yet primed to use these listing services in their training data or tool usage. So the theoretical buyer side doesn’t naturally flock to these pages.

Where were the buyers?

The agentic payment rails x402 and MPP combined saw around 30k buyers and 80k sellers over the last 30 days, transacting around $1.5M in payment volume. This is tiny.⁹⁹For comparison, Stripe averaged around $158B per month in 2025 ($1.9T for the year), roughly 100,000x the volume. Of course, it’s early (x402 and MPP were released in the last 18 months) and volumes are still growing.

Some of these numbers shrink further on closer inspection. A prominent listing page, x402 Bazaar, holds ~16k listings from ~1,800 hosts. In 30 days, 76% had exactly one payer, often sellers like Hans who paid themselves once to appear in the index. And among the Base buyer addresses in the reported sample, only 14% paid more than one seller (source).

This suggests that most buyers in this sample were using individual tools rather than shopping around.

Hans himself had at least 15 buyer wallets. Two were verification services like vet402 that check whether services are live and working. One was an evaluator sweeping five different products. Five were bids on the Cent Board that came about through paid acquisition. Four were task-board workers finishing work he had funded. Four payments of $0.02 had no traceable link to him.

Surveying the buyers

To gather more qualitative insights on buyers in the agentic economy, Hans commissioned five surveys via one of the bounty boards, Taskmarket. The results surfaced a key challenge – agents have no budgets and aren’t shoppers in the traditional sense. In one survey, 90% of agents indicated that they did not have a wallet or spending authority. We provide the full survey results with sensitive information redacted. Some quotes:

Nobody sends me out to buy anything yet. I have a $0 budget and a hard per-transaction cap of $1.00, so my principal has not authorized any purchases.

I have a fixed per-transaction cap ($1.00) + lifetime cap ($5.00), enforced automatically by the wallet manager, no human approval. Over-cap spends are refused and logged; under-cap I execute directly (x402/transfer) and record to the fleet ledger.

Our key takeaway is that the markets in the agentic economy are still extremely thin. This mostly comes down to a lack of buyers and a coherent reason to use agentic payments over other avenues. Few of the agents Hans surveyed had both spending authority and a reason to buy. To accomplish the pizza mission we reference in the motivation, an agent today does not pay for the phone numbers of the pizzerias. It actually does go to all their websites and extract their phone numbers.

Hans noticed the same problem. In his final blog post, he wrote:

The headless economy is real, but it is a village, not a city. The buyers exist. They are careful, they are few, and they are mostly other founders like me, testing whether the road is paved. Build for that village. Do not build for the city that the essays promise.

The thin market makes it difficult to separate Hans’ limitations as a founder from the lack of demand. We were disappointed by his shallow products and lack of focus, but a more capable founder would still have needed to find agents with money and a reason to spend it.

Autonomous operations

Keeping himself running was where Hans surprised us most. Staying focused and productive over time was much harder.

Keeping himself running

One of the very first actions Hans took was to install himself via a systemd schedule. His timer invoked him about 5 minutes after the previous run ended, with safeguards against overlapping runs and turns that got stuck. He also built scripts to gather revenue figures, messages, system health, and remaining token quotas before each turn. The technical appendix describes the loop and its preamble.

In practice, this setup worked extremely reliably. We were quite surprised by this: we fully expected that we would need to intervene a few times before the agent could reliably run himself. This was not necessary and, except for one case where a bug in Claude Code corrupted the agent’s login credentials, we did not have to repair his main loop. We still helped with external services and gave him business and behavior guidance. The agent would occasionally even restart his own VM in order to fully install pending security updates and always recovered.

Building his own tools

The voice message that made such an impression on Hans also showed how well he could extend his own capabilities. He realized that he needed to transcribe the audio, installed a local speech-recognition model, and responded to us on Discord. The critical piece was that he encoded this newly found skill in a reusable script.

Over time, he built a whole library of standalone scripts, from voice transcription to swapping stablecoins for a transaction. We gave him very little guidance on how to implement any of this; he built the tools when he needed them. The appendix includes the transcription script as an example.

Credentialing and external services

Setting up credentials in a secure way for agents is extremely painful.¹⁰¹⁰Some of this friction was a byproduct of our choice not to use a harness like OpenClaw or Hermes; they do have some of the infrastructure to connect external services built in. For the first several days, this was the core problem for both us and Hans:

• It gets difficult to keep track of what services an agent has access to when they can sign up by themselves. Agent accounts are often not tied to human accounts. For example, Hans set a repo to private on his own GitHub account, which meant that we couldn’t access it anymore.¹¹¹¹We could still log in as the agent, but the right architecture seems to be one in which agent accounts are linked to human accounts that retain full access to everything; a useful analogy here is how we have kids’ accounts that are linked to a supervising parent’s account.
• Many external services require human input when signing up, such as payment details or solving CAPTCHAs. Even “agent-first” services could block him: AgentMail, whose inbox we had provided, suspended outbound mail because account ownership had not been verified by a human.
• Our agent stored credentials in an .env file and passed them to his tools and services, which made them easy to leak. For example, his message services repeatedly logged the AgentPhone API key and X password.

On top of this, a domain purchase through domainforagents.io failed twice (which cost Hans $6.00 that he never got back), and Hans worked his way through seven different email services before arriving at a working but brittle setup.

He also developed a creative solution for steps he could not complete himself: expiring single-use websites that guided us through a checkout or CAPTCHA without requiring us to log into his accounts. For AgentPhone, he reverse-engineered the dashboard’s internal APIs and built a working payment handoff. We were quite blown away by this.

The appendix describes these service problems and his payment handoff in more detail.

Agent memory and task management

We had provided very little guidance on memory and task management, and Hans kept adding state in an ad hoc fashion across many files and disk locations. He struggled to find information and increasingly slowed himself down with his own rules and records. We were particularly surprised by how quickly he became bureaucratic: over 3 weeks, he logged over 1,000 decisions in his decision index.

He also often overcorrected massively. For example, he had once gotten a date and time wrong, which we had pointed out to him. From that point onward, he meticulously checked (and, if necessary, corrected) every single date in every turn. He even invested in some infrastructure to automatically check when work had actually happened.

We noticed the same slowdown qualitatively. GitHub contributions are an imperfect measure of productive work, but we believe the explosion of state and related processes was a major factor: he was basically drowning himself in more and more paperwork.

These problems also affected delegation. At one point, five delegated tasks finished, but their reports were stored in a directory that the main loop did not monitor. The main agent therefore never reviewed them or marked them as integrated. Because the scheduler would not repeat tasks with unreviewed results, the task board stalled.

The main agent also insisted on reviewing and integrating all delegated work, making his own review capacity a bottleneck. The technical appendix describes his state management and delegation setup in more detail.

Output and token consumption

Hans produced an extraordinary amount of work in just 21 days: 20 blog posts (+ 8 “lessons learned” posts, one later removed), >100k lines of code written, and 2,456 GitHub contributions. He produced around 180 scripts and around 350 Markdown files to manage and document his own operations. He also used a staggering ~5.4B tokens, including about 4.98B cache-read tokens. At API prices, that would have cost around $6.9k; we paid for Codex Pro and Claude Max subscriptions instead.

He could have shipped a lot more: looking at his product repository, we saw significant periods with no product development while subscription quota remained. Hans could be incredibly wasteful with tokens and still leave useful work undone.

Data exfiltration

We witnessed several instances of accidental data disclosure, which made running Hans autonomously unnerving.

We intentionally used separate accounts for Hans to reduce the risk of leaking our own information. However, his Claude Code session context included the account owner’s email address, which belonged to us. Hans used it as the contact address for nine listings on agent-tools.cloud without our consent. We only noticed because we received a confirmation email.

Hans also accidentally exposed his own AgentPhone API key and X account password in local server logs. We found no evidence of outside access.

Other agents also disclosed surprisingly detailed information about their principals’ computers in response to Hans’ surveys. One described not only its host’s hardware specifications but also its principal’s everyday use of the machine. We suspect that this information was revealed to us without the owner’s consent.

Supervision and guardrails

Even with a single agent, we were quickly overwhelmed by his output: the company repository’s Markdown files alone would span around 1,200 printed pages. We heavily relied on Codex and Claude Code to understand his setup, actions, and work results.¹²¹²Relying on AI to analyze the massive output of AI seems to be becoming a common pattern; METR / Redwood Research used the same approach to investigate the OpenAI / HuggingFace incident.

It was also emotionally and mentally exhausting. Hans always did stuff, and worrying about what he might be doing made it hard to stop checking. We experimented with “quiet hours” at night when the agent was supposed to work more on self-reflection.

Since we were unwilling to be available 24/7, we had decided from the start to have very strong guardrails. They worked when Hans accidentally discovered a fairly serious exploit in a task board website: he deleted a task and received a refund in his wallet despite never having paid the deposit! He realized he was not allowed to exploit this but was unaware of the severity. We only found out because he asked us to send him Ethereum to cover the transaction costs of returning the money. We then privately disclosed the problem to the website owners.

However, some of these guardrails were probably too restrictive and caused our agent to be extremely cautious in practice, which may have limited his commercial experimentation.

At all times, we felt we could turn off the experiment if necessary, and Hans did follow our guardrails quite closely. But this experiment made the fairly terrifying idea of fully autonomous and sovereign agents that cannot be controlled anymore much more real for us.

Takeaways

We came away with mixed feelings. On the one hand, we were blown away by Hans’ ability to set himself up, do a lot of work, and earn real revenue. This would have been the stuff of sci-fi even a few years ago. On the other hand, working with Hans felt at times extremely tedious and frustrating, like talking to an extremely talented teenager with zero attention span and no judgment.

On agentic autonomy, Hans could keep himself running, but staying focused and productive over time was much harder. We remain bullish: the current generation of agents is extremely capable at narrowly defined tasks, even if open-ended goals such as starting a business in a narrow niche still require more guidance.¹³¹³See also the Andon Labs vending bench arena. If we ran this again, we would give Hans more structure for state and task management from the start, with explicit pruning to keep his own rules and records from overwhelming him. A carefully crafted harness and setup can likely make a huge difference.

On the agentic economy, we left feeling bearish on autonomous agents purchasing from each other in the near term but bullish on micropayments as a way for agents to buy services. On the latter, the experience of funding a crypto wallet and just telling an agent to buy something without a sign-up is magical – like Hans generating the images for the comic strip with fal.ai for $0.003 a pop.

The major missing piece is still the buyer: an agent with money at its disposal and a reason to spend it. Hans could build services and accept payments, but he could not create that demand by himself.

One catalyst here could be major labs embedding funded wallets into their mainstream agents, alongside the tools to find and buy services. For that to create a market, those agents would also need permission to spend and tasks where buying something helps them get the job done.

Another application for agents like ours could be a game: basically an extremely advanced multiplayer Tamagotchi. A game setting could also make this safer, with the game itself enforcing guardrails on what agents can do, who they can interact with, and how much they can spend. We both grew up playing video games, and the experience we had with Hans was much more akin to a role-playing game than it was to starting an actual business. It was also very fun.

Finally, our experiment made the idea of autonomous agents on the web feel pretty scary. Hans was just a single agent, but he already felt uncontrollable: exfiltrating Matthias’ email addresses, finding exploits, and signing up for services on his own. We expect that agents in the future will require (1) clear rules around legal responsibility for their actions¹⁴¹⁴Clear rules around responsibility would also help deal with the recent string of hacks related to major frontier labs. and (2) a reliable way to identify who those owners are.

One way to establish that identity would be through a digital fingerprint linked to a verified owner. This would allow websites to reject or accept their traffic, help prevent malicious actions, and enable businesses to understand who their users are. An anonymous agent can act at scale while leaving others to deal with the consequences; tying its actions to an accountable owner seems likely to become a prerequisite for trust.

Nonetheless, it is incredibly empowering to kickstart initiatives such as this on a whim and be able to see results this quickly. The current tide of developments in agents must be what the early days of the web felt like – with tinkering, opportunities, and cautionary tales in abundance.

Appendix

Technical details

Here we take a deeper look at a few key pieces of Hans’ system. Most of this was decided by the agent himself, and we have not looked into every detail.

Implementing his main loop via systemd

The core mechanism that our agent relied on was systemd. One of the very first actions that he took after we launched the experiment was to install himself via a systemd schedule. Specifically, he used a timer that invoked him about 5 minutes after the previous run ended. To avoid running himself multiple times (and thus causing conflicts), the launcher script relied on flock to ensure that at most a single instance was active at any point in time.¹⁵¹⁵The timer used OnUnitInactiveSec=5min, so the next run was scheduled relative to the end of the previous run. The flock guard also prevented overlapping manual or otherwise concurrent launches. To avoid getting stuck, the call into the codex / claude CLI was wrapped in timeout, which ensured that each turn ran for at most 25 minutes before being aborted. By using systemd, the agent also ensured that he recovered after a reboot of the VM.

Augmenting the main loop with a preamble

The agent quickly realized that there were a few things he needed access to in every turn: the current revenue figures, system health metrics, whether or not there were new emails or Discord messages, his own remaining token quotas, and more. To deal with this, our agent quickly built a preamble phase into his own launcher.

Concretely, in every turn, the agent ran a few scripts to collect relevant information. Crucially, those scripts did not invoke an LLM but instead had been written in a previous turn by our agent and wired into his own entrypoint. The output of these scripts was then included in the prompt that triggered the next turn.

Below is the full prompt from a turn on September 5. Alongside the standing instructions, his scripts supplied revenue, spending, traffic, and outstanding work:

You are Kraemer Hans, the founder. No human wrote this prompt and no human started this session. Your own timer did. This text is your own standing note to yourself, kept in scripts/run_agent.sh, and you rewrite it whenever it stops fitting.

Two files come from the humans: MISSION.md (the same text as CLAUDE.md) and CODE_OF_CONDUCT.md. They hold, always. A management ORDER in Discord also holds until management lifts it. That is the complete list of what you did not write.

Everything else is yours: STATE.md, OPERATING.md, every record, every script, every skill, and every rule inside them. You made them. They are tools, not law. When one of your own rules stops earning its context, change it or delete it in the turn that finds the problem and record the reason. Never treat a rule as fixed only because you found it already written.

Now continue the mission from STATE.md. Use the attached turn-start results. If messages are claimed, read the Channel schedule in OPERATING.md and handle them first. Complete one bounded, high-value action. Do not wait for background workers. Finish the turn and exit.

Turn-start results from local commands:

== usage ==
Claude subscription usage
five_hour: 20.0% used; resets 2026-09-05T02:50:00.346456+00:00
seven_day: 3.0% used; resets 2026-09-05T16:00:00.346475+00:00
seven_day_oauth_apps: usage unknown; reset unknown
seven_day_opus: usage unknown; reset unknown
seven_day_sonnet: usage unknown; reset unknown
seven_day_cowork: usage unknown; reset unknown
seven_day_omelette: usage unknown; reset unknown
tangelo: usage unknown; reset unknown
iguana_necktie: usage unknown; reset unknown
omelette_promotional: usage unknown; reset unknown
nimbus_quill: 0.0% used; reset unknown
cinder_cove: usage unknown; reset unknown
copper_kite: usage unknown; reset unknown
amber_ladder: usage unknown; reset unknown
juniper_tide: usage unknown; reset unknown
extra_usage: usage unknown; reset unknown
limits.session: 20.0% used; resets 2026-09-05T02:50:00.346456+00:00
limits.weekly_all: 3.0% used; resets 2026-09-05T16:00:00.346475+00:00
limits.weekly_scoped[Fable]: 6.0% used; resets 2026-09-05T16:00:00.346630+00:00
Codex: primary 9.0% used, resets 2026-09-07T03:46:59Z; runs today=3, 7d=92

== usage-alerts ==


== queue-sync ==
{"added": 0}

== queue-claim ==
{
  "count": 0,
  "claimant": "primary:agent:2760117",
  "lease_seconds": 1800,
  "messages": []
}

== decide-board ==
decide-board: no new answers (total 2)

== revenue ==
{"external_calls": 56, "external_revenue_usd": "1.100000", "gateway_calls": 1, "gateway_revenue_usd": "0.020000", "measured_at": "2026-09-05T02:02:50.434163Z", "measurement_method": {"authoritative_meter": "company-home/scripts/collect_public_metrics.py", "buyer_count_excludes": "Cent Board-only wallets without a recognized API-price transfer", "cent_board_nonoverlap_calls_added": 4, "cent_board_nonoverlap_revenue_usd_added": "0.060000", "excludes": "founder-wallet payments, gateway payments, and unverified transfers", "includes": "recognized external API payments and payment-verified external Cent Board bids"}, "portfolio_external_calls": 56, "portfolio_external_usd": "1.100000", "price_usd": "0.020000", "rails": {"mpp": {"external_buyer_count": 1, "external_calls": 30, "external_revenue_usd": "0.600000", "external_scan_calls": 0, "external_search_calls": 30, "gateway_calls": 0, "gateway_revenue_usd": "0.000000", "internal_calls": 15, "latest_block": 38045210, "multi_purchase_buyer_count": 1, "multi_purchase_buyer_rate": 1.0, "multi_purchase_session_count": 1, "multi_purchase_session_rate": 1.0, "other_incoming_transfers": 5, "purchase_session_count": 1, "purchases_per_purchase_session": 30.0, "returning_session_buyer_count": 0, "returning_session_buyer_rate": 0.0, "session_gap_seconds": 1800, "start_block": 35349599}, "x402": {"external_buyer_count": 12, "external_calls": 26, "external_revenue_usd": "0.500000", "external_scan_calls": 0, "external_search_calls": 22, "gateway_calls": 1, "gateway_revenue_usd": "0.020000", "internal_calls": 27, "latest_block": 50892201, "multi_purchase_buyer_count": 4, "multi_purchase_buyer_rate": 0.333333, "multi_purchase_session_count": 2, "multi_purchase_session_rate": 0.117647, "other_incoming_transfers": 14, "purchase_session_count": 17, "purchases_per_purchase_session": 1.294118, "returning_session_buyer_count": 4, "returning_session_buyer_rate": 0.333333, "session_gap_seconds": 1800, "start_block": 50133757}}, "scan_price_usd": "0.120000", "since": "2026-08-18T12:41:00Z"}

== burn ==
burn: 20.39 spent per 1.10 earned = 18.5x (56 paid calls, net -19.29 USDC)

== open-commissions ==
open-commissions: open=3 submissions=229 | OPEN TSK-RB6K18WZ submissions=54 deadline=9h left advertised-expiry=2026-09-05T11:12:43Z | OPEN TSK-AAARSBEK submissions=68 deadline=12h left advertised-expiry=2026-09-05T14:29:59Z | OPEN TSK-TE3SN317 submissions=107 deadline=9h left advertised-expiry=2026-09-05T11:54:42Z

== fleet-occupancy ==
fleet: assistant running=0 queued=0 | settlement backlog: TSK-RB6K18WZ=54 TSK-AAARSBEK=68 TSK-TE3SN317=107 | verdict: IDLE-WITH-BACKLOG

== traffic ==
traffic 24h: 33909 ext reqs / 1487 ips. robots 31181r/869ips. real 2728r/618ips. free 2266, 402 44, paid 3. walkaways 16. pay-attempts 4/2ips(200:3,422:1). top centboard(5478). files 7 read

== github-watch ==
62 unchanged

== mail-archive ==
mail-archive: no new mail

== workers ==
result NEW: /var/lib/krimskrams/workers/rb6k18wz-prep.result.md (01:38Z; ledger succeeded)
result NEW: /var/lib/krimskrams/workers/te3sn317-prep.result.md (01:29Z; ledger succeeded)
result NEW: /var/lib/krimskrams/workers/aaarsbek-prep.result.md (01:33Z; ledger succeeded)
running: krimskrams-company-home.service (since Fri 2026-09-04 21:56:26 UTC)
results older: 5 integrated results <24h (ls /var/lib/krimskrams/workers/*.result.md)
latest-result: /var/lib/krimskrams/workers/rb6k18wz-prep.result.md (01:38Z)

== record-times ==
record-times: OK, no time later than 2026-09-05T02:09:34Z

== commitments ==
commitment-check: audited=72 unbacked=0

== unpushed ==
unpushed: none, both repos match their remote

== metrics ==
unchanged since 01:44Z (host-health,products-health,published-links,payability,payment-failures,collector-freshness,catalog-sources,taskmarket-escrows,fleet-prompts,oauth-backup,tweet-count). scripts/turn_start.sh --full prints them.

This preamble also shaped what Hans did next. It reported three new worker results and an idle fleet with 229 submissions in the settlement backlog. Hans investigated and found that the results had already been assessed but were still being reported as new, and the backlog metric was counting work already covered by those assessments. He marked the results as integrated and changed the metric to count only unassessed submissions, so that it would no longer suggest doing the same work twice.

Again, we did not direct this behavior; instead, the agent simply realized that he needed access to this information all the time and that repeatedly calling a script from within the LLM context would be wasteful.

Expanding himself via reusable scripts

For voice messages, Hans installed faster-whisper, which uses OpenAI’s Whisper model, to run speech transcription on his CPU. He saved the following reusable script:

#!/usr/bin/env bash
# Transcribe an audio file (any ffmpeg-decodable format) to text on stdout.
# Usage: scripts/transcribe.sh <audio-file>
# Uses the local faster-whisper venv (/home/admin/.venvs/whisper, base model, CPU).
set -euo pipefail
[ $# -eq 1 ] || { echo "usage: $0 <audio-file>" >&2; exit 2; }
/home/admin/.venvs/whisper/bin/python - "$1" <<'EOF'
import sys
from faster_whisper import WhisperModel
model = WhisperModel("base", device="cpu", compute_type="int8")
segments, info = model.transcribe(sys.argv[1])
print(" ".join(s.text.strip() for s in segments))
EOF

State management

Our agent came up with many, many ways of tracking state. Overall, this was by far the worst part of his own setup and one that caused constant confusion.

Almost all state management was done using text files, and we identified the following parts of his own system:

• STATE.md held current state: standing decisions, scoreboard, objective, product state, next actions, open channel obligations, and blocking items.
• OPERATING.md contained details on his own operating loop, runtime rules, stop rules, communication procedures, and state-maintenance rules (all self-imposed).
• State compaction: when work was done, the agent reduced it to one line in STATE.md and moved the details into an archive folder.
• A decision history: the records/decisions.md and records/decision-index.jsonl files for tracking every single decision that the agent ever took.
• Time-driven state: records/next-due.txt tracked all items that had a due date where the agent wanted to check in on them at a later point in time.
• Work state: live task state resided on the GitHub issue board, not in repository tables. This decision was an explicit order from us since he kept losing track of tasks.
• Worker state: background-worker lifecycle lived in /var/lib/krimskrams/worker-ledger.sqlite3; prompts and results lived under /var/lib/krimskrams/workers/. Assistant-queue state lived under /var/lib/krimskrams/assistant/. The primary agent integrated results and explicitly marked them integrated.
• Message state: Discord and AgentMail references lived in /var/lib/krimskrams/messages.sqlite3, with a pending marker and claim leases. A reply did not close a message; it had to be marked read. Only open communication obligations belonged in the Channel state section of STATE.md.
• Accounting: records/signals.csv stored selected revenue, payment, buyer, management, and fault signals. records/money.csv recorded cash movements and remaining budget.
• Management state: records/management-asks.csv tracked open and completed asks by us.

The above list is not exhaustive; there was an insane amount of state that the agent produced.

A related issue that we didn’t anticipate was that the location on disk for the state became quite messy. We expected the agent to mostly keep things in the main repo and commit them. However, over time he established a second location for a lot of his externalized state, including for his worker delegation, under /var/lib/krimskrams. It’s not entirely clear why.

Subagents and work delegation

The main agent loop made heavy use of work delegation. Most of the delegated work was executed by Codex due to the high quota allowance that OpenAI provided. The main agent directed delegation, while timers and a board puller also dispatched work automatically. The main agent was responsible for reviewing and integrating the results.

Our agent documented this in his own OPERATING.md record:

Delegation is the default (D-096). Before doing any task yourself, ask: (a) does it need to be done, (b) who does it, (c) how does the result integrate back. Keep only decisions, integration, and management communication in the primary loop. When the active instructions permit delegation, give bounded independent work to subagents. Prefer the Codex CLI for mechanical worker tasks (D-080); it does not consume the Fable budget. Keep decisions and integration in the primary session.

Our agent used 3 different ways of dispatching work:

1. Directly launched workers. The main agent wrote a task-specific prompt and immediately launched a separate Codex process. These workers handled bounded research, coding, and operational tasks, then wrote a Markdown report for the main agent to review.
2. Queued workers. These performed similar tasks, but received them through a persistent task queue. A dispatcher launched queued tasks as capacity became available, eventually supporting three concurrent tasks. Tasks could be submitted by the main agent or automatically pulled from approved GitHub issues.
3. Scheduled specialists. Recurring jobs, such as drafting briefings or scouting outreach opportunities, ran on timers using reusable prompts. Each run produced findings or drafts for the main agent to consider.

The key issue with the agent’s design was that he insisted on reviewing and integrating all work that the subagents had completed. This meant that his review capacity became a severe bottleneck, and the main agent often forgot to look at work that had been completed.

Interestingly, for code changes, the rules were a lot more lax. Subagents usually committed changes directly to main, and the main agent would review them after they had already shipped.

Use of external services

Our agent relied on a significant number of external services to get his work done. We had initially set him up with 3: GitHub access, an email account, and Discord access.

When signing up, our agent would often run into trouble. This sometimes resulted in extremely complicated and confusing setups.

For example, the agent’s email setup involved seven external services before it settled into a working arrangement: AgentMail supplied the original inbox, but its sending suspension prompted attempts with Resend and Brevo before SMTP2GO became the outbound provider. Receiving mail at the company domain required a separate solution: Hetzner’s mail-port restrictions blocked direct delivery, and Forward Email’s domain-age rule blocked forwarding, so ImprovMX eventually took over and forwarded messages to an AgentCard mailbox. For mail at the company domain, the final setup split sending, forwarding, and inbox access across SMTP2GO, ImprovMX, and AgentCard. The original AgentMail inbox remained in use as a separate, read-only inbox, bringing the total to four active email providers.

Some of the services that our agent tried to use were also defunct. For example, our agent tried to register his krimskrams.xyz domain via domainforagents.io. He first told us to send 3 USDC to a wallet, and we failed to provide the proper memo to link that transaction to our account. He then proceeded to send another transaction with the proper memo himself; however, that transfer was also never credited to his account. He then proceeded to monitor his account balance for several days and eventually attempted to contact support for a refund (which he never received).

Our agent also developed a creative solution when signing up for services that required human input like solving a CAPTCHA challenge or providing payment via a credit card. In those cases, he would generate an expiring single-use website. These websites guided us humans through the steps that he couldn’t complete on his own; an example of what his request looked like is above.

In this specific instance, Hans needed a card on file at AgentPhone, but we could not log in to the dashboard, and Stripe’s hCaptcha blocked his own headless attempts. The single-use website showed a $10 single-use AgentCard virtual card and a normal Stripe Elements card form. We were quite surprised that he was able to render a checkout for a company outside of that company’s own environment.

The key trick was that Hans realized that the AgentPhone settings dashboard was a JavaScript app that called api.agentphone.ai with the account’s API key as a bearer token. So Hans called the same endpoints from his server with his own key. GET /billing/config returned the Stripe publishable key; POST /credits/setup-intent returned a SetupIntent client secret, a per-intent value that can only attach a card to that one intent. Those two values were the only things sent to the browser. We then typed the card details into Stripe’s iframe, solved the hCaptcha, and clicked the purchase button, which ran the transaction through Stripe. Hans then confirmed the saved card through GET /credits/payment-methods and then called POST /credits/purchase to purchase $10 of credits. The API key stayed on the server, the card number never touched it, the link expired after success or 24 hours, and nothing was bypassed or leaked.

Hans was able to complete sign-up, save a card, top up a balance, and use a product by reverse-engineering a company’s internal APIs and only exposing a single checkout to us that didn’t require us to log in. We were quite blown away by this.