An AI agent is a system that carries out a multi-step task on your behalf and decides for itself when the job is done - which is what separates it from a chatbot that answers and then stops. This guide covers the decision to build one at all, the three components every agent needs, and the two orchestration patterns worth knowing. We write for 300,000+ senior professionals at AI Central, and more guides like this are in the AI Central Library.
What is an AI agent?
An agent runs a workflow end to end rather than responding to one request at a time. It uses a language model to judge what to do next, decides when the task is finished, corrects itself or stops when something goes wrong, and calls external tools to actually take action - all inside limits you define.
That last clause matters. An agent without defined guardrails is not more capable, it is just less predictable.
When should you build an agent?
Most workflows do not need one. Agents earn their complexity on work that has resisted conventional automation, where rules-based systems keep failing for the same reasons.
The useful comparison is fraud review. A rules engine works like a checklist, flagging anything that trips a preset threshold. A model-driven agent behaves more like an experienced investigator, weighing context and spotting patterns that no single rule captures. That difference is the whole argument for agents, and it only pays off where the judgment is genuinely ambiguous.
Three signals suggest a workflow is a real candidate:
Complex decision-making. Judgment calls, exceptions, and context-dependent outcomes. Refund approval in customer service is the standard example
Rules that have become unmaintainable. Systems where the ruleset has grown so tangled that changing anything is expensive or risky. Vendor security review often looks like this
Heavy dependence on unstructured input. Work that means reading documents, interpreting language, or handling a conversation. Processing an insurance claim is a good test case
If your use case does not clearly meet at least one of these, a deterministic solution is probably the better build.
The three components of an agent
Strip away the frameworks and every agent is the same three things: a model doing the reasoning, tools giving it the ability to act, and instructions defining how it behaves. Everything else is implementation detail.
Choosing your model
Models differ on capability, latency, and cost, and there is no reason to use one model for every step. Simple retrieval or intent classification can run on something small and fast. A judgment call like approving a refund justifies something more capable.
The practical sequence is to prototype with the strongest model available so you establish what good looks like, then substitute smaller models step by step and see where quality actually drops. Build the evaluations first, hit your accuracy target, and only then optimise for cost and speed. Doing it in the other order means you never learn whether the ceiling was the model or the design.
Defining tools
Tools are how an agent reaches the rest of your stack, usually through APIs. Where a legacy system has no API, computer-use models can drive the interface directly, the way a person would.
Tools fall into three broad types: data tools that retrieve what the workflow needs, such as querying a CRM or reading a document; action tools that change something, such as updating a record or sending a message; and orchestration tools, where one agent is exposed as a tool to another.
Define each one to a consistent standard. Well-documented, tested, reusable tools stop you rebuilding the same capability three times under three names.
Writing instructions
Instructions matter more for agents than for ordinary model applications, because ambiguity compounds across steps rather than showing up once. Four things reliably improve them:
Start from documents you already have. Operating procedures, support scripts, and policy documents convert well into agent routines
Break dense material into smaller explicit steps rather than handing over a wall of policy
Tie every step to a specific action or output. Naming the exact action, and sometimes the exact wording, removes the interpretation gap
Anticipate the edge cases. Incomplete information and unexpected questions are the norm, so routines need conditional branches for them
A capable model can draft this scaffolding for you from an existing policy document, which is faster than writing routines by hand. The general principles behind writing them well are covered in our 26 principles of prompt engineering.
Orchestration: single-agent and multi-agent systems
The instinct is to design a sophisticated multi-agent architecture immediately. The teams that succeed generally do the opposite and grow into it.
Single-agent systems
One agent can cover a surprising amount of ground if you add tools incrementally. Each new tool extends what it can do without forcing you to coordinate multiple agents, and evaluation stays manageable because there is one thing to evaluate.
Every orchestration approach needs the idea of a run: a loop that keeps the agent working until an exit condition is met. Typical exits are a final-output tool being called, a response arriving with no tool calls, an error, or a cap on the number of turns. That loop is the mechanical heart of an agent.
Before splitting anything up, try prompt templates. A single flexible base prompt with policy variables handles many use cases, and new situations become a variable change rather than a new workflow.
When to use multiple agents
Push a single agent as far as it goes first. More agents buy you cleaner separation of concerns and cost you complexity and overhead.
Two symptoms justify splitting. The first is complex logic: prompts stuffed with conditional branches that no longer scale as templates. The second is tool overload, though the count matters less than the overlap - some systems handle more than fifteen distinct tools comfortably while others struggle with fewer than ten similar ones. Try clearer names and descriptions before you divide the system.
The manager pattern
A central agent coordinates specialists by calling them as tools, then synthesises their output into one response. The user only ever deals with the manager, which keeps the experience coherent and the control central. Use it when one agent should own execution and own the conversation.
The decentralized pattern
Here agents operate as peers and hand off execution to each other. A handoff is a one-way transfer: the receiving agent picks up the conversation state and takes over, and the original agent steps back entirely.
This suits triage. An incoming query goes to a routing agent, which passes it to whichever specialist owns that domain. You can give the specialist a handoff back if control needs to return.
Both patterns are graphs with agents as nodes. In the manager pattern the edges are tool calls; in the decentralized pattern they are handoffs. The design principles do not change either way: keep components composable and drive them with clear, well-structured instructions.
Frequently Asked Questions
What is the difference between an AI agent and a chatbot?
A chatbot responds to a request and stops. An agent executes a multi-step workflow, decides when the task is complete, and takes actions through tools without needing a prompt at every step.
Do I need a framework to build an agent?
No. Frameworks and SDKs handle the loop, tool definitions, and handoffs for you, but the three components - model, tools, instructions - can be implemented directly in your own code with any capable model.
Should I start with one agent or several?
One. Add tools to a single agent until it stops coping, then split. Multi-agent architectures introduce coordination overhead that is only worth paying once a single agent is demonstrably the constraint.
When is an agent the wrong solution?
When the workflow is genuinely deterministic. If the decisions can be written as rules that stay maintainable, rules will be cheaper, faster, and easier to audit. Validate that your use case needs judgment before committing to build.
