Model, application, workflow, agent: who decides what happens next

A language model does one thing: given a sequence of tokens, it produces a next token. Everything that looks like a decision — calling a tool, writing a row, sending a message, choosing the next step of a task — happens outside it, in code someone else wrote. This sheet is about who chooses that next step. The model produces text; the application around it parses that text, decides what it means, executes the call and feeds the result back. And the shape of the control — a workflow, whose sequence is fixed in code, or an agent, which lets the model choose the next step inside a loop — is the developers’ choice, not the model’s.

The mental model: one model call, inside an application

application  (the code the developers wrote)
  |
  +-- builds a request and sends it to the model
  v
model  (the weights)  ->  returns text
  |
  v
application again:
  parse the text  ->  is this a tool call? which tool? which arguments?
  ->  execute it, or refuse  ->  feed the result back as new input

The application always drives: the model is called with text and returns text. The vendor documentation treats tools as functions the surrounding system offers — “External functions or APIs the agent can use to take action” — and describes the model’s output as a block inside a response: “When Claude responds, it will include a tool use block in the API response if it plans to invoke a tool.” Planning to invoke a tool and invoking it are two events, in two systems.

Terminology the reader needs

• Model call — one request to the model and one response from it.
• Application (also the harness or agent framework) — the program that builds the request, reads the response, decides what it means and executes tools. (model-runtime-and-application uses the same word for the product or API layer that wraps the engine; the two roles are often the same program, but that sheet’s layer and this sheet’s decision-making code are not the same thing.)
• Tool — an external function or API the application exposes to the model, so it can gather context and act in external systems.
• Workflow — a system “where LLMs and tools are orchestrated through predefined code paths”.
• Agent — a system “where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks”.
• Loop (a run) — the model called, its result fed back, called again, until a condition is met.

Who chooses the next step: workflow or agent

WORKFLOW — the sequence is fixed in code
  step 1 --> step 2 --> step 3 --> done
     |          |          |
   model      model      model
  (the model fills each step; the code decides which step is next)

AGENT — the repetition is fixed; the next step inside it is not
  +-----------------------------------------------+
  |   model -> text -> application parses/executes |
  |      ^                              |          |
  |      +---- result fed back <--------+          |
  +-----------------------------------------------+
        repeated until an exit condition is reached

A workflow uses the model too; the difference is not whether a model is involved but who sequences the steps. In the workflow the order is written in code before anything runs. In the agent the order is decided at run time: the model proposes the next action, the application carries it out and hands back the result, and the model proposes again. The two vendor guides say almost the same thing — an agent “leverages an LLM to manage workflow execution and make decisions” and “dynamically selects the appropriate tools depending on the workflow’s current state” — but OpenAI uses the word for the task’s own sequence of steps: “A workflow is a sequence of steps that must be executed to meet the user’s goal” (line 43). “Manages workflow execution” there means the agent sequences the task, not that it follows a predefined path. Anthropic is blunter: agents “are typically just LLMs using tools based on environmental feedback in a loop”.

The loop, and what stops it

A loop a model partly drives needs an exit, and the exit is code, not the model’s judgement. OpenAI’s guide calls the while loop “central to the functioning of an agent”, and describes it ending either when a “final-output tool is invoked” or when the “model returns a response without any tool calls”. Anthropic’s guide adds the ceiling: “The task often terminates upon completion, but it’s also common to include stopping conditions (such as a maximum number of iterations) to maintain control.” Each of those — completion, a maximum number of turns, a human checkpoint — is a decision the application makes, and (in my reading) the place where accountability for the run sits.

One comparison: the same model in three shapes

Shape	Who fixes the sequence	What the model contributes	How it ends
Single model call	nobody — there is only one step	text, once	the response arrives
Workflow	the code, before the run	text for each fixed step	the last step runs
Agent	the application’s loop, at run time	the choice of the next step, repeatedly	an exit condition in code (done, no tool call, max iterations, human)

The table is not a ranking: the guides recommend the simplest thing that works and an agent last — reduce complexity first, “add multi-step agentic systems only when simpler solutions fall short”, and reserve an agent for work that resists fixed rules, where “a deterministic solution may suffice” otherwise.

Limits, and the common conceptual error

The error sounds like this: “the model called the API.” It did not. The model produced text — including text naming a function and its arguments — and the application parsed it, decided what it meant, executed the call and returned the result. Nothing moves unless the application moves it.

The corollary is what survives into operations: because the executing code sits outside the model, so does responsibility for the action. The developers decide which tools exist, which arguments are acceptable, and when the loop runs. That reading is my own framing; the sources establish the mechanism, not the conclusion. The consequences — a model steered into naming a tool it should not — belong to permissions, sandboxing and prompt injection, named here only as the next level (L4).

Level and prerequisites

L1 — the decision locus only: who chooses the next step, and why a model’s output is a proposal rather than an action. No procedure, no setup, no configuration. Prerequisites: none. The model/runtime/application execution stack is a sibling sheet (model-runtime-and-application), the structure of prompts and messages another (prompts-system-instructions-and-messages), the nesting of AI, machine learning, deep learning and LLM a third (ai-machine-learning-deep-learning-and-llm); none is published yet.

Where to go next

• Automation & AI — the area this sheet belongs to.

References

• Anthropic, Building effective agents (Anthropic engineering article; local evidence file anthropic-building-effective-agents.html) — the workflow/agent distinction, why an agent suits open-ended problems, the loop and its stopping conditions, and the note that a model’s response carries a tool-use block rather than an executed call.
• OpenAI, A practical guide to building agents (OpenAI PDF, page 4 “What is an agent?”, page 5 “When should you build an agent?”, page 7 “Agent design foundations”, page 13 “Orchestration”) — the same distinction from a second vendor: what an agent is, when to build one, the model/tools/instructions components, the while loop and its exit conditions, and agents as tools.