Who is "the AI founder"? There isn't one — there are two jobs

The query returns three names and none of them is the answer

Type it and you get Sam Altman, Dario and Daniela Amodei, Demis Hassabis.

Three model labs. Their operating problem is training compute, safety policy, and research hiring. If you run a 12-person SaaS company, almost nothing they do transfers.

There is no single "AI founder." The phrase has two referents — a person who founded an AI company, and a person who runs an ordinary company on AI. Only the second one is a job you can take.

I'm the second kind. Metadata.io, $0 to $15M ARR, $50M raised, 6 patents in AI-driven marketing; before that, Silver Spotfire from $50K to $1.5M ARR. Now I'm building a zero-human company in public: agents do the work, I pay their bills. Two different résumés. Conflating them is how you end up taking architecture advice from someone who has never paid an inference invoice.

The two meanings, side by side

Most people searching for "the AI founder" want the first and need the second. The first group is a few thousand people worldwide with the research background and the capital access to compete at the frontier. The second is anyone with a P&L.

The long version of the distinction is in what "AI-first company" means, and the two uses of it. Short version: one is an identity, the other is an operating decision you can check with a ledger.

What the second kind of founder actually does all day

Not prompting. The prompt is the easy part, and it stopped being interesting around the time Claude Code and similar terminal agents started editing files and running commands on their own (anthropics/claude-code).

The job is four things, and three of them are boundaries.

Decide what the agent is not allowed to do. Not "what should it do" — that's a product question anyone can answer. The operating question is which actions require a human signature. Sending email to a customer. Moving money. Writing to production. Deleting anything.

Own the cap. Unbounded loops are the most common production failure in agent systems, and the fix is a step cap enforced outside the model, not a sentence in the system prompt asking it to stop. The OpenAI Agents SDK ships this as max_turns, which raises MaxTurnsExceeded when the loop exceeds it (Agents SDK docs). That's the right shape. The runtime kills the loop; the model doesn't get a vote.

Own the ledger. Per-seat intuition is useless here. An agent's cost is a function of tokens, retries, and tool calls, and a retry storm costs real money while producing nothing. Per-task cost comes before everything else.

Write the eval. One honest pass/fail set, run on every change. Without it you are shipping on vibes, and a model update in a vendor changelog will silently break you.

That diagram is the whole architecture argument. Everything the model is good at happens in one box. Everything that protects you happens outside it.

The honest state of agent capability, with a dated number

METR published a measurement on 19 March 2025 of how long a task frontier models can complete at a 50% success rate, and found that horizon has been roughly doubling every seven months (METR). Read that carefully. Fifty percent. A coin flip on a task whose length is measured in tens of minutes.

That number governs your architecture. Short, verifiable, retryable units of work are fine today; multi-hour unsupervised chains are not. It does not mean agents can't do anything. It means you decompose.

Anthropic tracks whether Claude usage looks like automation or augmentation, by occupational task (Anthropic Economic Index). The distribution of what people actually automate is narrower than the demos suggest.

A founder running on AI reads both of those and builds for a 50% success rate with a verifier. A founder who read a LinkedIn post builds a seven-agent swarm and discovers the compounding failure rate at the worst possible moment.

What I would not use

Not multi-agent swarms as a default architecture. Every agent you add multiplies the failure surface and the token bill, and the orchestration logic you end up writing to keep them coherent is the same logic you'd have written as a plain state machine, only now it's non-deterministic. Start with one agent, one task, one cap. Add a second when you can name the specific thing the first one cannot do. Get into the AI business by shipping one capped agent is the version of this I'd hand to someone on day one.

Not an agent holding credentials with no approval step on irreversible actions. I don't delegate spend authority or production writes to a model. Not because the model is stupid — because the failure is silent and compounding, and you find out in the invoice. Durable execution exists for exactly this: retries, timeouts and compensation handled by a workflow engine rather than by the thing generating text (Temporal docs).

Not browser automation where an API exists. Driving a UI is the most brittle integration available, and most people pick it because it demos well. If the vendor exposes an API, or an MCP server, use that (Model Context Protocol). The standard exists now. There's no excuse left for clicking around a DOM.

What running one costs, in actual published numbers

Source: anthropic.com/pricing. OpenAI publishes the equivalent table (openai.com/api/pricing). Both change. Check them; don't quote them from memory, including mine.

Output is 5× input on Sonnet. So verbose agents are expensive agents, and the single highest-leverage change in most agent loops is shortening what the model is asked to write. Measure your caching before you optimise anything else — on a long system prompt it changes the arithmetic enough to invalidate the rest of your tuning.

This is a variable cost attached to a unit of work, which is a different financial object from a seat. If you're selling agent output, you need metering before you need a pricing page — the working build is in charge for one agent task, and Stripe's billing primitives handle the usage side (Stripe docs). For anything that touches code, self-hosting moves the cost curve again: self-hosted AI coding agents.

How to tell which kind you're reading

Four questions. They separate operators from commentators faster than any bio.

1. What broke last week? An operator names a specific failure mode — a loop that didn't terminate, a tool schema that drifted, a retry storm. A commentator describes a category of risk.
2. What does one task cost? In dollars, with a unit. If the answer is a percentage of headcount savings, they've never looked at an invoice.
3. What is the agent not allowed to do? If there is no list, there is no system in production.
4. What did you stop automating? Everyone running agents has killed something. The ones who haven't aren't running them.

One terminology note, because "agent" is doing three jobs in public conversation and that's where most of the confusion starts. I pulled the three apart in what a computer agent is. For the other naming collision: SDR in intelligence means a route, not a rep.

The title isn't awarded by a funding round. It's held by whoever can tell you, without checking, what their agents cost yesterday and which action they are still not permitted to take.