What is an agent? The anatomy of a system that decides | Cleon

The word "agent" has been stretched to mean almost anything that calls a model more than once. That vagueness is expensive: most projects that get scoped as "an agent" actually want something simpler, cheaper, and easier to test. This page draws the line precisely. An agent is a system where the model decides its own next step in a loop — it chooses which tool to call, reads the result, and decides what to do next, until it judges the task done. That one property — the model controls the flow — is what separates an agent from everything it gets confused with.

Everything in this subcategory builds on that definition. So before the patterns, the tools, and the debugging, this page lays out what an agent is made of, what it is not, and the single test for whether you need one. Get this right and most of the hard decisions later become easy.

The anatomy of an agent

An agent is five parts working together. Strip any one out and you have something else.

The model — the reasoning core. It reads the current situation and decides what to do next: call a tool, ask a question, or stop. The model is the part everyone fixates on, and the part that matters least to whether the system works (principle 4 — the model is the easy part).
Instructions — the system prompt that defines the agent's job, its boundaries, and how it should behave. This is where you tell it what it is allowed to do, what it must never do, and how to decide when it is finished. Vague instructions are the most common cause of an agent that wanders.
Tools — the functions the agent can call to act or to fetch. A tool is a typed function with a name, a description the model reads, and arguments it fills in: lookup_order(order_id), send_email(to, subject, body). A single invocation of a tool is an action. Tools are the agent's only way to affect the world or learn anything the model wasn't trained on; see tools and actions for how to design them.
Memory — what the agent carries between steps. At minimum, the running transcript of the current task (what it has tried, what came back). Sometimes more: retrieved facts, prior conversations, scratch state. Memory is a budget, not a bucket — more is not better past the point where the signal drowns (principle 10).
The control loop — the engine that ties the rest together. It runs a cycle: perceive the current state, reason about it with the model, act by calling a tool, observe the result, then loop back to perceive. The loop repeats until the model decides the task is done or a stop condition (a step cap, a timeout, an error) fires.

The control loop is the part that makes it an agent. In a workflow, you wrote the order of steps. In an agent, the loop hands control to the model on every pass and lets it pick the next step from the result of the last one. That is the whole difference, and it is the source of both the capability and the risk.

Grounding, in one paragraph

One term you will see throughout this subcategory: grounding. An agent reasons over whatever it is given. Grounding is the practice of feeding it real facts — retrieved from your data, a database, an API — instead of relying on what the model absorbed in training. An ungrounded agent answers from memory and guesses confidently when memory fails. A grounded agent answers from what you handed it this run. Grounding is upstream of almost every quality problem: when an agent is wrong but fluent, suspect what it was given before you blame the model (principle 2).

Agent, workflow, chain, single prompt: four shapes

These are four shapes, not four competitors. Each is the right answer to a different question. The axis that separates them is one thing: who decides the next step.

Single prompt — one call to the model, one response. No tools, no loop. The right shape when the task is "transform this input into that output" and the model already knows how: summarize, classify, rewrite, extract. If a single prompt solves it, stop here. It is the cheapest, fastest, most testable shape there is.
Chain — a fixed sequence of prompts, where each step's output feeds the next. Step one extracts entities, step two looks them up, step three drafts a reply. You wrote the order. The model fills in each blank but never chooses what comes next. A chain is the right shape when the task has clear stages that always run in the same order.
Workflow — a chain with branches and logic: conditionals, loops over a list, retries, parallel steps. Still, every path through it is one you drew. A workflow can be complex and still fully deterministic in its control flow — the model decides contents, your code decides flow. This is the shape most "agent" projects actually need.
Agent — the model decides the flow. There is no fixed sequence; the loop asks the model what to do next on every pass, and the answer depends on what the previous step returned. You give it tools and a goal; it composes the path itself, step by step.

Read top to bottom, each shape hands one more decision to the model. A single prompt decides nothing about flow. A chain and a workflow decide contents but not flow. An agent decides flow too. More decisions handed to the model means more capability on open-ended problems — and less predictability, higher cost, and harder testing. You climb this ladder only as far as the problem forces you, and not one rung higher.

When you actually need an agent

Here is the honest test, and it has one question: can you enumerate the path ahead of time?

If you can draw the flowchart — if you can write down the steps and the branches before the task runs, even a large and messy chart — then you do not need an agent. You need a workflow. Build the flowchart in code. It will be cheaper to run, faster to respond, possible to test case by case, and it will fail in ways you can predict and fix. Every branch you can name is a branch you should hard-code rather than hope the model picks correctly each time.

You need an agent only when the path genuinely cannot be enumerated in advance — when the next step depends on what earlier steps return in ways you cannot foresee, so no fixed flowchart could cover the space. A research task that follows leads wherever they go. A troubleshooting loop whose next probe depends on the last result. Work where the branching is effectively unbounded. There, the model deciding the next step is not a luxury; it is the only shape that fits, because you genuinely cannot write the flowchart.

This is not a counsel of caution for its own sake. An agent that should have been a workflow is worse on every axis you care about: it costs more per run, responds slower, drifts in non-deterministic ways, and resists the eval set you need to ship it. The discipline is to use the smallest shape that fits the job — and to be honest that the job rarely needs the biggest one.

The rest of the vocabulary

This page seeds the terms the subcategory leans on. A tool is a typed function the agent can call; a single call is an action. The control loop is the perceive → reason → act → observe cycle. Grounding is feeding the agent real retrieved facts rather than letting it answer from training. An eval is a fixed set of test cases with known-good outcomes you score the agent against — the difference between improving it and guessing (principle 3); because an agent's path is non-deterministic, the eval scores outcomes and trajectory, not an exact string. You will meet each of these in depth as the subcategory goes on; here they are just the words.

From here, two directions. To see how agents are wired together — single agent, agent calling sub-agents, the shapes a control loop takes — read orchestration patterns. To see the failure modes before you hit them in production, read agent gotchas. The platform-specific builds live in Agentforce agents for work inside the Salesforce security model and external agents for LangGraph and the Claude API outside it — complementary tools an engineer composes, never a versus.

Orchestration patterns — the shapes a control loop takes: single agent, sub-agents, and when to use each
Tools and actions — how to design the functions an agent calls, and how to keep each action's blast radius small
Agent gotchas — the failure modes — loops, runaway cost, wrong-tool calls — and how to catch them
Agent Style Guide — the bar an agent clears before it ships
AI Engineering principles — why the model is the easy part (4), ground before you generate (2), and if you can't evaluate it you can't ship it (3)

Reference: