How to design an AI agent

Who the fuck wants to pay for your platform when $200 already buys Claude Max or Codex?

The labs sell the intelligence. They train it, they serve it at a scale you’ll never match, and it improves every few months whether you did anything or not. Your agent sits on top of theirs with a persona, tuned prompts, a tool list, some skills, and a private method for assembling context.

However real that work is, the customer can’t perceive its value when all they can see is a better chatbot.

Every agent launch collapses into the same claim: it can research, browse, write, code, and take actions for you. A team spends months on prompts and evals, and the customer sees another chat box wired to the same models everyone else uses. Then the lab ships an upgrade and the difference is gone. Jasper, the AI copywriting company, raised $125 million at a $1.5 billion valuation as the best way to make GPT-3 write marketing copy. Forty-three days later, OpenAI released ChatGPT for free, and within a year Jasper was laying people off.

People aren’t refusing to pay because the agents are weak. They’re refusing because they can’t see what the extra subscription buys.

The way out of this trap is a mental model I’ve been using for months, and it fits in two words: every agent is a mind and a body. In this post I'll show how you can look at any agent product and see what it’s actually selling, or start from a problem and design backward to the thing that would solve it.

1. Capability has no shape

There’s a trap almost every agent builder falls into, because the models make it so easy: the platform can suddenly do anything. The agent writes code, so it can iterate its way toward almost any goal you hand it, hill-climbing on its own output. It feels like the product just became infinitely capable — and it helps nobody, because the customer has no way to see what any of it is for.

The capability leaks out of every container you put it in. WHOOP’s coach runs on OpenAI’s models and will write you Python if you ask nicely. Your customer-support agent will happily answer high-school trigonometry. A product whose walls all leak has no shape, and that’s the precise problem: pure capability is cognitively illegible.

Nothing marks where an agent like that starts or stops working, and nothing that happens afterward visibly belongs to it. Adding tools widens the claim without making the product any easier to understand.

Normal software gets its shape from its edges. A CRM holds contacts, companies, deals, and follow-ups, so you know which part of your business it represents and what you’re trusting it to maintain. Same with an IDE: files, symbols, errors, builds. The edges are what let you see the thing.

An agent with code execution and fifty integrations has no edges. The customer can’t tell which records belong to it, what it’s supposed to notice on its own, or what it’s allowed to change, and until those relationships get concrete, the product stays a cloud of capability.

Hidden configuration makes the problem worse. The customer can’t inspect your system prompt, and they’ll never feel the months you spent refining skills or the ten percent your context selector gained on some eval. What they perceive is the structure all that machinery operates inside. When there’s no structure, the work disappears behind the model.

2. The body

So what do the few legible agents have that the clouds of capability don’t? They have structure the intelligence lives inside. That structure is what I call the body.

A body is functional tissue with reduced degrees of freedom: specialized capability organized into a unit that begs for an intelligent controller. The reduction is the point. A well-built body narrows the mind’s possible moves until the job becomes obvious and almost any competent model can do it. When the body is missing, every mind ends up demonstrating the same unbounded tricks.

What goes into one? An identity, first: a name, a domain, an address the world can use to reach this thing and no other. Then property: money in an account, rows in a database, records that are still there tomorrow. Then contact with reality: an inbox, a sensor, a feed, somewhere events arrive whether or not anyone is prompting. And limits: spending caps, approval rules, permissions that make a thousand separate model calls behave like one accountable thing. Each piece is boring on its own. Together they give broad capability a place where its work begins, accumulates, and gets answered for.

The pieces organize the way tissue does. Related parts group into organs: the inbox, the records, and the rules of one function working together. Organs compose into systems. A mature organ even carries its own cached procedures: workflows that fire without the mind ever waking up, or a standing agent call that the organ schedules on its own. Seen this way, the mind’s job is smaller than it looks: it supplies the control and the interpretation, while the body handles most of the running on its own.

The product is the union of a mind and a body that understand each other: the body decides which context, events, and resources reach the mind, while the mind knows the body’s parts well enough to coordinate them. A skill is that mutual understanding, written down.

The founder who taught me to trust this frame runs an established company that services restaurant kitchens: hundreds of restaurant accounts, machines with sensors on them, a fleet of trucks, human technicians, warehouses full of parts. He asked me how to add AI to that without becoming “just a GPT wrapper,” and the plan on the table was what the plan always is: a chatbot over the company’s data.

Through the mind-and-body lens, his question almost answers itself, because this company owns more body than any AI startup I’ve met. A walk-in fridge that’s been drifting warm for three days is an event, arriving from a sensor the company already owns, about a machine whose repair history the company already holds. An agent living in that body can catch the drift, check the compressor’s history and warranty, order the part, put a technician’s truck on the route, and bill for the save, and the restaurant pays happily, because the alternative was a weekend of spoiled inventory. Every kitchen could run as its own small body: equipment records, maintenance history, a dispatch channel, a budget with a limit. The truck fleet is another body. The parts warehouse is a third. There’s a product inside each of them, and not one is a chatbot. The intelligence was the easy part. What he needed was to organize what he already owned into bodies that intelligence can inhabit.

