Start from a process that already exists

The best first agent automates a task someone on your team already does every week, by hand, with a result you can judge. You know the steps, you know what a good output looks like, and you have a baseline to compare against. An agent built on a process nobody runs yet has none of that: when it fails, you can’t tell whether the agent is wrong or the process is.

So before writing a single instruction, I do three things: pick the task, write down how it’s done today, and define what done means in terms a checker can apply.

Pick a task with a scoring grid

Score every candidate task from 1 to 3 on five criteria, then add up. Anything above 12 is a good first agent.

Criterion	1	3
Frequency	A few times a year	Every week or more
Volume per run	One item	Dozens or hundreds of items
Checkable output	Only an expert can tell	A rule or a sample tells you
Cost of an error	Public, expensive, hard to undo	Caught before it leaves the building
Existing know-how	In one person’s head	Written somewhere, even badly

Say you sell payroll software to French SMEs and your SDR spends every Monday morning qualifying last week’s free-trial sign-ups: checking the company, guessing the size, deciding who deserves a call. It’s weekly, it’s 50 to 100 rows, a sales lead can judge a sample in ten minutes, and a wrong label means a missed call rather than a public mistake. That scores high.

Writing your LinkedIn posts scores lower on “cost of an error”, because everything is public. It can still work, as chapter 16 shows, but it needs more checks than a first project should carry.

If you don’t know which task to pick, look for the bottleneck. The method in finding the funnel bottleneck applies here: automate where time is lost on the stage that limits growth.

Write down how it’s done today

Sit next to the person who does the task, or record a session, and write every step as they actually do it. Not as the process document says. The gap between the two is where the agent will fail.

For each step, capture five things: what comes in, what they look at, what they decide, what goes out, and the exceptions they handle without thinking. The exceptions matter most. “If the email is a Gmail address, I look the person up on LinkedIn” is exactly the kind of rule nobody writes down and every agent needs.

Here is what that sheet looks like for the sign-up example.

process: qualify_trial_signups
owner: SDR team
frequency: weekly, Monday
input: signups.csv  # email, name, company field, signup_date
steps:
  - id: 1
    do: Get the company domain from the email
    exception: free email provider -> search the name + company field
  - id: 2
    do: Look up headcount and country from a company data source
    exception: no match -> mark "unknown", never guess
  - id: 3
    do: Check the ICP (France, 10 to 250 employees, no payroll provider in-house)
    decision: fit | maybe | no_fit
  - id: 4
    do: Write one line on why
output: signups_qualified.csv  # adds fit, reason, source_url
time_today: about 2 hours per week

Notice what’s already in there: where facts come from (a data source, never memory), the unknown escape hatch, and the time it takes today. That last line is your baseline. Without it, you will never know whether the agent saved anything.

Then cut the steps by the tool each one needs, as described in the tools chapter. In this example step 1 is a script, step 2 is a data tool, and only steps 3 and 4 need a model.

Define what done looks like

“Qualify the sign-ups well” gives a checker nothing to apply. Write a definition that a checker, human or machine, can apply without asking you.

Write it in three layers.

Layer	Example	Checked by
Format	Every row has fit, reason, source_url; fit is one of three values	A script
Content	reason cites a fact found in the source, not a guess	A reviewer or an independent judge
Quality	On a 30-row sample, the sales lead agrees with at least 27 labels	A person, every week at first

The numbers in the third line are yours to set, before the first run. If you set them after looking at results, you’ll set them to whatever the agent achieved.

Collect real examples now, too: five rows labelled correctly, and three rows where a hurried person would get it wrong. These become the examples in the instructions file, covered in the next chapter, and later the frozen test cases you rerun after every change.

Keep the human steps where they are

Mapping the process also shows you which steps should stay human. In the outbound plugin I published for Claude Code, the flow follows the steps any outbound person already does: import, enrichment, message, sequence, push, then a weekly review of replies. The agent does most of them. For the sequence, it advises on structure and delivers the content, and the person builds the sequence in their sending tool. The push has a check that refuses to overwrite a lead already in an active campaign. Each of those choices answers the same question: what does an error cost at this step, and who would notice it?

Do the same on your map. Mark each step “agent does”, “agent proposes, human approves” or “human only”. Start with more approval than you think you need, and remove it when the weekly sample stops finding mistakes.

Decide in advance when to stop

A done definition also needs a failure condition. Write down what would make you stop: the sample agreement stays under your bar after three weeks of fixes, or the time saved is eaten by reviewing. Stopping is a valid outcome. On Derrick’s marketing, which runs on agents (I co-founded Derrick), a Reddit lever was started and then cancelled in October 2026. A stop is easy to accept when the grounds for it were written before the start.

Your next step: score three candidate tasks with the grid, take the winner, and write its process sheet and its three-layer definition of done. Time the next manual run, so you have a baseline before the agent exists.