- An agent is a language model in a loop that picks its own tools and steps until it reaches the goal or gets stuck.
- A workflow has its path written in code, while an agent decides as it goes.
- Start with the simplest solution; an agent costs time and money, so use it where flexibility is needed.
The word “agent” is used so loosely that it is worth pinning down before I compare tools. In its write-up on building effective agents, Anthropic notes that some people mean fully autonomous systems that work long and independently, and others mean systems that follow a predefined recipe. It calls all of these agentic systems, but draws one important line, which I will carry over to coding.
Workflow versus agent
According to that write-up, a workflow is a setup in which a model and tools are orchestrated through predefined code paths. An agent is a setup in which the model directs its own process and tool usage, keeping control over how it accomplishes the task. The difference is practical: in a workflow you know which steps will follow and in what order, because a human wrote them. In an agent the steps result from what the model sees along the way.
| Workflow | Agent | |
|---|---|---|
| Who picks the steps | The code author, upfront | The model, as it works |
| Predictability | High | Lower |
| Flexibility | Low, for known tasks | High, for open-ended tasks |
| Cost and latency | Usually lower | Usually higher |
| Testing | Simpler | Harder |
The authors recommend looking for the simplest solution and adding complexity only when needed. Agentic systems usually trade latency and cost for better task performance, so you should consider whether that trade makes sense. For many applications a single, well-prepared model call with retrieval and in-context examples is enough.
The loop a coding agent works in
A coding agent such as Claude Code is a model run in a loop with access to tools. The ReAct study described the idea behind this pattern: the model generates reasoning traces and actions in an interleaved manner, where reasoning helps it form plans and handle exceptions while actions let it gather information from the outside world. In coding, the outside world is your project.
- 01GoalYou describe the task and the success criterion.
- 02ThinkThe model decides the next step.
- 03ToolIt reads a file, searches, edits or runs a command.
- 04ResultIt sees the tool's answer: code, an error, test output.
- 05DecisionIt fixes, moves on or finishes.
- 06HumanYou review the changes and approve.
A failing test makes it easy to see. The agent reads the message, opens the file with the function, proposes a fix, runs the test again and checks whether it passed. If not, it goes back to the “think” step. Such a loop is the strength, because the agent corrects itself on facts instead of guessing. It is also a source of risk: every turn costs money, and the model can go in circles or head the wrong way if the goal was unclear.
What an agent consists of
The Anthropic write-up names the basic element: a model augmented with retrieval, tools and memory, which generates its own queries, selects tools and decides what to keep. In coding practice that means four components. First, a model that reasons and writes code. Second, tools: reading and editing files, search, running commands, sometimes a browser or MCP servers. Third, context: what the model currently “sees”, limited by the context window. Fourth, project memory, for example a rules file loaded at the start of a session. That is why two agents on the same model can behave quite differently: they differ in toolset, context management and permissions.
When an agent pays off
The recommendation from the write-up is that an agent is better when flexibility and model-driven decisions are needed at scale, and a workflow when the task is well defined. In coding an agent wins on open-ended tasks: find where a bug comes from, add a feature across several files, refactor a module. It loses where a rigid sequence is enough, for example daily file formatting, which a script handles better.
A good practice is three questions before using an agent. Can this be done with a simpler tool? Can I describe what a good result looks like? Can I check the result quickly? If the answer to the last one is “no”, even the best agent will give you a problem instead of help. A related topic is the human in the loop: deciding which steps the agent takes alone and which need your consent.
Common mistakes when working with an agent
The first mistake is a task that is too big in one go. An agent works in a limited context, so after many steps it starts to lose earlier arrangements. It is better to split the work into stages that can be checked separately. The second mistake is no completion criterion: without one the agent finishes when it thinks it has finished, not when the task is done. The third is permissions that are too broad at the start. When an agent can do everything, every mistake has full consequences, so begin in a mode that asks for consent and loosen it only for commands you know. The fourth is trusting the agent’s own declarations: the sentence “everything works” is not proof; proof is a test you ran yourself.
It is also worth remembering a simple split of responsibility. The agent is responsible for execution, you for the goal and for the judgement. If you assign the goal “improve the code”, you will get changes the agent considers an improvement; if you assign “make test X pass without changing its content”, you get something you can verify. The more concrete the criterion, the fewer loops and fixes.
You will find a comparison of specific tools in the article Claude Code, Codex CLI and Gemini CLI compared.
Last checked: 20 October 2026. The concepts are stable, but products and their capabilities change quickly, so check details in the documentation.