AI Agents, Explained: The Loop Behind the Label

Start with the useful boundary

A normal AI feature may send one prompt to a model and display the answer. A workflow can make several model calls, but the application code still decides the sequence. An agent changes that responsibility: the model can choose the next step and select tools based on the task and the results so far.^[1][2]

• Chatbot: the user asks; the model answers.
• Workflow: code follows a predefined path, perhaps calling a model at several points.
• Agent: the model helps direct the path, choosing actions until it reaches a result or a stopping condition.

That boundary is more useful than debating whether a product is “truly autonomous.” Agentic behavior exists on a spectrum. A research assistant that decides what to search next is agentic even if a person must approve the final report. A calendar assistant can be agentic while still requiring confirmation before it creates an event.

The five parts of a small agent

Many agent diagrams look complicated because they include queues, databases, multiple models, and orchestration layers. Strip those away and a useful first design has five parts.

1. 1. ModelThe language model interprets the goal and decides what information or action is needed next.
2. 2. InstructionsThe operating rules define the job, available choices, limits, and what counts as finished.
3. 3. ToolsFunctions or APIs let the system read information or act in another system. Search, calendars, code execution, and databases are all examples.
4. 4. StateThe agent needs the current task, relevant results, and enough history to make the next decision without starting over.
5. 5. LoopThe runtime sends results back to the model and continues until the task is complete, blocked, handed to a person, or stopped by a limit.

A common shorthand is model, tools, and instructions. State and the execution loop are worth naming separately because they turn those ingredients into a running system. ReAct, an influential research pattern, formalized the benefit of interleaving reasoning with actions and observations from an external environment.^[2][3]

A simple example: schedule a project review

Suppose you ask: “Find a 30-minute slot with Aisha and Marco next week, then draft an invitation.” A chatbot can suggest wording, but it cannot know when the attendees are free. A fixed workflow could work if every scheduling request follows exactly the same steps. An agent becomes useful when the path depends on what it discovers.

1. Understand the goalExtract the attendees, duration, date range, and the fact that the invitation should be drafted—not sent yet.
2. Choose a read toolCall a calendar-availability function for the three people.
3. Observe the resultIf there is no shared slot, widen the search only if the instructions allow it; otherwise ask the user what to change.
4. Prepare the next actionDraft the event with the selected time and a useful agenda.
5. Stop at the boundaryShow the draft and ask for approval before creating an external commitment.

When a workflow beats an agent

Autonomy is not automatically an upgrade. If the sequence is stable and every branch can be expressed clearly, ordinary code is easier to predict, test, and operate. Anthropic’s engineering guidance makes the same distinction: workflows favor predictability, while agents are a fit when flexibility and model-directed decisions are genuinely needed.^[1]

• Use one model call for summarizing a document in a known format.
• Use a workflow for classify → retrieve → draft when the same three stages always apply.
• Consider an agent when the number and order of steps cannot be known in advance.
• Do not add an agent merely because the implementation sounds more advanced.

Agents often add latency, cost, and new failure paths because each decision can create another model call or tool action. The burden of proof should therefore run in the other direction: start simple, measure the result, and add agency only when the fixed solution falls short.^[1]

Useful autonomy is bounded autonomy

A production agent needs more than a good prompt. It needs limits that the surrounding software enforces. The runtime—not the model’s goodwill—should decide which tools exist, what arguments are valid, how long the loop may run, and which actions require approval.

• Give the agent only the tools required for its job.
• Separate read-only tools from tools that change external state.
• Validate tool arguments before execution.
• Set iteration, time, and spending limits.
• Require a person to approve irreversible or high-impact actions.
• Record tool calls and outcomes so failures can be reconstructed.

This is the practical meaning of guardrails: constraints around the model, not a promise that the model will always reason correctly. Good agent design assumes that some calls will be mistaken and makes those mistakes contained, visible, and recoverable.

Five questions to ask when someone says “agent”

1. What goal can it pursue?A concrete outcome is more informative than a list of model features.
2. Which decisions does the model control?This reveals whether the system is an agent, a workflow, or a chatbot behind new wording.
3. What can it read and change?Tools and permissions define the real capability—and the real risk.
4. How does it know it is done?A credible design has success criteria, stopping conditions, and a handoff path.
5. What happens when a step fails?Look for validation, retries with limits, alternate paths, and a way to ask for help.

If those five answers are clear, the label matters less. You can see the actual system: who controls the path, what the system can do, and how its autonomy is contained.