What actually eats the time in a first agent build

What this page is, and is not

This is not a study. We have not yet sat a group of beginners down with a stopwatch, and we are not going to publish numbers we have not collected — there is enough invented data in this field already.

What this is: an argument about where the time in a first agent build actually goes, based on the structure of the task and on the platform limits we have verified. When we do run the timed build properly, the numbers go here, including the ones that make us look slow.

The intuition that is wrong

People budget a first build as though the work is the typing. Write some instructions, pick a tool, press go. On that model half an hour sounds generous.

The typing is the fast part. A complete set of agent instructions is a couple of hundred words. If that were the job, a first build would be trivial and nobody would find it difficult.

Where it actually goes

Three places, none of which is the writing.

Finding things in an unfamiliar interface

Connecting the tool is the only step in a first build that is not typing into a box. It is looking for a specific control in a product you have never opened, which is a different cognitive task and an unpredictable one. Quick if the label matches what you expected, considerably less so if it does not.

It is also the step where the vocabulary shifts under you. "Tool" and "capability" get used interchangeably for the same mechanism. Knowing that in advance removes a genuine stall.

The re-runs

This is the big one, and it is structural rather than a failure.

Your first output will be weak, because instructions that seemed precise in your head turn out to have been ambiguous. So you change something and run again. An agent run is not instant — it goes and searches, fetches pages, reads them. You wait through each attempt.

Two or three of those and you have spent more time waiting and reading than you spent writing. That loop is not overhead, though. Read the output, adjust the instructions, run again is the actual skill being learned — the rest is setup. Time spent there is the point of the exercise.

Hitting the per-run ceiling

On Zapier's free plan a single run can use up to 10"activities" before it stops and asks you for input instead of finishing, with 400 a month in total. An activity is the agent reaching outside itself — a search, a page read, an action. Talking to it is not counted.

For a beginner this costs time twice. Once in the run that did not finish, and once in the minutes spent working out whether something is broken. It arrives in exactly the place a result was supposed to appear, so it reads as a crash.

This is avoidable and that is the useful part: a task with no stopping condition — "research thoroughly" — is what pushes a run into the ceiling. Put a number on how many sources to check and the problem largely disappears. Vague instructions are slow in a very literal, meterable sense.

Checked on 23 August 2026 against Zapier's usage documentation. Platform limits move, so treat the date as part of the fact — if you are reading this much later, verify before relying on it.

What we are going to measure

When we run the timed build, these are the numbers we will publish, whatever they say:

1. Wall-clock time per block — deciding the job, writing instructions, connecting the tool, first run, first revision.
2. How many activities one research run actually consumes. Nobody has measured this, ourselves included, which is why no page on this site quotes a figure for it.
3. How many re-runs it takes before the output is genuinely usable.
4. Whether the per-run ceiling gets hit at all on a sensibly scoped task, or only on a deliberately vague one.

The fourth is the one we most want the answer to, because it decides whether the limit is a footnote or a thing every beginner runs into.

What to do with this in the meantime

Budget your half hour with the shape in mind rather than evenly. Spend real time deciding the job before you open anything — it is the cheapest place to buy time back. Expect the tool step to run long. Expect the first output to be weak and treat that as the process working.

And put a number in your instructions for how many sources to check. Of everything on this page it is the smallest change with the largest effect on how long the whole thing takes.

The block-by-block walkthrough has the full sequence and a checklist to work through.