AI agents for a startup: what to automate before you hire

The short answer: automate the recurring, text-shaped, reversible work — inbound triage, research, first drafts, follow-ups, reporting — and keep a person on anything that commits the company. Do it in that order, one job at a time, starting with whichever one is currently done late or not at all. The mistake is not automating too much; it is automating something nobody was going to do anyway, which produces output nobody reads.

The test for whether a job is ready

Three questions, and it has to pass all three:

1. Does it recur? A one-off does not repay the setup. If it happens weekly, it qualifies; daily, it is urgent.
2. Is the output text, or a decision expressible in text? Research, drafts, summaries, classifications, replies. Not "make the product better".
3. Is a wrong answer recoverable? A bad draft costs a minute. A bad wire transfer does not. The recoverable half is where you start, and it is most of the hours.

What actually gets handed over first

Across the startups we see, the same five jobs come up, roughly in this order:

• Inbound triage. Enquiries, support, and the shared inbox. An agent reads everything, classifies it, drafts a reply, and escalates what it should not answer. The founder reviews a queue instead of a stream.
• Prospect research. Not scraping a list — reading a company's site and working out what they actually sell, so outreach is specific. This is the job where an agent's tirelessness beats a human's, because the work is dull rather than hard.
• Follow-ups. The revenue that leaks at seed stage mostly leaks here. Nobody forgot on purpose; there was just no one whose job it was.
• Recurring reporting. The weekly numbers, the investor update draft, the pipeline summary. Assembled overnight, edited in the morning.
• Document drafting. Proposals, scopes, first-pass answers to a customer's security questionnaire — see selling to enterprise buyers for why that last one eats a week you did not budget.

What to keep away from it, for now

Not because an agent cannot do these, but because at seed stage the cost of being wrong is asymmetric:

• Anything that spends money. Payments, procurement, ad budgets. The approval boundary belongs here even when the agent is right every time.
• Pricing and contract terms. A number an agent invented in a proposal becomes a commitment the moment a customer accepts it.
• The first conversation with a design partner. Early customer development is the founder's job precisely because the value is in what you learn, not in the reply being sent.
• Anything touching hiring decisions. Beyond being a bad idea, it is in scope for several state statutes — see US state AI laws in 2026.

Why "one agent that does everything" fails here specifically

The temptation at three people is to build one agent and keep adding to its instructions. It works for about a month. Then the prompt is two pages, its behaviour on job four regresses when you tune job one, and nobody can say what it is supposed to do.

The alternative is not complicated: one agent per job, each with only the tools that job needs. It also bounds a bad day — an agent that can read the web and write a draft is a different risk from one that can also send mail and touch billing. That argument in full is in multi-agent versus single agent, and the security version of it is in prompt injection containment.

The order that works

1. Pick the job that is currently late. Not the most interesting one. Lateness is evidence that nobody has capacity for it, which means an agent doing it from week one beats the status quo of it not happening.
2. Write down what "done well" looks like in two sentences, before you build. This becomes the thing you check against, and later the thing you evaluate against — see how to tell whether your agent is working.
3. Run it with every output reviewed for two weeks. You are not testing the model; you are finding out what context it is missing.
4. Move the approval boundary once, deliberately. Let the reversible half run unattended. Keep the irreversible half in the queue permanently.
5. Only then add the second job. If the first one still needs daily attention, adding a second gives you two things that need daily attention.

What this does and does not do to headcount

At three people it usually changes when you hire rather than who. The first operations hire happens later and arrives to a company where the recurring work is already documented as procedures the agents follow — which is a materially better first week than inheriting an undocumented mess.

What it does change immediately is what the founders spend Tuesday on. That is the return worth measuring, and it is measurable: pick the number before you start, per how to measure AI ROI. The comparison against an actual hire, with US cost figures rather than intuition, is in hire or deploy.

One thing worth getting right early

Where the agent's context lives. A startup changes tools constantly — CRM at six months, billing at a year, a real support desk at two. If each agent's memory, credentials and history sit inside one of those tools, every migration costs you the agent as well. Keeping that state in one place you control is cheap to decide now and expensive to fix later, which is the whole argument in platform lock-in.