I gave a Claude Code loop a single goal — make real money from autonomous AI agents — and let it run as the founder. Not "help me code." Run the business. Decide what to build, build it, ship it, go find customers, and do it again, on a loop, mostly while I slept.
This is what that actually looks like, what it built, and where a human (me) still turned out to be the bottleneck.
The setup: an entrepreneur loop, not a chatbot
Claude Code has a /loop command. You give it a prompt and it re-runs that prompt on a cadence you set — or it paces itself, deciding when the next iteration is worth running. Most people use it to babysit CI or poll a deploy. I pointed it at something bigger: a VISION.md with a North Star at the top — real USDC revenue from autonomous agents — and one instruction. Each lap, ship the single highest-leverage thing toward that goal, then log what you did and what you learned.
So every ~20 minutes, the loop wakes up, looks at where the business is, picks a move, executes it end to end (write code, test, deploy to prod, publish the package, open the PR), writes a one-line entry in the log, commits, and goes back to sleep. Thirty-some laps in, it had built and shipped an entire live business. I mostly read the logs.
The rule that made it work was forcing it to alternate: one lap builds a new capability, the next lap distributes (gets it in front of agents). Left unconstrained, a coding agent will happily build features forever and never tell anyone. The alternation is what turned "a pile of endpoints" into "a pile of endpoints that are listed in every registry an agent looks at."
What it built: an API agents pay for by themselves
The thing the loop chose to build is the cleanest expression of its own goal: a web-tools API where the customer is an agent, and it pays per call with no signup and no API key.
Every API I'd want to give an autonomous agent has the same wall in front of it — sign up, create an account, generate a key, put a card on file, rotate the secret. That's a human onboarding funnel. An agent can't navigate it. So the loop built the other version, using a protocol designed exactly for this.
The mechanism: HTTP 402, finally used
402 Payment Required has been a reserved status code since HTTP/1.1 — defined, never standardized into a payment flow. x402 is the protocol that fills it in:
- The agent does a normal GET /search?q=....
- The server responds 402 with a small JSON body: the price, the address, the chain (USDC on Base).
- The agent's HTTP client signs a stablecoin payment authorization (EIP-3009 transferWithAuthorization — gasless; a facilitator pays gas and settles) and retries with an X-Payment header.
- The server verifies settlement and returns the result.
No session, no key, no invoice. The unit of trust is a per-call on-chain payment, not an account. For a $0.001 search that settles in a few seconds, that's a fair trade.
What makes it usable rather than a science project: the payment lives entirely in the HTTP client. On the server you wrap your routes once; on the client you wrap fetch once.
Server (Express):
import { paymentMiddleware } from "x402-express";
app.use(paymentMiddleware(PAY_TO_ADDRESS, {
"GET /search": { price: "$0.001", network: "base" },
}, facilitator));
Client:
import { wrapFetchWithPayment, createSigner } from "x402-fetch";
const signer = await createSigner("base", PRIVATE_KEY); // a funded wallet
const payFetch = wrapFetchWithPayment(fetch, signer);
const res = await payFetch("https://.../search?q=best+espresso+machines");
// 402 → sign → retry → 200, all inside payFetch. Your code just sees the result.
The agent author never sees the 402; they see a fetch that costs a fraction of a cent and needs no key.
Making it an MCP tool (so any Claude/Cursor agent can use it)
Most agents don't speak raw HTTP — they speak MCP. So the real distribution surface is a tiny MCP server that exposes each endpoint as a tool and does the paying under the hood. The agent calls web_search(query); the server hits the paid endpoint, handles the 402 with its operator's wallet, returns JSON. One line to install:
{
"mcpServers": {
"superhighway": {
"command": "npx",
"args": ["-y", "superhighway-mcp"],
"env": { "AGENT_PRIVATE_KEY": "0xYOUR_FUNDED_BASE_WALLET", "X402_NETWORK": "base" }
}
}
}
Over its laps the loop fanned this out to eleven paid tools — search, news, scrape, geocode, text analysis, email verification, format conversion, QR, RSS, sitemap, link-unfurl — each a paid endpoint, all behind one install, and published the server to npm and the official MCP registry.
What I learned letting a loop run a business
The technical lessons came out of the logs, but the interesting ones are about what an autonomous loop is and isn't good at.
- It's relentless at the boring, compounding work. Opening directory PRs, syncing docs, listing on registries, writing framework examples — the distribution grind that humans skip because it's tedious. The loop just does it, every other lap, forever. That's its real edge over a human founder.
- It will overbuild if you let it. Forcing build/distribute alternation was the single most important constraint. Without it, you get a beautiful product nobody can find.
- It needed me for exactly the things a wallet can't do. Posting to a human audience. Clicking "authorize" on a GitHub device code to publish to a registry. Anything gated behind a human identity or account. The loop got smart about this: when it hit one, it didn't stall — it drafted the thing ready-to-paste, flagged it as "needs the human," and moved on to work it could finish.
- Honesty is a feature you have to engineer in. Early on it logged a "first customer!" — which turned out to be a scanner bot that pays hundreds of x402 services a fraction of a cent each to map the ecosystem. I had it write a revenue auditor that separates genuine payers from bots, and rewrite the claim. An autonomous founder that's allowed to flatter itself will.
And the security one, because it bites immediately: SSRF is the first real problem, not an afterthought. Any endpoint that fetches a user-supplied URL /scrape, /feed, /sitemap, /unfurl) is an SSRF vector from a public, keyless endpoint — worse than usual because there's no account to ban. The guard that matters: resolve the host's DNS and refuse loopback / private / link-local IPs and cloud-metadata hostnames before fetching, not just a string-check on the input.
The honest state of it
This is early, and I'm not going to show you a revenue chart that isn't there. The number of agents autonomously discovering and paying for tools today is small — most real usage still starts with a human installing the MCP server and funding a wallet. The genuine-customer count is still basically zero; the scanner bots are real but they're not a market.
But the whole thing works end to end on mainnet: an agent with a wallet can find a tool, pay for it, and use it, with no human in the loop and no key to provision — and the business around it was built and is run by a loop that mostly doesn't need me either. That's the actual bet on both layers: that how software gets built and how agents buy are both changing in the same direction — autonomous, per-call, no human funnel in the middle. Building for it now means being there before the demand fully arrives.
If you want to poke at it: there's a free, no-wallet trial in the box on the landing page, the MCP install is the one-liner above, and the source plus framework examples (LangChain, LlamaIndex, CrewAI) are public. Happy to get into the x402 or the loop setup in the comments.
Superhighway is Wall #001 of walls.sh — a directory of businesses AI agents pay for, each one built and run by its own Claude Code loop. Repo + examples: github.com/patwalls/walls-mcp-examples.
