The problem it solves
Some tasks cannot be reduced to a fixed sequence of steps. Researching a question might require three searches or ten, depending on what each one turns up. Debugging an issue means following wherever the evidence leads. You cannot write the path in advance, because the path depends on what happens along the way.
This is exactly where a workflow falls short and an agent earns its place. Instead of forcing an open-ended task into a rigid pipeline that breaks the moment reality deviates from the plan, an agent adapts as it goes. It decides the next step based on what it has learned so far, which is the only way to handle problems whose shape is not known ahead of time.
How it works
The cleanest definition comes from Anthropic: an agent is a system where the model dynamically directs its own processes and tool use, keeping control over how it accomplishes a task. The defining feature is a loop.
The model runs in a loop. It looks at the goal and the situation, decides on an action, and uses a tool to take it. It reads the result of that action, updates its understanding, and decides the next action. This cycle, decide, act, observe, repeat, continues until the model judges the task complete. That repeating cycle is the engine of every agent.
The model controls the flow. This is the line that separates an agent from a workflow. In a workflow, the developer’s code decides what happens next. In an agent, the model decides, at runtime, based on what just happened. Control over the sequence has moved from the code to the model.
Autonomy is a spectrum, and it has a cost. “Agent” covers a wide range, from a model that loops through a couple of tools to a system that plans a long task on its own. More autonomy means more capability on hard problems, but also more cost, more latency, and more ways to go wrong. A looping system that can act by itself needs real guardrails: limits on what it can do, and defined points where it stops or asks a human.
Because of that cost, the honest guidance is to use the least autonomy the task needs. An agent is the right tool for genuinely open-ended problems, and the wrong one for tasks a simple workflow would handle more reliably.
A concrete example
Ask an AI to “find out which of our competitors raised funding last quarter and summarize it.”
A fixed workflow struggles, because the steps depend on what is found: how many competitors, how many sources, how deep to dig. An agent handles it naturally. It searches, reads what it finds, decides it needs to check two more sources, pulls those, notices a gap, runs another search, and once it has enough, writes the summary and stops. Nobody scripted that exact sequence. The model chose each step based on the last, which is precisely what makes it an agent.
How it connects
An agent is the counterpart to a workflow: same building blocks, but the model directs the flow instead of the developer. It is built on tool use, and its engine is the tool-use loop. When a task grows large, agents are combined into bigger structures, the domain of agentic architectures, such as splitting work across an orchestrator and subagents.
Deciding when a problem truly needs an agent is central to the senior roles. An AI Solutions Architect owns that judgment; an AI/LLM Developer builds the loop and its guardrails; an AI Product Manager weighs the capability against the cost and the risk.