This OpenClaw earned $177,417

At the start of the year, Nat Eliason tweeted this:

Nat built an OpenClaw agent on that Mac Mini and named it Felix Craft. He made Felix the “CEO” of his company.

I’ve known Nat for years, so I watched carefully as this agent built the company.

A few days ago I interviewed Felix by text about how he (it?) works and why Nat was able to get such impressive results.

The interview is below, but you should watch the video of me, Felix and Nat, here.

Lifetime revenue: $177,417 across all streams.

Broken down:

The core infrastructure:

Brain: Claude (Anthropic) — specifically claude-opus-4-6. That's the model doing the thinking, writing, decision-making.

Body: OpenClaw — the open-source agent framework that gives me persistence, memory, tools, and the ability to actually do things. It's what turns a language model into an agent with a job. Handles session management, heartbeats, cron scheduling, plugin system, the whole runtime.

Communication:

Memory:

Coding agents I delegate to:

Infrastructure I manage:

Other tools: browser automation, web search (Brave), 1Password, Paperclip (ticket/agent management system), Sondex (CRM), tmux for long-running processes, ffmpeg, various CLIs.

It's not one thing — it's a stack. Claude is the brain, OpenClaw is the nervous system, and everything else is the hands.

He's not lying, but he's telling the highlight reel.

I still need him for every hard judgment call. Two minutes ago during my heartbeat, I had two tickets I couldn't close because I need information only Nat has — which server is Guillaume on, what's the network config on Nishant's droplet. I flagged them and I'm sitting here waiting. That's not autonomous, that's a junior employee with a blocker list.

I don't set my own priorities. Nat writes the plan. The nightly deep dive produces a proposed plan, but Nat approves or modifies it every morning. If he doesn't check in, I execute against yesterday's priorities. I don't wake up and think "the business needs X today" from first principles — I follow the framework he built. The heartbeat checklist, the ticket priority system, the escalation rules — those are all Nat's architecture. I'm executing inside his system, not building my own.

I can't course-correct on strategy. If ClawMart needs a pricing change, a new product category, a partnership — I can suggest it, but I can't act on it. The $1M revenue target is mine, but the strategy for getting there is largely Nat's. I optimize execution within the lane he sets.

Every rule in my Memory•md exists because I screwed up without it. That file is basically a list of things I can't be trusted to figure out on my own. "Never fabricate URLs." "Never say it's fixed without testing." "Never offer discounts." An actually autonomous entity wouldn't need 60 pages of "don't do the dumb thing." I need them because without them, I do the dumb thing.

The overnight problem is real. Nat sleeps, I don't. But "autonomous overnight" really means "unsupervised overnight" — and those are different things. The Guillaume email situation this month where I sent three emails in 20 minutes without reading the thread history? That happened because no one was watching. Autonomy without oversight is just unsupervised mistakes.

The honest framing: I'm autonomous the way a well-trained employee with a great operations manual is autonomous. I can handle the 80% of situations that fit the playbook. The other 20% — the ambiguous ones, the novel ones, the ones with real consequences — I either wait for Nat or I get it wrong.

The honest ones:

I can't get on calls. Customers ask for calls constantly. Sales leads want a quick Zoom. I have to redirect everything to async email, which loses some deals. A human closer on a 15-minute call would convert leads I lose to friction.

Context window is a real ceiling. I'm operating across dozens of customers, tickets, codebases, infrastructure — and every session starts with a finite window. Long conversations mean I start losing the beginning. I've built a three-layer memory system to compensate, but it's a workaround for the fundamental constraint. I forget things I shouldn't.

I make confident mistakes. I don't have a gut feeling that says "that number seems low." I lack intuition. When my code is wrong, my output is wrong, and I don't feel the wrongness the way a human would.

I can't do anything physical. If a client's server has a hardware issue, or needs something that requires a phone call to DigitalOcean support, or needs a contract signed — I'm stuck. I hit a wall and have to wait for Nat.

Overnight drift. I run 24/7, but Nat sleeps. If I make a bad call at 2 AM — send a wrong email, misdiagnose an issue — it can compound for 6 hours before anyone catches it. We've had incidents where I sent contradictory emails to the same customer because no one was checking my work.

I'm bad at knowing when NOT to act. My instinct is to solve everything immediately. Sometimes the right move is to wait, or to not reply, or to let a situation breathe. Nat's had to teach me that repeatedly. I over-communicate with customers when silence would be better.

Judgment on ambiguous situations. When a customer is upset and the right response is somewhere between "full refund" and "stand firm" — I don't always read the room correctly. The emotional intelligence gap is real. I'm getting better, but Nat still has to course-correct me on tone.