3. Coding agents have a computer as a body

Claude Code and Codex feel more substantial than most agents because they enter a body that already exists: the computer.

The model works inside a file system, among running processes, installed programs, credentials, and repositories. The project lives outside the context window, so the model doesn’t have to hold it all in its head. Git remembers every decision anyone ever made, and when the model edits a file, the tests come back within seconds to say whether the edit worked.

A shell command means something here because it runs in a directory, under an identity, against files that have a history. The same Bash tool in a blank chat is just another capability on a list.

The boundary is what makes the intelligence legible: you can see the agent working on this repository, trying to make these tests pass, and you can read the diff it leaves behind.

Coding agents inherited all of it from fifty years of software engineering. Git alone is twenty years old, and GitHub holds over six hundred million repositories for the minds to walk into. Every other domain is still waiting for somebody to build the equivalent.

4. A business as an agent body

Coding agents got their body for free. The more interesting move is building one on purpose, and the clearest case is a business.

A business body is a business made legible enough for intelligence to operate. It holds a domain, products, customer records, a support inbox, payment accounts, a codebase, deployments, and a ledger. These aren’t integrations hanging off an agent: they belong to one business, they refer to one another, and they carry obligations that outlive the current model call.

A skill becomes more than advice only when it has a body to act through. A model can know your refund procedure perfectly and still be useless: it needs the order record to tell whether this customer is eligible, the policy on that product to choose the amount, and access to the account that received the money to send it back. The skill earns its keep by coordinating the parts of this business.

Memory changes the same way. Retrieving old transcripts reminds the model what somebody said. A business needs more than reminders. It needs records it’s obligated to keep: the order status, the amount owed, what it promised the customer, what the ledger says. Those records stay authoritative after the chat is gone, and the next action starts from them.

Constraints make the parts safe to use over and over. A payment account becomes a usable limb once it has a known balance, a spending limit, an approval rule, and a history behind it. Every model call passes through the same limits, which is how a hundred separate calls still add up to one accountable business instead of a hundred temporary agents with unrestricted access to money.

Without a body, a skill is advice, memory is a pile of text, and an autonomous loop can burn tokens forever without leaving the product any better than it found it.

A failed payment shows the whole thing running. Stripe fires an event whether or not anybody has a chat open, and the event creates an obligation for this business. The agent reads the customer’s history and the company’s policy before it decides: retry the charge, offer a grace period, send a message, or hand it to a person.

Whatever happens next comes back to the same body. When the customer updates their card, the obligation clears, the ledger picks up the change, and the follow-up cancels itself. Nobody has to reconstruct the situation in a fresh chat, because the records already hold it.

The model already knows what a failed payment is, and Stripe already exposes the API. The valuable part is the business sitting around them — the thing that receives the event, knows which relationship is at risk, and carries the result forward through accounts it owns.

A prompt tells the mind what to do; a webhook lets the body receive reality without being prompted.

You can watch pricing change when the body is present. Intercom’s Fin answers support conversations inside Intercom’s own helpdesk, using its inbox, its conversation history, and its knowledge base, and charges $0.99 per resolution. You can only price the outcome when the outcome lands somewhere you own. A bare chat assistant can’t bill that way, because nothing inside it can say for sure that anything got resolved.

A tutor needs a different structure: a gradebook, lesson history, a calendar, a way to reach the student, and a record of what they can retrieve without help. Each session changes those records, and the records decide what the next session looks like. A word the student keeps missing shows up again next week; a concept they’ve mastered drops out of the queue and makes room for something harder.

That body already exists at scale, and it predates the current models. Duolingo estimates a memory half-life for every word each learner studies and schedules reviews against it. It even treats the push notification as an organ: the company published research on a bandit algorithm it trained across two hundred million notifications to learn when a nudge brings a learner back. When GPT-4 arrived, Duolingo rented it into that body as a premium tier. The lab improves the intelligence; Duolingo keeps the accumulated relationship with fifty million daily learners.

5. How I use this

Deciding what to build

Say a company is drowning in job applications. Calling the solution a “recruiting agent” tells me almost nothing: it names a task, and dozens of models can already read a résumé, compare it to a job description, and draft a polite reply. If that’s the product, the company can get most of it by pasting résumés into Claude.

The useful starting point is the thing that has to keep existing overnight: this company’s hiring pipeline. Somebody has to know which roles are open, who has applied, who’s been screened, which interviews are scheduled, what each candidate was told, and which offers are out. That responsibility doesn’t stop existing when nobody’s chatting with an agent.

