The four types of agents

When someone tells me they built an agent, I ask three questions. Who decides the next step? What happens when a tool returns garbage? And what survives when the run fails?

The answers sort every agent system I have read or built into four types. The types are not a capability ranking, though they are usually read as one. They are a map of where control lives, and each jump between types moves a control point from the developer to the model. Getting the jump wrong, or skipping it, is where most agent projects die.

The field map

type 1  LLM workflow        developer-fixed flow, model fills content and params
type 2  model-routed flow   model picks tools and branches inside a fixed frame
type 3  closed-loop agent   model iterates on tool results and decides when it is done
type 4  long-horizon agent  goal decomposition, persistent state, verify -> recover -> replan

Everything else is engineering texture on top of one of these four. When I review an agent system, the first thing I do is place it on this map, because each type carries its own failure modes and its own answer for how much harness it needs.

Type 1: the LLM workflow

The flow is drawn by a developer. The model fills the blanks: a summary, a translation, the answer slot in a RAG template, the body of a drafted email. The model never decides what happens next; the arrows between steps are fixed before the first token is generated.

Most production AI features live here and should stay here. RAG chat, classification pipelines, extraction chains, drafting assistants. Type 1 is cheap to run, cheap to test, and every failure is reproducible, because the path is identical on every run. The model can be wrong, but it cannot take a wrong turn, because it has no steering wheel.

The limit is that the system is exactly as smart as the plan written in advance. Every case the plan missed is a case the system misses, forever. At some point the branching you would have to hand-write stops paying for itself, and the decision about which path to take should move into the model.

Type 2: the model-routed workflow

The frame is still fixed: the set of tools, the ordering constraints, the exit conditions. What moves is one decision, and the model makes it. A support ticket is classified, then routed to the specialist prompt. A natural-language request is mapped to one function call out of a fixed schema. A risky turn is detected and rerouted to a guarded flow.

Toolformer is the cleanest demonstration that this routing decision can be learned rather than hand-specified. Toolformer (Schick et al., 2023) trains a model to decide, at each position, whether to call one of a handful of APIs, a calculator, a search engine, a calendar, a translator, what arguments to pass, and how to fold the result back into prediction. The training is self-supervised, requiring little more than a few demonstrations per API, and the result is a model that routes to tools on its own while remaining an ordinary next-token predictor. The jump from type 1 is small but real: the branch point is now a model judgment, so the system can route around cases the developer never enumerated.

What type 2 still cannot do is change course. The frame is fixed, so when a tool result says the plan is wrong, there is no plan B except the one the developer pre-wrote.

Type 3: the closed-loop tool-using agent

Now the loop opens. The model emits an action, the tool runs, the observation comes back, and the model acts again. It composes tools: search, then read, then write. It decides when it is done, which is a subtle power, because done is a model judgment rather than a fixed exit condition.

Concrete examples: a research assistant that searches, opens sources, searches again, and writes a synthesis; a coding agent that edits a file, runs the tests, reads the failures, and edits again; an ops agent that checks inventory, quotes a customer, and updates the CRM, in whichever order the situation requires.

The canonical reading of type 3 is ReAct. ReAct (Yao et al., ICLR 2023) interleaves reasoning traces and actions so the model can think, act, observe, and think again. On question answering and fact verification, interacting with a simple Wikipedia API overcomes the hallucination and error propagation that chain-of-thought reasoning suffers from in isolation, because a wrong claim can be checked against the world. On the ALFWorld and WebShop benchmarks, ReAct outperforms imitation and reinforcement learning baselines by 34 and 10 absolute points of success rate, prompted with only one or two in-context examples.

Two properties make this type 3 rather than type 2. Iteration: the observation feeds back and changes the next action, not just the next token. Termination: the model itself decides the goal is met and stops. Both are new in type 3, and both are exactly where the risk concentrates. A loop that composes tools can call the wrong tool, call it forever, or declare victory while the world disagrees.

The blind spot of type 3 is that iteration alone is not correction. When the tool result is wrong in a way the model cannot detect from text, the agent's only lever is to generate more text. ReAct does not fix that; it makes the failure visible, which is already a win. The boundary to type 4 is drawn by what happens after the failure.

Type 4: the long-horizon general agent

Goal decomposition. Persistent state. Shell, browser, editor, API, GUI. And the loop that makes everything else survivable: verify, recover, replan.

The state matters as much as the loop: files, databases, skill libraries, and memory stores that outlive any single prompt, so the agent gets better across runs instead of starting from zero every time.

Reflexion is the reading note on the recovery half. Reflexion (Shinn et al., NeurIPS 2023) reinforces an agent without updating weights: after a failed trial, the agent verbally reflects on the feedback and keeps the reflection in an episodic memory buffer that guides the next trial. The headline number is a 91 percent pass@1 on HumanEval against 80 percent for GPT-4 at the time. What Reflexion demonstrates is that recovery can be a first-class mechanism rather than a prompt afterthought. What it does not have is a horizon: the memory is trial-scoped, and the goal is to finish one task by retrying it.

Voyager is the cleanest full type 4 in the literature. Voyager (Wang et al., 2023) is an embodied lifelong-learning agent in Minecraft built from three components: an automatic curriculum that proposes the next exploration goal, a growing skill library of executable code, and an iterative prompting loop that feeds environment feedback, execution errors, and self-verification back into program improvement. The model is queried as a black box, with no parameter fine-tuning. The measured results, 3.3x more unique items, 2.3x longer travel distances, and key tech tree milestones reached up to 15.3x faster than prior state of the art, matter less than the architecture: goals are decomposed, skills persist and compose across tasks, and a program enters the library only after the agent verifies it. That is verify, recover, replan made structural instead of textual.

