Types of AI Agents, Sorted by What You Would Build

Search for types of AI agents and every result gives you the same list. Simple reflex, model based, goal based, utility based, learning. It is the taxonomy from the artificial intelligence textbooks, it predates every model you are considering, and it is repeated on nearly every page that ranks for this because it is easy to write and impossible to argue with.

It is also useless for building anything. That taxonomy sorts agents by the decision procedure running inside them, and when you are shipping software on top of a language model, the decision procedure is not a thing you choose. You write a prompt, you hand over some tools, and whether the result behaves reflexively or deliberatively is an emergent property you observe afterwards. You cannot select it from a menu.

The two properties you do select are what the thing is allowed to touch and how long it runs. Those are decisions you make explicitly, in code, before anything is deployed. They also happen to be the two properties that determine what it costs you and what it can break, which is why they are the sort worth having.

Sort one: what it may touch

This axis is about blast radius, and there are three positions on it.

Nothing. A prompt in, a completion out, no tools at all. This is the shape most things called an agent actually are, and there is no shame in it. Cost is predictable per call, failure is a bad answer, and nobody needs an audit trail to sleep.

Read only. The model can look things up: a search index, your documentation, a database it cannot write to. This is retrieval, and the interesting property is that being wrong is still cheap. A bad lookup produces a bad answer, which is the same failure mode as the previous band with more surface area for it to happen on.

Write. The model can change something outside itself. Issue the refund, send the email, update the record, merge the branch. This is the only band where the category genuinely changes, because a mistake now persists in a system somebody else depends on, and it outlives the conversation that produced it.

Almost every difficult question about agents is really a question about that third band. The useful discipline is to enumerate the write tools before choosing a model, a framework or a vendor, and to decide for each one whether it may fire unattended, requires confirmation, or may only ever be proposed. That is a product and liability decision, and no amount of model quality substitutes for having made it. There is more on where that accountability line falls in what separates a conversational agent from a chatbot.

Sort two: how long it runs

This axis is about money, and it is the one people estimate worst.

One shot. One call, one answer. Cost is the length of the prompt plus the length of the answer, and you can work it out on paper.

Bounded loop. The model calls a tool, reads the result, decides again, and stops after some fixed number of rounds. The thing to understand is that the whole accumulated context is resent on every round, because models are stateless underneath. Your input is not paid for once, it is paid for again at each step, and the last round of a session costs a multiple of the first.

Open ended. The loop runs until the model decides it is finished. This is the shape with the worst cost behaviour in the catalogue, because the growth is quadratic in the number of steps and the number of steps is chosen by the thing you are paying for. Anything in this band needs a hard ceiling on rounds and on total tokens, set by you rather than by the agent.

Rather than estimating any of this, measure it. Take a realistic transcript from the shape you are considering, count what one late step actually sends with a token counter, and put that through the LLM cost calculator at the step count you expect. The answer is routinely nothing like the figure people reach by looking at a single message, and it is what decides whether you summarise history, cache it, or cap the session.

Multi agent is a coordination decision, not an upgrade

Multi agent systems get written about as the top of a ladder, the thing you graduate to. They are not a rung above single agent systems. They are a different trade, and the thing you trade away is context.

Splitting one agent into several means each one holds only part of the picture. When the subproblems really are separable, that is a saving: each agent carries a smaller prompt, and small focused prompts are cheaper and more reliable than one enormous one. When the subproblems are not separable, you pay to resend the shared context to every agent, you add a round trip between each pair of them, and you introduce the failure mode where two agents hold contradictory views of the same state and neither is wrong from where it is standing.

Several agents earn their place in three situations, and it is worth being honest that they are narrower than the enthusiasm suggests.

• The subproblems are genuinely independent, so the context does not need to be shared in the first place.
• The permission boundaries differ. An agent that may write should not also be the one reading untrusted input, and separating them is a security argument rather than a performance one.
• The context must not mix, because one part of the work sees data another part is not allowed to see.

Outside those, a single agent with more tools is usually the simpler, cheaper and more debuggable answer, and simpler is not a consolation prize here.

The grid you actually pick from

Cross the two axes and you get the small number of shapes that exist in practice. A one shot call with no tools, which is a feature and not an agent. A bounded loop with read only tools, which is retrieval and covers a great deal of real work. A bounded loop with write tools, which is the first shape that needs approvals and an audit trail. An open ended loop with write tools, which is the most capable and the one that should never ship without ceilings and a kill switch.

Notice that none of those names appear on the pages ranking for this question, and that every one of them tells you something about what to build. The textbook categories tell you what to call the thing after it exists. Read more of our writing on building these systems.