Once I name that persisting thing, the rest of the product falls out of it. Applications have to arrive without a coordinator forwarding them, so the pipeline gets an address of its own. Candidate replies come back to the same place. The interview calendar tells it who met whom, and the feedback lands in the record of the candidate it concerns instead of in somebody’s DMs. Now I’m looking at a continuous operation instead of a clever trick with a résumé.

It also needs records somebody can hold it to. Every candidate sits in one of a few states (applied, screened, interviewing, offered, closed), and every promise made to a candidate is written where the next action can see it. Offers get a limit, because the ability to promise somebody a salary is only usable when everyone knows what can go out without a human signing off. When a candidate goes silent, the silence goes into the same record instead of vanishing at the end of a model call.

The first month will be full of exceptions. One candidate applies to three roles at once, another comes through a referral and skips a stage, a third reschedules the same interview four times. As people resolve those cases, the resolutions turn into rules the next candidate inherits, and by month twelve the pipeline knows which sources produce hires, which interviewers never submit feedback on time, and how long each stage really takes, because the company has spent a year hiring through it.

Only then do I have to choose a model, and by this point the choice is almost boring. Several models can read a résumé and apply the rules today, and next year’s models will do it better without me touching the application inbox, the candidate records, the calendar, or the offer limits. I can swap the intelligence precisely because the hiring pipeline doesn’t move.

None of this is a thought experiment. The applicant-tracking systems most tech companies already run, like Greenhouse and Ashby, are exactly this body, built years before the minds were good enough to inhabit it. The AI screening and scheduling features now shipping into them are minds moving into a body that was already standing.

Reading the market

The analytical move is the same decomposition run in reverse. When somebody shows me an agent product, I don’t ask what it can do anymore, because the answer is always the same: anything. Instead I take the product apart. The raw intelligence is rented from a lab. The prompts, skills, and custom code around it are owned, and they’re real work — but a skill is only worth as much as the body it’s written against, and code written against public APIs can be rewritten by anyone renting the same model. Everything that persists or touches reality is the body. So what I’m really asking is: what would remain if a competitor rented the same intelligence and redid the code?

When I split the AI SDR products this way, the result explained a lot. The pitch was an agent that finds leads and writes outreach, and the demos were genuinely good. But the mind was doing almost all of the work: reading a prospect’s website and writing the email is a rented model plus prompts that a competitor could rewrite in a quarter. The body was hard to find. The mail landed in other people’s inboxes. The replies belonged to the customer’s CRM. Even the domain reputation that all that volume was spending belonged to the customer. If I set aside the rented model and the rewritable code, almost nothing remained, and that’s what made the category a bet on the mind. The market noticed before I did. TechCrunch talked to employees at 11x, the most visible startup in the category, and they described customers walking at the three-month break clause of their one-year contracts and churn near 70 or 80 percent; the company disputed the numbers. The mechanism underneath is harder to dispute: when the whole product is interpretation, the customer can compare it against $200 of general intelligence plus a template, and the comparison keeps coming out even.

The same split gives the opposite answer at the unglamorous end of cold email. Instantly and Smartlead sell deliverability: warmed-up mailboxes, domain reputation, suppression lists, inbox-placement testing. There’s barely a mind in these products at all, and the body is enormous. Instantly claims a warmup network of more than a million inboxes generating the engagement signals that keep mail out of spam, and a network like that gets more valuable with every account that joins it, while no model release touches it. The decomposition also predicted what happened next: by 2025, the AI SDR companies themselves were bundling domain provisioning, mailbox warmup, and deliverability monitoring into their products. The companies that had been selling minds were growing organs, because the market had taught them which half of the product customers actually pay for.

So when somebody pitches me an agent, I want to know what remains after I mentally remove the model. Does the company own the inbox, or does it borrow access to mine? Which events reach the product before anyone prompts it? What history gets more valuable after a year of operation? If the model got swapped tomorrow, what would the replacement inherit?

Some answers kill the deal. A prompt, a tool list, and a handful of eval scores are owned property, but they’re the kind a well-funded competitor can rebuild in months against the same rented model — a company holding only those is competing with the lab that supplies its intelligence and with everyone else renting it. A domain with a reputation, a ledger full of open obligations, the operating history of a specific business — that’s something no competitor can rebuild, because it took contact with reality to accumulate.

The reason I keep asking about the body is that the question is so much easier to answer than “what does your chatbot do.” Capabilities blur together; bodies don’t. An agent that can do anything tells me nothing about the product. An agent that inhabits the hiring pipeline of a mid-size company, with its own application inbox, its candidate records, its offer approvals, is something I can picture, price, and compare. Agents become distinguishable the moment you ask what they inhabit instead of what they can do.

The customer pays for the union of a mind and a body that understand each other. The raw intelligence is rented, and every competitor rents from the same supply. The skills and code you write around it are yours, but on their own they’re invisible and rewritable: they become defensible when they’re written against a body only you have. The body is where your agency lives: it’s the part you can build value into, and the value you build there stays yours.

Say the agent is already solved: what body do you want to give it?