I have built several different kinds of LLM systems: a retrieval system that answers questions over internal documents, a pipeline that turns text into 3D models, and a deep research tool I use myself. Same idea — "let the model do the work" — but all three ended up built differently.
Two questions decide which one you get. First, how much do you hand to the model? Second, once you have handed it over, who owns the loop that drives the next step, and who provides the place where the tools actually run? The first half of this article covers the four levels. The second half covers the four ways to build an agent.
Contents
- The four levels
- Workflow or agent: what actually differs
- Deciding where to stop
- Once you have decided on an agent
- Summary
The four levels
Level 1 means using the chat interface that the provider gives you — ChatGPT, Claude, Gemini — as it is. One person opens it when they need it. That is not worse than the rest; it is a different use. If you are building something that runs on its own, you start at level 2.
The further down you go, the more complex and flexible the thing you can build. It also becomes harder to predict what it will do.
How far you go is set by the requirements. If a single call is enough, stop at 2. If you can write the procedure out completely, stop at 3. Only go to 4 when you cannot. Going deeper is not a promotion. Going deeper removes the ways you had to check correctness before you run it.
Workflow or agent: what actually differs
The boundary between 3 and 4 is where the words get mixed up. Anthropic's "Building Effective Agents" (December 2024) draws the line this way:
Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.
Source: https://www.anthropic.com/engineering/building-effective-agents
This article follows that distinction.
What matters in this definition is not whether the model makes a choice. It is whether the path was written down in advance. So a design where the model picks from a set of options is still a workflow. Classifying an input and sending it to the matching branch is called routing in the same document, and it is counted as one of the workflow patterns, alongside chaining, parallelization, orchestrator-workers, and evaluator-optimizer. The branches are in the code; the model only chooses which one to walk.
Asked as a question to yourself: before you start writing, can you draw every path the execution can take? If you can, it is a workflow. Only when you cannot — when the shape is not settled until you run it — is it an agent.
Whether to go to an agent at all comes down to four checks:
- Is the task too complex to write out as a procedure in advance?
- Is the result worth the time and money it will take?
- Is this the kind of work the model is actually good at?
- With guardrails in place, is handing it over still worth it?
If any one of them fails, stay with the simpler option.
On the fourth one. If the work is editing files, version control keeps a diff, so you can see what happened and roll it back. Sending mail, writing to an external service, charging money, deleting data — none of those can be undone. But "cannot be undone" does not mean "do not automate it." In practice people add guardrails and hand it over anyway: cap the amount, restrict the recipients, stop at a draft and let a human send it, take a copy before deleting.
And guardrails can almost always be added. Put a human review at the end and you can stop anything. So the fourth check is not "can I add a guardrail" but "with the guardrail in place, is it still worth handing over." If a human has to look at everything on every run, there is almost nothing left of the delegation. At that point it is faster to narrow the scope. Carve out the dangerous part so a human presses that button, and what remains is usually small enough that you can write the path out.
I have used Claude Code to build systems that produce slide decks, videos, and 3D models. Those are agent-based systems. The subject matter differs, but in each case Claude Code decides what to do next at run time, and my code does not contain the path.
The borderline case is my own deep research tool. The angles it investigates are fixed; only the depth grows based on intermediate results. The procedure is fully written, but how far it goes changes on every run. The honest name for that is an adaptive workflow, not an agent.
The objection to the dichotomy
There is a fair objection to this line: autonomy is a continuum, and splitting it into two is crude. That is true. You can place any number of stages in between — let the model pick the tool but fix the order, let the model decide only how many times to repeat. The deep research tool above is exactly that.
Which raises a related question. If you keep making a workflow more elaborate, does it eventually become an agent?
No. Agent code is usually simpler than an elaborate workflow. The loop is "when it asks for a tool, run it, hand back the result, repeat" — a few lines. The complexity is not in the code; it is in the plan the model assembles on each run. A tool like Claude Code holds a set of tools, a loop, and context management. The order — read the file, fix it, run the tests — is not in the code. The model decides it every time.
So you cannot draw the line by how much was built. You draw it by whether you can enumerate the paths before running. If you can, it is still a workflow, even with a thousand branches.
Once the line is placed, the reason for placing it becomes clear: what you build, and how it fails, changes on either side.
On the side where the procedure can be written, you can write tests. Inputs map to outputs, so when something unexpected arrives, it stops. Stopping is a good property — it also tells you where to fix.
On the side where it cannot, you cannot write tests. The path differs on each run, so correctness cannot be established in advance. What you need instead is a way to notice afterwards: a visible diff, a way to roll back, a record of what was done. The thing you are building is fundamentally different.
So treating autonomy as a continuum is correct for understanding it, but when you are actually building, splitting once on "can I write the procedure" makes the decision faster. Asking yourself yes or no beats debating where on the continuum you sit.
An agent raises the ceiling when it goes well and lowers the floor when it does not. That is why the fourth check matters. Tests exist, diffs are visible, rollback is possible — where all three hold, you can put an agent in as is. Where they do not, you can still put one in if you can put a floor under the downside. Deciding the size of the worst case in advance is what that floor means.
Deciding where to stop
That is the first half. Which of the four levels you stop at comes out of asking, in order:
Where you stop is what you build. The numbers match the four levels above. Only the last question has a different destination. When guardrails are possible but not worth it, narrow the scope itself. Carve out the dangerous part for a human to approve, and the rest usually becomes small enough to write out — which lands you back at level 3.
The second half only matters if you went all the way to an agent.
Once you have decided on an agent
At this point the work splits in two.
One is using a coding agent directly. You open the Claude Code or Codex command line and drive it yourself. By "coding agent" I mean the kind that runs in a terminal and reads files and executes commands on its own — as distinct from the kind that stays inside a chat window.
The other is building a system for a specific job. A video-production pipeline, for example: you prepare the materials and the sequence, and hand execution to the coding agent. You stop rewriting the same instructions, and you can run it on a schedule.
Either way, running it inside your own subscription is the path of least effort. It is fast to build and the cost stays inside what you already pay.
The place it runs does not have to be your own machine. You can create a session on the provider's cloud and run the same thing there, inside a saved environment configuration (network access, environment variables, setup commands). It frees up your machine, which suits long jobs and jobs you fire off from elsewhere.
Here two separate things come apart: whether it runs locally or elsewhere, and whether you pay a flat fee or by usage. A cloud session runs elsewhere but stays inside your subscription. The four build styles below also cost by usage when run with an API key — but some of them, such as the agent SDK, can run under your subscription's authentication instead. What decides the cost shape is not the build style; it is which authentication you run it with. Mixing the location question and the cost question is where people get confused.
But on your machine or in the cloud, this is only usable by you. Both are tied to your own subscription: anyone who runs it needs their own account and login.
The thing that bites when you distribute is authentication. Running under your own subscription, running under each user's subscription, and running with an API key are all governed differently. Anthropic's SDK documentation, for instance, states that third-party developers may not offer claude.ai login or rate limits for their products unless previously approved. Elsewhere there is documentation describing SDK usage authenticated with a subscription. This is an area where the wording has been changing, so check the current terms before you distribute.
The moment you want several people to use the same system — to ship it, to deliver it to a client, to run it as a service — you have to decide whether to step outside your own subscription.
Everything below is about the outside.
The four ways to build
Outside, the build splits four ways. Three things are being divided up: who owns the loop that drives the next step, who provides the place the tools run, and whether the tools come built in.
| # | Approach (example) | What you write | Why you would pick it |
|---|---|---|---|
| 1 |
Hand-rolled loop you write the loop |
The whole loop: when the model asks for a tool, run it, return the result, call again | You want to decide everything — when to stop, what order, what happens on failure, what gets logged |
| 2 |
Tool runner built into the provider's SDK (e.g. Anthropic's SDK) |
Only the tool bodies; the SDK drives the round trips | You want to limit which tools exist, and to insert approval or failure handling on each turn |
| 3 |
Agent SDK the coding agent's machinery, packaged (e.g. Claude Agent SDK) |
A prompt and configuration; file access, command execution and search are already there | You want to hand over work that involves touching files and running commands |
| 4 |
Managed hand it to the provider (e.g. Managed Agents) |
The agent configuration, which is stored and versioned | You do not want to run infrastructure; you want a fresh environment per run, or a schedule |
SDK stands for Software Development Kit: the set of parts a provider ships so you can call their service from your own program. It saves you writing the transport and the formats yourself.
Seen as a division of ownership:
The execution-environment axis is not about physical location. It is about who provides it and who pays for it. Your own machine, a server you rent, a GitHub runner — if you are the one providing it, they all sit on the same side. Only the case where the provider spins it up and you supply nothing sits on the other side.
The hand-rolled loop, the tool runner and the agent SDK all have one thing in common: none of them provide the place to run. Only managed takes the environment off your hands (and even managed offers a configuration where you host the sandbox yourself). Assuming "if I use the SDK, the environment comes with it" is how the hosting question disappears from your estimate.
Hand-rolled loop vs tool runner: where the line is
The API is the interface you talk to the model through. The SDK is the set of parts that lets you call that interface from your language — the SDK calls the API underneath. So you can use the SDK and still hand-roll the loop. The line is not the tooling; it is whether you write the loop yourself.
Writing it yourself means you decide everything inside it:
- when to stop iterating
- in what order to call
- what happens on failure
- what gets recorded
Riding on a ready-made loop means fitting into its shape. It also avoids depending on preview features, which makes it less likely to break. That said, the tool runner is enough most of the time.
Tool runner vs agent SDK: why not just take the stronger one
The tool runner and the agent SDK both have "SDK" in the name, which makes them easy to confuse, but they are different things. The first is a helper inside an ordinary SDK, where you supply every tool. The second brings the coding agent's machinery along with it, tools included.
The agent SDK is more powerful, so is there a reason to pick the tool runner? Yes.
| Tool runner | Agent SDK | |
|---|---|---|
| Tools | Only what you put in | File and command access are already there; you select and restrict from that set |
| Context handling | You build it | Machinery for long-running work is included |
| Fits | You want the set of tools to be something you can count | You want to hand over the hands-on work wholesale |
Both can restrict which tools are usable and insert human approval before execution. The difference is not whether you can restrict; it is whether you are using what came built in.
If the job is "give it internal search and a database query, nothing else," writing those tools yourself on a tool runner keeps the surface visible. If the job involves files and commands, the agent SDK gets there faster. If your own tools are enough, tool runner; if you are handing over hands-on work, agent SDK.
Where third-party frameworks fit
Besides the provider's SDK, there are external frameworks — a set of parts and conventions for building agents. They land somewhere on the same table.
- The framework owns the loop, you own the hosting (LangChain, LangGraph) — same place as the tool runner
- Tools come built in, you own the hosting (OpenClaw, Hermes Agent) — same place as the agent SDK
- Either of those may also offer a hosted option from the same vendor (LangSmith's Deploy to Cloud, for instance) — using that puts you in managed
Names and lineups change fast. What is worth remembering is not the individual products but who owns the loop and who owns the environment.
The Anthropic document quoted earlier also has advice about frameworks: start by calling the API directly, add a framework when you need one, and if you use one, understand what it is doing underneath. Using one with the wrong mental model of its internals is a common source of failure.
Where the familiar tools fit
Some of these already exist as finished products you invoke by name. Placing them on the table makes the differences concrete.
The one that runs when you name it in a GitHub issue or pull request — writing @claude in the body to start work, for example — is built on the coding agent's SDK, and it runs on a GitHub runner. Not your machine, but your GitHub account pays for it and you write the configuration. On this article's axis, that is the side where you provide the environment: the agent SDK position. There are two cost sources as well: GitHub Actions minutes and model usage. Standard runners are free on public repositories, and private ones come with a free allowance. The model side can run with an API key or with subscription authentication. Note that it does not work just because you typed a name: the GitHub app and a workflow have to be set up first.
The one you invoke by name in a chat — writing @Claude in a Slack channel to hand over a task — runs on the provider's cloud. There are two variants: one where the session runs under an individual's subscription, and one where it runs under the organization's shared identity with admin-configured access (that one requires a business plan).
Both run on the provider's side, but they are finished services, which is a different thing from defining your own agent and handing execution over (managed). The word "hand over" is the same; whether you write the configuration is not.
Managed means you write the agent's configuration, store it, and hand execution to the provider. The amount you build is different from using a finished tool.
What changes in cost when you step outside
There are two ways in: build inside your own subscription and move it out later, or build on the API from the start. Either is fine. Building inside your own plan is faster, so deciding "inside the plan while experimenting" is reasonable.
What changes on the move is the shape of the cost. The same processing that fit inside a monthly fee becomes billed by usage. The number of runs also goes up in production compared with testing. An agent calls the model many times for one job, so the bill grows faster than you expect.
Before moving, run one representative job and look at how many input and output tokens it produces. Pricing is per token, so a count of calls is not enough. Once you know the volume of one run, multiply by the monthly run count for an estimate. Then pick a model that fits the job, set a cap, and make usage visible. Put those three in before you start running it. One loop that does not terminate is enough to make the bill jump.
When running inside your plan, check the provider's terms on whether unattended use is allowed. A plan intended for interactive use and unattended execution are sometimes treated differently.
Picking one
Read it from the requirements. Collect the ones that apply and treat the overlap as your candidate. This is not a table that returns a single answer.
| Requirement | Destination |
|---|---|
| You do not want to run infrastructure | Managed |
| You want to pause and resume (long jobs, jobs spanning days) | Managed |
| You want it to run on a schedule | Managed (or anything else if you build the trigger yourself) |
| The work involves reading/writing files and running commands | Agent SDK |
| You need approval before execution, or substitution on failure | Tool runner |
| You want the usable tools limited to ones you defined | Tool runner |
| None of the above; you want full control | Hand-rolled loop |
The top three are the "I do not want to own it" side, the bottom three the "I want to decide it" side. When in doubt, check first whether you have a reason to hand anything over. If not, you stay on your own side. Note that pause-and-resume also exists on the agent SDK and framework side.
Summary
There are three levels before an agent. If the provider's own interface is enough, use it. If a single API call is enough, use that. If the procedure can be written out, stop at a workflow. Only when you find that it cannot, go down to an agent.
Once you do, you can build inside your own subscription, or on the API from the start. If several people will use it, or it will be shipped or delivered, the latter is the answer. The four ways to build are just combinations of who owns the loop, the environment, and the tools.
If you spot something, a comment is welcome. For AI-related consulting, my DMs are open on Threads (@ai_advisor_jp).
Top comments (0)