OpenAI shipped AgentKit as a full toolkit for building, deploying, and optimising “agents”, complete with a visual workflow designer. Pocock’s reaction: the flagship example is not an agent at all, and that mislabelling is worth unpacking.
Agent vs workflow: the Anthropic definition
The whole discussion traces back to Anthropic’s December 2024 article Building Effective Agents, which is where these two terms got pinned down. Anthropic defines an agent as a loop, and a workflow as a set of predetermined code paths, a directional flow through steps that are known ahead of time. Pocock’s dig is that a famous article titled “Building Effective Agents” actually spends most of its length walking through roughly six different kinds of workflows.
The AgentKit demo lands squarely on the workflow side. It runs a fixed sequence: start, pass through a jailbreak guardrail that filters malicious input, then an LLM call that routes the request to one of three downstream agents. Every branch is decided in advance and written in code, so by the Anthropic definition it is a workflow with an agent-builder label on it. Pocock’s frustration is that the TypeScript-flavoured AI-engineering community had, he thought, converged on these definitions, and OpenAI is now shipping a different one under the same word.
The agent loop: tool calls are what make it agentic
An agent is a loop of multiple LLM calls where the LLM itself decides when to stop. The catch is that calling an LLM repeatedly with the same information does nothing useful, so each turn has to feed it something new, and the mechanism for that is tool calls. A tool call is the model saying “run this piece of code for me and tell me what happened”, and the result flowing back in is the new information that makes the next turn worthwhile.
The concrete example is a writeFile tool.
The user asks the agent to create a .gitignore; the assistant replies with a message asking to call writeFile with a given path and content; the system executes the tool and sends the result back to the model.
That handoff is what closes the loop, and repeating it is exactly what drives coding agents like Claude Code.
The agent keeps calling tools until it decides it is finished, at which point it emits a stop token that the front end catches so it stops re-invoking the model.
Workflows have no such loop. They are LLM calls chained one after another, optionally with deterministic branching (if the call returns X do one thing, if Y do another), but every path is known up front and lives in code. That predictability is their strength: because the route to the answer is fixed, you can optimise it, for example fanning out parallel calls that summarise separate chunks of text and then summarising the summaries. Pocock, self-described contrarian, says if he could keep only one he would take workflows.
Why the distinction matters: matching pattern to problem
The definitions earn their keep by telling you which architecture fits the job. Two entry requirements first: you need multiple LLM calls to qualify as either, since a lone call is “just a freaking API call”, and the real dividing line is who decides when to stop, the LLM (agent) or the predetermined steps (workflow).
Agents win when the path to a solution is unclear or has to generalise across many tasks. Coding assistants are the canonical case: Claude Code or Cursor cannot know which codebase or which bug they will face, so they have to improvise on the fly. Workflows win when the path is known and you need to do the same thing a thousand times, because you can optimise the fixed setup instead of leaving optimisation to the model. Pocock’s framing: agents are jazz, all improvisation and feel; workflows are classical music, where you tune the upfront arrangement until the output is as good as it gets.
In practice the two are a spectrum, not a binary, and most real systems sit somewhere on the gradient:
- A pure agent would run forever, so nearly all agents add a deterministic
max stepscounter (Google’s ADK exposes exactly this parameter) to break the loop from the code side. - Agents commonly call workflows from inside their tools, combining an agent’s generalisability with hand-optimised tools.
- Workflows can contain loops, such as generate-then-evaluate refinement; the tell is whether the LLM can break the loop early (agent) or not (workflow).
The value is having shared patterns to reason about trade-offs, which is why watering the word “agent” down to mean any multi-step system bothers Pocock as a teaching tool. His hope is that the Anthropic definition, “tool calls in a loop”, is the one the field settles on.
Key takeaways
- An agent is a loop of LLM calls where the model decides when to stop; a workflow is predetermined steps written in code.
- Tool calls are the mechanism that makes a loop agentic: they feed the model new information each turn (the
writeFileexample). - The real dividing line is who controls the stop condition: the LLM (agent) or the code (workflow).
- Fewer than two LLM calls is neither; a single call is just an API call.
- Agents suit unclear, general, improvisational tasks; workflows suit known, repeatable paths you can optimise (e.g. parallel calls).
- Real systems live on a spectrum:
max stepscaps on agents, workflows inside agent tools, loops inside workflows. - OpenAI’s AgentKit demo is a workflow by Anthropic’s definition, which is why the loose use of “agent” matters.
Sources
- Watch the video: youtube.com/watch?v=AtYtuVTZCQU
- Full transcript: what-are-ai-agents
- Related: agentic-engineering-workflow
- Related: how-llm-tokens-work