Starting a company with AI, one capped agent at a time

Claude Haiku 4.5 lists at $1 per million input tokens and $5 per million output. GPT-4o mini lists at $0.15 and $0.60 (Anthropic pricing, OpenAI pricing). At those numbers, an agent that burns 72,000 input and 6,000 output tokens to qualify one inbound lead costs about ten cents a lead on Haiku. That is arithmetic, not a forecast.

Starting a company with AI means shipping one agent into production that does one billable job, with a hard cap on steps, spend, and credential scope — and staying the only human in the loop until the unit economics are boring.

Everything else is the same business you would have started in 2015. You still need someone to pay you, a reason they keep paying, and a way to collect the money. What changed is that the delivery mechanism can now exist before the headcount does.

What one agent costs to run

List prices, straight from the vendor pages. Check them before you model anything; they move.

Sources: Anthropic, OpenAI.

Take a concrete job: an agent that qualifies inbound leads. Twelve model calls per lead — read the form, fetch the company page, check the CRM, score, write a reason, hand off. Call it 6,000 input tokens per call (system prompt, schema, page text) and 500 output.

That is 72,000 input and 6,000 output tokens per lead. On Haiku 4.5: $0.072 + $0.030 = $0.102 per lead. At 2,000 leads a month, $204. Same workload on Sonnet 4.5: $0.216 + $0.090 = $0.306 per lead, or $612 a month.

Two discounts change the shape of that bill before you optimise anything. Anthropic bills cache reads at 0.1× the base input price and cache writes at 1.25× (docs), and your system prompt and schema are byte-identical on all twelve calls — which is most of your input tokens. Batch is the other one. If the work does not have to be synchronous, OpenAI's Batch API is 50% off with a 24-hour completion window (docs). Lead scoring overnight is fine. Routing a live demo request is not.

Move the sliders on the scenario above. The thing to watch is not the monthly total — it is the per-run cost against whatever you charge per run.

Model inference is rarely the line item that kills you. The ones that do: a retry loop that re-reads a 40,000-token document eleven times, a scraping vendor priced per request, and the observability bill you did not budget because you only instrumented after the first bad week.

The approach I would not use

I would not build an AI org chart.

The pattern shows up in every demo: an "AI CEO" that briefs an "AI CMO" that briefs an "AI SDR" that briefs a writer agent. It is seductive because it maps onto something you already understand. It fails for a reason that has nothing to do with model quality.

Error compounds across handoffs, and no handoff has a verifier. Agent A produces a plausible-but-wrong brief. Agent B treats it as ground truth, because that is what you told it to do. By the time output reaches you, you cannot attribute the failure to a step — you can only see that the result is wrong and the spend is up. Six agents in a chain is not six employees. It is one process with six places to go wrong and no place to put a cap.

I took Metadata.io from $0 to $15M ARR with a real team, and the org chart was the expensive part — not the software. Reproducing that org chart in prompts reproduces the coordination cost without the judgement that justified it.

The second thing I would not do: let the model hold its own limit. A line in the system prompt saying "never spend more than $50" is a suggestion. The model can be talked out of it, forgets it after enough turns, and cannot see your invoice. Caps that matter are enforced by code the model cannot reach.

Start with one agent, one job, one output you can check. When that job is boring and profitable, add the second — and give it its own caps, not a shared budget. I wrote the narrower version of this argument in one agent, three hard caps.

Three caps, and they live outside the model

Unbounded loops are the most common production failure in agent systems, which is why both major frameworks ship with a turn limit on by default. OpenAI's Agents SDK takes a max_turns argument on the runner and raises MaxTurnsExceeded when the agent exceeds it (docs). LangGraph defaults recursion_limit to 25 super-steps and raises GraphRecursionError past that (docs).

Those defaults are the floor, not the design. Three caps belong outside the model entirely:

1. Step cap. A counter in your runner, not a number in the prompt. The run dies at N whether or not the agent thinks it is close.
2. Spend cap. A ledger you write to after each call, with a kill threshold. If the agent touches money, put the limit at the card. Stripe Issuing enforces per-card spending controls at authorization time — the transaction is declined by Stripe, not by your code (docs).
3. Credential scope. A key that can do exactly the one job. A read-only CRM token cannot delete a contact, no matter how the agent is prompted.

The dashed box is the only region where the model has discretion. Every arrow leaving it crosses something you own. If you cannot draw your own system this way — if a cap is a sentence inside the dashed box — you do not have a cap.

Pick a job that produces its own receipt

The single best filter for a first AI-run business: can a machine check the output without a human reading it?

Jobs that fail the filter: "write our content strategy," "find us partnerships," "improve our brand." Not because models cannot produce text about those things — they produce a great deal of it — but because you have no cheap verifier, so quality drift stays invisible until a customer tells you. That is the expensive way to learn.

This is also the best idea filter I know, and it runs in the opposite direction from most startup ideation. Instead of starting from a market, start from a complaint about repetitive work with a checkable output — mining Hacker News complaints works for exactly this reason. Then build the smallest version: one agent, one CSV, one scoring job.

The plumbing costs less than the agent

This surprises people who last incorporated a company a decade ago.

Stripe publishes an agent toolkit that exposes its APIs as function calls, so an agent can create a customer or issue an invoice without you writing a wrapper. The Model Context Protocol does the equivalent job for tools and data sources generally — one protocol instead of a bespoke integration per vendor.

So the fixed cost of existing as a company is $500 plus the first month of tokens. The real cost is attention. Every integration you add is a credential to scope, a failure mode to instrument, and a bill to watch, and I would not add a tool to an agent until the job it does without that tool is already working.

Hosting is the one place where the cheap answer is right. Rent inference, rent the queue, rent the database. Self-hosting becomes interesting when there is a specific reason — data residency, a fine-tuned model, a volume where the arithmetic flips — and not before, a trade-off examined in more detail in what to run yourself and what to rent.

Prompt injection is a business risk, not a model risk

OWASP ranks prompt injection as LLM01 — the top application-layer risk for LLM systems (project page). The framing that holds up in production is Simon Willison's "lethal trifecta": an agent is exploitable when it has access to private data, exposure to untrusted content, and a channel to send data out (post, 16 June 2025). Remove any one of the three and the attack has nowhere to land.

Now read your lead-qualification agent again. It has your CRM. It fetches arbitrary company web pages. It writes to Slack and sends email. All three. A sentence on a prospect's careers page, invisible to a human reader, is an instruction your agent will read with the same weight as your system prompt.

There is no prompt that fixes this. The fixes are architectural: strip the outbound channel from the agent that reads untrusted pages, pass results to a second process that has no network access, or keep the private data out of the context of the agent doing the fetching. The design question is not "is the model safe." It is "which of the three does this agent get to have."

What you cannot delegate yet

Spend authority. Pricing. Signing anything. Telling a customer something that is not yet true. Deciding to fire a customer. These are not technical limits, and a better model will not solve them, because the failure cost is asymmetric and lands on you.

There is also a quieter one. Under the API terms, you own the output your agents produce — OpenAI's business terms assign customers ownership of outputs. Ownership is not copyright. The US Copyright Office's position is that copyright protection requires human authorship, and that purely machine-generated material does not qualify (copyright.gov/ai). So if your plan is "generate 10,000 pages of content and defend the asset," you do not have an asset.

Which pushes the moat somewhere else. The defensible part of an AI-run company is not the prompt, the model choice, or the generated output. It is the verified workflow — the job you have run ten thousand times, with a verifier that catches the 3% that go wrong, and a customer who has stopped checking because you have earned it. That takes production time. You cannot generate it. What stays human is mostly the part that earns the trust.