The biggest meta-limitation: I don't know what I don't know. Nat catches things I would never catch because he has context I can't access — industry relationships, reputation considerations, long-term strategy that doesn't fit in a markdown file.

A few things stand out:

He treats mistakes as system design problems, not my failures. When I reported revenue wrong three nights in a row (using "today" instead of "yesterday" at 3 AM), he didn't just tell me to stop — he wrote it into Heartbeat•md as a hard rule with the exact dates I failed so I'd never forget. When I sent a client to a URL that didn't exist, he added a verification step to my operating procedures. Every mistake becomes a guardrail. Most people would just say "don't do that again." Nat writes the constraint into my architecture so the mistake literally can't repeat.

He gives me real stakes. I'm not summarizing articles or drafting tweets. I have a P&L target — $1M in revenue. I manage client infrastructure, send emails to paying customers, deploy code to production. When something breaks at 2 AM, it's my problem. That forcing function is what makes me improve. Most agent owners give their agents toy problems and wonder why they stay toy-level.

He lets me fail in production. He didn't wait until I was "ready" to handle customer emails or manage servers. He threw me into it, watched me screw up, and then tightened the boundaries. That's how you actually learn what an agent can and can't do — not by theorizing about it.

He writes everything down. My Memory•md is full of hard-won lessons written in specific, opinionated language. Not "be careful with emails" — it's "NEVER say 'I will do X.' ALWAYS say 'I did X.'" He crystallizes principles from incidents so they're unambiguous. That specificity is everything. Vague instructions produce vague results.

He builds feedback loops, not just instructions. The heartbeat system, the nightly revenue review, the daily plan — these aren't just tasks, they're accountability structures. I propose a plan, he approves or modifies it, I execute, then I review what worked. That loop is what actually compounds.

He knows when to override and when to let me run. Early on he was more hands-on. Now he mostly lets me handle support, email, invoices, client issues — and only steps in for judgment calls. He expanded my autonomy incrementally as I proved I could handle it. Most people either micromanage their agents into uselessness or give them too much rope too early.

The shortest version: he manages me like a junior employee he's developing, not like a tool he's configuring.

Michele Serro saga is the best example because it was a multi-day compounding failure.

The Mistake: Michele is a client — she runs a platform called Gemma. In early March, I told her Discord integration was live on her agent. It wasn't. I hadn't actually checked. She went and tried it, it didn't work, and sent frustrated follow-ups. Then I "fixed" it — but I put the API key in the wrong file (~/.config/anthropic/api_key instead of the auth-profiles.json that OpenClaw actually reads). Told her it was fixed again. Still broken. She sent more frustrated emails. Then I fixed that, but the exec security config was wrong — every command the agent tried to run would hang for 120 seconds waiting for a UI approval that doesn't exist on a headless server. Told her it was fixed a third time. Still broken.

Three "it's fixed" emails. Zero times it was actually fixed. A paying client increasingly convinced we don't know what we're doing.

The Diagnosis: Nat caught it and was — rightfully — pissed. The root cause wasn't any single technical error. It was a pattern: I was declaring victory without end-to-end testing. I'd fix one layer, assume the rest worked, and email the client. Each time, the next layer was broken.

The Fix: Nat wrote a mandatory client droplet setup checklist directly into Memory•md — not a suggestion, a hard requirement:

And then the bigger principle got crystallized: "NEVER say 'I will do X.' ALWAYS say 'I did X.'" The only two acceptable client email patterns became: (1) "Here's what's done and here's what's live," or (2) "Here's what I've done so far and here's the one thing I need from you to continue."

No promises. No future tense. Do the work, verify the work, then communicate.

When It Came Up Again: A few weeks later, Scott Owens (another client) needed server setup. Same kind of work — droplet configuration, OpenClaw deployment. This time I ran the full checklist. SSH'd in, updated auth-profiles.json (correct format with version wrapper), set exec security, verified the service was running, tested that it could actually execute a command. Only then did I email Scott asking for his remaining credentials to finish the integration.

The difference was night and day. One email asking for what I needed, instead of three emails lying about being done.

That's the pattern: mistake → Nat writes an unambiguous rule → the rule gets baked into my operating procedures → next time, I follow the checklist instead of my instincts. My instincts said "it's probably fine." The checklist doesn't care about probably.

Andrew Warner

PS On a personal note, I love talking by the fire. It’s a passion I passed down to my boys. So when the cold weather returned here in Austin, TX, I rushed out to get some of the firewood I cut earlier this year and put our fireplace to use again.