Every AI agent runs the same loop: perceive, decide, act, check the result. What separates one type from another is how smart the decide step is. Here are the five classic designs, the modern LLM version, and what it takes to run one safely inside a business.
There are five classic types of AI agents: simple reflex agents that follow if-then rules, model-based reflex agents that track state, goal-based agents that plan toward an outcome, utility-based agents that weigh tradeoffs, and learning agents that improve from feedback. Modern LLM agents combine these ideas with tools, memory and planning.
An agent is software that observes something, decides what to do about it, and does it, without a person pressing the button each time. The idea is decades older than the hype; classic AI textbooks define an agent as anything that maps percepts (inputs) to actions. What changed recently is the decide step. Language models can read a rambling email from a customer who wants two things at once and choose a sensible next action. That makes agents practical for ordinary business work, and easy to build badly.
Our framing is simple: an agent is a tool. It takes the repetitive part of a job off someone's plate so they get that time back. In every setup we recommend, a human still approves anything that costs money, commits the business, or cannot be undone.
Swap out how step two works and you get a different type of agent. That is the whole taxonomy.
These categories come from classic AI research, and they still describe real systems well. Most production agents are blends: a learning component around goal-based planning, with hard reflex rules underneath as a safety net.
How it decides: condition, then action. It looks only at the current input and fires the first rule that matches.
Business example: a form handler that spots "flooding" or "gas smell" in a service request and texts the on-call technician immediately, while every other request lands in the normal queue.
Where it breaks: when the right action depends on history. It fires the same rule on the tenth duplicate message as on the first.
How it decides: still rule-driven, but it keeps an internal picture of the parts of the world it cannot see right now, and updates that picture with every new input.
Business example: an inventory agent that tracks stock on hand, units already on order and typical weekly usage. It flags a reorder only when projected stock drops below a threshold, not every time a count dips.
Where it breaks: when its picture drifts from reality. If deliveries are never logged, the stockroom it believes in is wrong, and so are its alerts.
How it decides: it knows what "done" looks like and searches for a sequence of actions that gets there. A different situation produces a different plan.
Business example: a scheduling agent with one goal, book the job. It checks technician calendars, drive time between stops and the customer's stated windows, then proposes the first slot that satisfies all three.
Where it breaks: when two plans both reach the goal and one is clearly worse. A goal answers yes or no; it does not say which yes is better.
How it decides: it scores possible outcomes with a utility function, a number that captures what you care about, and picks the action with the best expected score.
Business example: a lead-routing agent that ranks the morning's inquiries by estimated job value, likelihood to close and how long each person has waited, so the first callback goes to the lead worth the most right now.
Where it breaks: when the scoring is wrong. The function encodes your priorities; weight them badly and the agent optimizes faithfully for the wrong thing.
How it decides: any of the designs above, plus a feedback loop. A critic compares results with a standard, a learning element adjusts behavior, and a problem generator occasionally tries something new to learn from.
Business example: an inbox triage agent that sorts mail into quote requests, invoices, complaints and noise. Every time someone drags a message to a different folder, that correction becomes training signal.
Where it breaks: when feedback is noisy or rare. It learns what it is rewarded for, which may not be what you meant.
Root, the guide that peeks in from the edge of this site, is rule-based. It matches what you type against answers a person wrote and never makes up a reply. In textbook terms that is a simple reflex agent, and for a site assistant that must never improvise a price, that is a feature, not a limitation.
Hierarchical and multi-agent systems describe how agents are organized, not how one decides. More on those below.
| Type | Keeps state | Explicit goal | Weighs tradeoffs | Improves itself | Good first use |
|---|---|---|---|---|---|
| Simple reflex | No | No | No | No | Keyword routing, alerts |
| Model-based reflex | Yes | No | No | No | Stock and status tracking |
| Goal-based | Yes | Yes | No | No | Scheduling, multi-step tasks |
| Utility-based | Yes | Yes | Yes | No | Prioritizing leads or jobs |
| Learning | Yes | Often | Often | Yes | Classification that drifts over time |
A large language model agent puts a language model in the decide step. The model reads the situation in plain language and chooses the next action. Surrounding code, usually called the harness or runtime, carries that action out. Four components do most of the work.
The model cannot touch your systems directly. Developers describe each tool with a name, a purpose and a strict input schema, for example find_open_slots(technician, after, duration_hours). When the model wants to act, it returns a structured call instead of prose. The runtime validates the arguments, makes the real API request, and hands the result back to the model as a new observation.
That separation is the most important safety property an agent has. The model proposes; your code decides whether the proposal runs. Every tool is a door you chose to build, with a lock you control.
# one task, traced step by step observe email from j.ortiz: "move thursday's install, add a 2nd unit" think two intents: reschedule + order change call find_open_slots(technician="any", after="thu", duration_hours=3) result ["mon 09:00", "tue 13:00"] call draft_reply(to="j.ortiz", slots=[...], change="add unit") result draft saved gate order change alters the invoice total -> needs approval stop queued for a person; nothing sent yet
Short-term memory is the context window: the conversation, tool results and instructions. It is precise but limited, and paid for again on every step. Long-term memory lives outside the model: a customer record, a notes table, a summary written back after each session.
Retrieval connects the two. Documents are split into passages and indexed, usually as embeddings, and only the passages relevant to the current step are pulled into context. This is retrieval-augmented generation (RAG), and it is how an agent answers from your actual price sheet instead of its general training. Facts the agent must never get wrong belong in a lookup, not in its recollection of a long chat.
Simple agents take one step at a time: reason, act, observe, repeat, a pattern often called ReAct. Harder tasks do better with plan-then-execute. The model drafts a short plan, the runtime works through it, and the plan is revised when an observation contradicts it. Either way, cap the steps. An unbounded planner is how an agent ends up calling the same search tool forty times in a row.
Guardrails are the code between the model's intentions and the real world:
A multi-agent system splits a job across several agents, each with a narrow role, its own instructions and its own tools. The usual shape is an orchestrator that breaks the task into parts and specialists that each handle one part.
A content pipeline is the standard example. A researcher gathers sources and pulls quotes with links. A writer turns those notes into a draft in your voice. A reviewer checks every claim against the research notes and sends the draft back with specific fixes. Only when the reviewer passes it does a person see it, and that person decides whether it ships.
Every hand-off adds latency, cost and a chance to lose context. If one agent with three tools can do the job, ship that. Split only when fixing one behavior in a long prompt keeps breaking another.
Coordination usually follows one of three patterns: sequential hand-offs (a pipeline), a supervisor that delegates and merges results, or a shared workspace, sometimes called a blackboard, that every agent reads from and writes to.
A demo proves an agent can work once. An evaluation proves it works on the hundredth messy input. Before an agent touches real customers, we build a test set from real past examples, write down the correct outcome for each, and score every version of the agent against it. Four numbers matter most:
A hypothetical inbox triage agent. Version 2 added price-sheet retrieval and a rule to escalate refund requests.
Source: illustrative numbers written for this explanation. They are not benchmark, client or industry data.
| Metric (illustrative) | Version 1 | Version 2 |
|---|---|---|
| Task success rate | 71% | 88% |
| Cost per task | $0.09 | $0.05 |
| Median latency | 14 s | 9 s |
| Escalation rate | 22% | 12% |
The numbers in this made-up case do not matter. What matters is that every metric is re-measured on the same test set whenever a prompt, a tool or a model changes.
Skipping this step is common, and expensive. In a July 2026 prediction, Gartner said AI agents will outnumber sellers ten to one by 2028, yet fewer than 40% of sellers will say agents improved their productivity. Its finding on who wins matches what we see in code: leaders who fix data, automation and user experience first are five times more likely to see a return.
None of these are exotic. They are the agent versions of input validation and access control, and they get solved the same way: in code, with tests.
| Failure | What it looks like | Engineering mitigation |
|---|---|---|
| Hallucinated actions | The model calls a tool that does not exist, invents an order number, or reports a success that never happened. | Strict tool schemas. Confirm every outcome from the system of record. The agent never narrates a result the runtime did not verify. |
| Loops | The same search repeated, or a failing call retried forever, burning money and time. | Step, token and spend caps. Detect identical repeated calls, back off, then escalate to a person. |
| Permission creep | Access grows one convenience at a time until a support agent can issue refunds or delete records. | Least-privilege credentials per tool, separate read and write keys, scheduled access reviews, approval for any new write permission. |
| Prompt injection | Text hidden in an email, web page or PDF tells the agent to ignore its instructions and forward the inbox. | Treat retrieved content as data, never as commands. Require approval for outbound actions triggered by outside content. Log everything. |
Agents are not only something you run. Increasingly they are your visitors: shopping assistants, research tools and browser agents that fetch pages, extract facts and sometimes fill out forms for someone. What they can parse decides whether you get recommended.
Our machine-readability analyzer scores a page on most of these in seconds. The same discipline applies to agents you run internally: an agent reading a tidy, consistently labeled spreadsheet makes far fewer mistakes than one guessing its way through a messy one. For the bigger picture of how answer engines choose sources, see AI search optimization.
Start smaller than you think. The agents that last solve one annoying job completely before they are trusted with a second.
Adoption is running well ahead of execution. The McKinsey State of AI 2025 survey found 62% of organizations experimenting with AI agents, but only 23% scaling an agentic system in at least one function. The gap between those two numbers is mostly steps two through seven. And the direction is clear: Gartner expects agentic AI to make at least 15% of day-to-day work decisions autonomously by 2028, up from zero in 2024 (as reported by WFTV).
Tell us the task you would hand off first. An engineer will look at how it runs today and tell you plainly whether an agent, a simple automation or nothing at all is the right fix.
The agents we build are custom-coded around the tools you already use, with human approval on anything that matters, a full action log and a kill switch. They do not replace your people. They give them back the hours.
Prefer to talk? Call 1-800-481-8638 or use the contact page.
The five classic types are simple reflex, model-based reflex, goal-based, utility-based and learning agents. Hierarchical and multi-agent systems describe how several agents are organized together rather than how one agent decides.
An inbox triage agent that reads incoming email, sorts it into quotes, invoices and complaints, drafts replies and waits for a person to approve them is a practical business example. A thermostat is the classic simple reflex example.
They run a loop: perceive inputs, decide on an action, act through tools such as APIs, then observe the result and decide again. Modern agents use a language model for the decide step, with code that validates and executes every action.
Multi-agent AI splits a task across several specialized agents, for example a researcher, a writer and a reviewer, coordinated by an orchestrator. It helps when one agent's job becomes too broad to test reliably.
They can be, when they use least-privilege access, log every action, stay inside step and spend limits, and require human approval for anything involving money, customers or changes that cannot be undone.
That is not how we build them. A well-scoped agent takes over repetitive steps like sorting, copying and drafting, so your people spend their time on judgment, relationships and the work they are good at.
Start with one workflow, human approval on every step that matters, and numbers that prove it is working.