AgentBench is the reality check. AgentBench (Liu et al., 2023) evaluates LLMs as agents across eight environments and finds the obstacles are poor long-term reasoning, decision-making, and instruction following, plus a wide gap between top API models and open ones. Read as a type-4 statement: the failures of long-horizon agents are horizon errors rather than tool syntax errors: the model loses the thread, and good tooling can only make the loss visible and recoverable.

The jumps are design decisions, not capability claims

type 1 -> type 2   who picks the branch:       the developer -> the model
type 2 -> type 3   iteration and termination:  the observation steers the next action, and the model decides done
type 3 -> type 4   who remembers and recovers: the prompt -> persistent state and replanning

Each jump moves control from the developer to the model, and each one converts a fixed guarantee into a model judgment. Type 1 guarantees the path. Type 2 guarantees the frame. Type 3 guarantees the loop. Type 4 guarantees nothing except what the harness enforces. That last sentence is the whole reason I care about harnesses.

This is also why the four types are a taxonomy and not a ladder. A type 4 general agent is not better than a type 1 workflow; it is less constrained, which is only better when the constraint was the thing holding you back. Most products are better at type 1 or 2, where the guarantees are cheap. The type you choose should be the highest one whose failures you can observe, explain, and recover from.

The arrow also runs backward, and this is the part that makes the taxonomy load-bearing. Take a type-3 loop, pin it under a hard iteration cap, and move termination out of the model into an acceptance check against world state: you now have a type-3 agent running at type-2 guarantees, because the frame and the exit condition are fixed again and the model only chooses inside them. Type is a property of the agent plus its harness; the agent alone has no type. A harness is how you buy back guarantees the type gave up.

Run the exercise on a system you already know. A deep-research loop, search, open sources, search again, synthesize, is textbook type 3, and the classification makes two design decisions for you: the observations must actually change the next query, because if the search plan is written fully up front you have a type-1 chain with extra steps, and done should be decided by a source-coverage check rather than the model's sense of closure. Give that loop a hard iteration cap and the coverage check as its acceptance gate, and you have deliberately demoted it to type-2 guarantees, which is the right call for a research feature with a latency budget and a user waiting on the other end.

What I would build

If I were designing an agent system from scratch today, the taxonomy would dictate the harness before the model choice. Model choice matters, but the harness decides whether failures are visible, reversible, and learnable.

First, the event log is the schema. Every action, observation, and decision is recorded in a replayable stream, because you cannot supervise a loop you cannot replay, and you cannot train on trajectories you did not keep. Second, completion is a gate, not a sentence: the agent may claim done, but an acceptance check against world state decides. Third, irreversible actions are proposal-first: nothing that cannot be undone fires without a reviewed proposal. Fourth, candidate plans run in a sandbox before touching real state, and tool access is sandboxed regardless of how much the model is trusted. These four are design positions, and each one has a deep-dive below.

Notice how each one maps onto the taxonomy. Type 1 and 2 need almost none of this, because the developer still owns the frame. Type 3 is where the event log and the completion gate become the product: the loop is only as trustworthy as the record you keep of it. Type 4 is where everything else lands, sandboxed tools, review before irreversible mutation, and replayable state that survives the model losing the thread. The harness is not a fixed checklist either. The harness grows with the type, and so should your testing.

Where my own projects sit on the map

SafeRoutes is a skill that enforces invariants for a type-3 host agent on an unmodified harness (github.com/xesws/SafeRoutes). The insight is that you do not need to rewrite the harness to keep a closed-loop agent honest. You ship a skill the agent loads, and the invariants constrain what it can commit.

PiPlan.ai's agent harness sits between types 3 and 4 with the review discipline of type 1. Every plan is proposal-first: the agent writes the plan, the harness shows what would change, and a person makes it land. Candidate plans run in a simulation sandbox before anything real is touched. And the full event log is kept as training-data trajectories, because an agent that cannot replay its own run cannot learn from it. The conversational planner-executor agent is still in progress.

Loop Supervision is dependency-aware supervision over multi-agent runs (github.com/xesws/Loop_ENG_Hackathon). Once a run spans hours and several agents, the question stops being can it finish and becomes who is blocking whom, and who claims completion while the world disagrees.

Engram is a personal agent that writes beliefs into model weights (github.com/xesws/AIEHackathon). Type 3 agents usually keep memory in a retrieval store; Engram asks what should be internalized instead of retrieved, and proves the belief lives in the weights by turning retrieval off.

ClawConclave is an OpenClaw multi-agent system with distinct roles (工部, 格物, 都察) operating in shared channels (github.com/xesws/EvenRealities-Claw). Multiple agents under one roof is where the supervision problems of type 4 stop being theoretical.

Reading further

The posts under this one go deeper on the control points the taxonomy exposes.

Harness: sandboxing notes, review gates, agent harness frameworks in 2026.

Evaluation: function calling, why multi-agent systems fail, long-horizon agents, graph-grounded verification.

Memory and context: agent memory, context compaction, memory as an attack surface.

Training, security, planning: agentic RL, MCP tool interfaces, sandboxing agents, planning with classical solvers.

The taxonomy is a map, not a ladder. The interesting work is not climbing from type 3 to type 4. It is knowing, at every step of a build, which type you are in, which control point you just moved, and which guarantee you traded away for it.

Sources linked in this post were fetched and verified.