A fixed workflow and an agent loop are the two basic shapes of an application that gives a language model tools. In a workflow, code decides the steps and their order, and the model is called at fixed points. In an agent loop, the model decides: it reads everything so far, picks the next tool, reads the result, and goes round again until it chooses to answer. The film runs the same task through both, side by side on one bench.
The task is a real support email to a kitchenware shop: order A-2207 arrived and the blender jug is cracked, can I get a refund. The tools are three real functions over a small order table and a policy table: find_order, search_orders and get_refund_policy. The policy is keyed by a category code that appears only on the order record, so the order has to be looked up first. Every run was recorded on 11 September 2026 with `google/gemini-3.8-flash` through OpenRouter at temperature 0, with a real tools schema, three runs per lane per condition, and every run agreed on its path, its model calls and its tokens sent.
Along the top are the people and things involved: the developer who wrote the workflow, Maya and her email, your application, the model and the three tools your code can run. Below them, side by side, are the two lanes as TypeScript. On the left, workflow.ts runs line by line through a typed pipeline of four steps, extractId, findOrder, getPolicy and draftReply, with each step's recorded output under the code and the outcome below it. On the right, agent.ts is a while loop: it calls the model with every message so far and the tools, runs whichever tool the model picked, appends the call and its result, and stops on a reply or when the budget of six calls is spent. The model's real choices arrive as it makes them, and the conversation it resends grows underneath. Each lane counts its model calls, one bar per call as tall as the tokens it sent, and its total tokens sent. When the film is paused, the pills above it show either lane finished under any of the three conditions.
On the happy path both lanes send the same reply in substance: a full refund or a free replacement with no return postage, and a request for a photo of the damage. The workflow made one model call on 211 tokens. The agent made three calls and sent 896, because every call resends the rules, the tool definitions, the email and every result so far. It made exactly the choices the workflow hard-codes, so the extra cost bought nothing. It also waits on three calls in sequence rather than one.
Take the order number out of the email and the picture turns round. The workflow's first step finds no id and stops, which in a real system means a person picks it up. The agent searched the customer's orders by email, saw a blender and a kettle, chose the blender, the item the email mentions, and replied in four calls and 1,354 tokens. This is the case a loop is for: an observation changed the next step. If requests like this are common and a person's time is expensive, the loop pays for itself\; if they are rare, a workflow with a hand-off is cheaper and easier to test.
The failure mode is the runaway. When the policy service times out on every call, the workflow stops at that step and hands off at once, having spent nothing on the model. The agent asked for the same policy five times, each call longer than the last, and stopped only because the harness allowed six model calls: no reply, 2,159 tokens sent. The loop's only natural stop is the model choosing to answer, and a result that says it can be retried gives it no reason to. Give every loop a step budget, and add stop conditions that the model does not control: a retry limit per tool, a check for the same call repeated with the same arguments, errors that say plainly not to retry, and a route to a person when any of them fires.
The honest caveat is scale. This is one email, three tools, one model and three runs of each, and the workflow's regular expression is deliberately simple. The token counts are the provider's own. The model's reasoning tokens are mandatory on this endpoint and varied from 0 to 487 between identical runs, so the film counts model calls and prompt tokens sent, which did not vary. Latency was not measured, and a budget of six is a choice for the film, not a recommendation.
The maths
- Every call resends the transcript
P_k is what call k sends: the opening P_1 (rules, tool definitions and the email) plus every earlier tool call and result r_j. Each request in the film carries P_k. On the happy path the agent sends 229, 306 and 361 tokens, so S is 896, against 211 for the workflow’s single drafting call.
- A retry loop grows with the square of its length
In the runaway every timeout adds about 40 tokens to the transcript, so each retry costs more than the last: 229, 306, 346, 386, 426 and 466 tokens, 2,159 in all. The bars in the agent’s call meter are the P_k, and they climb.
- What stops the loop
The loop ends when the model answers without calling a tool, or when the budget B of model calls is spent. The film shows which one fired: a reply sent to Maya, or the budget’s stop. In the runaway the model never chose to answer, so only B stopped it.
- When the loop earns its cost
q is the share of requests whose next step depends on what a tool returns (here, an email with no order id), H is what the workflow’s failure costs (a person handling the email), and the right-hand side is the loop’s extra spend. When q is small, the workflow with a hand-off to a person is the cheaper design.
Transcript
The narration, chapter by chapter. A timestamp opens the film at that moment.
- 0:00Two lanes
- One refund email can go down two lanes: a fixed workflow that runs the same four steps in the same order every time, or an agent loop, where the model picks each next tool from what the last one returned.
- 0:14Happy path
- Trace the happy path, where the email names order A-2207: the workflow looks it up, fetches the refund policy and makes one model call on 211 tokens, while the agent takes three calls and 896 tokens to reach the same answer.
- 0:31Known steps
- The part people miss is where those tokens go: every agent call resends the email, the tools and each result so far, so when the steps are known, the loop pays four times as much to make the choices the workflow already hard-codes.
- 0:47Missing order id
- Now take the order number out: the workflow's first step finds no id and stops, but the agent searches by Maya's email, sees two orders, picks the blender and replies in four calls, because what came back changed its next step.
- 1:02Runaway
- Here is the failure mode: the policy service times out on every call, so the workflow stops at that step and hands off at once, while the agent calls the same lookup five times, each call longer than the last.
- 1:16The budget
- Only the budget stops it, at six calls, with no reply and 2,159 tokens sent, because the loop's natural stop is the model choosing to answer, and a timeout that says it can be retried never gives it a reason to.
- 1:32What to keep
- So use a workflow when the steps are known, and a loop only when what comes back decides the next step, with a budget, a stop condition and a person to hand off to.
Also available as captions (WebVTT), the video file and a Markdown copy of this page.
Related terms
- AgentAn agent is a language model wrapped in a loop that lets it call tools, read the results, and decide what to do next. The model supplies the judgement; the loop and the tools give it hands.
- HarnessThe harness is the code wrapped around a model that builds requests, runs tools, manages context, and enforces permissions. It is the agent minus the model, and it is where most of the real engineering lives.
- Tool callA tool call is the model’s request to use a tool: it names the tool and supplies the arguments, then pauses. It has not run anything. Your harness is what actually executes the action.
- TurnA turn is one round of the agent loop: your input, the model doing its work (possibly several tool calls), and its response. A single turn can span many provider requests.
- Human in the loopHuman in the loop means keeping a person in the agent's decision path to approve, steer, or verify its work. It is the deliberate counterweight to full autonomy.
More visualisations
Embed this film
Paste this into a post, a course page or a newsletter. The film plays in place, with the same controls as here, and credits the source.