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.
On the left is the workflow: a conveyor that carries the email through four stations in the same order every time. A regular expression extracts the order id, find_order and get_refund_policy run as plain function calls, and one model call drafts the reply from both records. Each station's recorded output appears on a tag above it. On the right is the agent loop: the transcript column holds everything sent on each call, as tall as its token count\; the model box carries a call counter against a budget of six and a stop lamp\; the toolbelt lights up with each call the model makes, and the recorded result flies back onto the column. The slates at the front keep each lane's model calls and 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. The column in the film is 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 on the agent’s slate 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 stop lamp shows which one fired. 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.
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.