Scripts, workflows and agents
Tell a script from a workflow from an agent by who picks the next step, and price one task built all three ways, turn by turn, with your own turn count.
On this page
Script, workflow and agent get used as if they were sizes of one thing. They are three answers to one question, who picks the next step, and the answer fixes what a run costs, what can be tested before it ships, and how it fails. In a script the author picked every step in advance. In a workflow a graph picks, branching on the data, and a model may do one step inside it. In an agent the model picks each next step from a list of tools until it decides it is finished.
One task, built three ways
The task is the agency's lead reply from how to use this course, and it has three steps: read the form, look up the customer in the CRM, draft a reply.
The script. Read the form's fields, query the CRM by email, fill a template with the name and the service ticked. No tokens, under a second, and the same output for the same input, so a test can compare strings. It breaks on the part of the task that is text: the lead who writes "we need the new site live before our March trade show, and the last agency missed two deadlines" gets the same template as everyone else.
The workflow. The same three steps as a graph with one branch: read the form, find the customer, and on exactly one match go on, otherwise send the lead to a person's queue. Then one model call drafts the reply with the form and the CRM record in hand. The graph picks the path; the model writes one paragraph.
The call is about 1,700 tokens in: a 1,200-token system prompt (the agency's services, its tone, what never to promise, three example replies), 250 tokens of form and 250 of customer record. The reply is 250 tokens out, about 190 words at 1.3 tokens a word. About 1,950 tokens a lead.
The agent. The model gets the form, a goal ("reply to this lead using what we know about them") and three tools: find_customer, get_history, save_draft, in no set order. A typical run is 8 turns. On the one traced here it searches by email and finds nothing, searches by the company's domain, pulls the history, reads two past projects and the last proposal, saves a draft and confirms it. It can handle a lead the workflow would queue, the prospect whose colleague wrote last year from another address, because it can decide to look again.
The agent's bill, turn by turn
Every turn is a model call, and every call resends everything before it. Turn 1 sends the prefix, which is the same 1,200-token system prompt plus 800 tokens of tool schemas, and the 250-token form: 2,250 tokens in. The model answers with a tool call of about 100 tokens, the tool returns about 200, and both join the transcript, so each turn sends 300 more than the one before.
input on turn n = 2,250 + 300 × (n − 1)
turn 1: 2,250 turn 2: 2,550 … turn 8: 4,350
input over 8 turns = 8 × 2,250 + 300 × (0 + 1 + … + 7)
= 18,000 + 8,400 = 26,400 (3,300 a turn on average)
output over 8 turns = 8 × 100 = 800
total = 27,200 tokens, about 14 × the workflow's 1,950
Re-derive it with your own turn count, T:
tokens per run = T × 2,250 + 300 × T × (T − 1) ÷ 2 + 100 × T
Four turns is 11,200 tokens, about 6 times the workflow; twelve is 48,000, about 25 times. Half again as many turns uses 76% more tokens, because the transcript term grows with the square of the turns, the mechanism taught with a loop's three exits in agent loops and stop conditions.
At the assumed $2 per million input tokens and $8 per million output, the workflow costs (1,700 × $2 + 250 × $8) per million = $0.0054 a lead, and the agent (26,400 × $2 + 800 × $8) per million = $0.0592. At 400 leads a month that is $2.16 against $23.68. Against the $2,000 a person costs, neither figure decides anything.
What the 14× actually costs
The token multiple is the visible cost and the smallest.
The test. A script's test compares strings. A workflow's model step is tested against a set of cases and its branches like any code. An agent's path changes between runs, 8 turns today and 11 tomorrow on the same lead, so the path cannot be asserted; the test can only accept a set of acceptable outcomes, which someone has to write.
Three failure modes the workflow does not have. The loop: a search for a customer who is not there, repeated in new forms. Tool misuse: save_draft called twice. Spend with no ceiling: by the formula above, a lead that runs to 50 turns costs 480,000 tokens in and 5,000 out, about $1.00, seventeen times a normal lead. Each needs a cap, and the caps are code the workflow never needed.
Accountability. In the workflow a wrong branch is a bug in a graph someone drew. In the agent the model chose, and the trace is the only record of why.
What the agent buys is the leads the graph cannot route. One lead in ten matches no customer by email, 40 a month. If half are known under another address, the agent saves a person 20 × 6 minutes = 2 hours, $60 a month, for $21.52 more in tokens and three failure modes. The temptation is to build the agent. The cheaper fix is one more node in the workflow: no match by email, search by domain, then branch. It catches most of the 20 for no extra tokens, and the graph stays testable.
Choosing who picks
Give each step to the cheapest picker that can make it.
- A script when the input is structured and the output is fixed: copying a form into the CRM.
- A workflow when the steps are known in advance and one or two need judgment on text: the lead reply.
- An agent when the next step depends on the last result in a way you cannot list before the run: reconciling a payment that matches no invoice, where each search decides the next. Then cap it: turns, spend, and an exit to a person.
The course's ladder is this distinction in tools: three rungs of workflows, a fourth that hands the model the loop inside caps you set, and a fifth, the harness, that wraps the model's judgment back inside steps code picks. Why a maturing product moves its loop into code is five eras, one ladder in the developer's course. Whichever picker you choose, the virtual employee frame turns it into a role someone can manage.
In practice
When a vendor demonstrates "an agent", ask who picks the next step and what stops it: the turn cap, the spend cap per run, and where a capped run goes. Ask for turn counts across a hundred real runs, since the average hides the long runs that set the bill. With your own team, draw the graph first; if you can draw it, build the workflow.
The mistake that costs money is building an agent for a task whose graph you can draw. It pays 14 times the tokens on every run, adds three failure modes the graph did not have, and leaves a test suite that cannot assert the path, all to make decisions a branch would have made for free.
Check yourself
1. The lead agent averages 12 turns, not 8. What does a month of 400 leads cost, and does it change the decision?
12 × 2,250 + 300 × 66 = 46,800 tokens in and 1,200 out: $0.0936 + $0.0096 = $0.1032 a lead, $41.28 a month, 74% more for half again as many turns. Against $2,000 that changes nothing on its own; what decides it is whether the extra turns find customers the workflow would miss, or loop.
2. The weekly client report pulls figures from six dashboards and writes three paragraphs per client. Script, workflow or agent?
A workflow. The six reads are fixed steps in a known order, and the only judgment is the summary, one model call per client. An agent would spend turns choosing the order of six reads that never changes.
3. About 15 payments a month match no invoice, and the operations manager spends 12 minutes on each one. An agent that searches by amount, client and reference would take 16 founder hours to build. Build it?
No, and the decision comes from the sums, not from who picks. Sum 1 is 15 × 12 = 180 minutes, 3 hours × $30 = $90 a month. The build is 16 × $100 = $1,600, so even at zero run cost the payback is 18 months, past a 12-month life. The task suits an agent; it does not pay for one.