What agent models are — and which architecture your process needs
Not every AI agent is built the same way. The model or architecture you choose determines whether your agent reacts to inputs, plans ahead, or works with a team of other agents.
4-day trial · Cancel anytime
Agent models are the architectural patterns that decide how an AI agent perceives, plans, and acts — not the language model weights inside it. The four patterns in production are reactive agents that answer inputs, deliberative agents that plan before acting, autonomous agents that pursue goals across time, and multi-agent systems where a manager coordinates specialists. The pattern you pick determines what the agent can handle.
Published August 27, 2026 · Updated September 2, 2026 · Loïc Jané
What's new: a definition section separating agent models from machine learning models, a four-pattern comparison table, the five-component taxonomy, the build sequence, and a governance section — re-verified September 2026.
Sources: Anthropic — Building effective agents · Google Cloud — What is an AI agent? · Microsoft Learn — AI agent design patterns · IBM — Types of AI agents · AWS — What are AI agents?
What are agent models?
An agent model is the architecture behind an AI agent: the design decisions that govern how it takes in context, whether it plans, how far it acts on its own, and whether it works alone or alongside other agents. The same language model can power all four patterns — the model around it changes the behavior.
The term gets used two ways, and the confusion is worth clearing up. In machine learning, a model is a trained network — weights that turn input into prediction. An agent model is not that. It is the structure around the network: whether there is a memory layer, who decides the next step, how many agents share the work, and where a human approval gate sits. Two agents running identical weights can behave as differently as a phone tree differs from a colleague.
Why does the distinction matter in practice? Because architecture, not raw model quality, decides which processes an agent can run. A reactive pattern fails at anything requiring memory or sequencing; an autonomous pattern wastes budget on tasks that are really lookups. Matching the pattern to the process matters more than choosing between frontier models — and unlike the model choice, it is yours to make.
How to put an agent model in place
Whatever pattern you land on, the deployment sequence is the same. Skipping a step is how teams end up rebuilding an agent in the middle of a live process.
Map the process first
List the steps, the inputs each one needs, and every point where the path depends on what happened before. The map — not a vendor demo — tells you which pattern fits. A process with two steps and fixed inputs is a script; one with memory, branching, and handoffs is an agent of a specific shape.
Choose the pattern from the constraints
Read your map against the five questions below. Memory without branching points to deliberative; standing goals point to autonomous; clean handoffs between domains point to multi-agent. When two patterns both fit, start with the narrower one — promoting an agent to more autonomy later is easier than walking it back.
Wire only the tools the pattern needs
A reactive agent needs one clean input. A deliberative agent needs read access to its sources. An autonomous agent needs write access — behind approval gates. A multi-agent setup needs each specialist scoped to its own apps. Over-wiring is the common failure: every extra tool is a new way for the run to go sideways.
Run supervised before you scale
However confident the pattern looks on paper, the first weeks run supervised: every external action gated, every step logged. The run log is where you verify the architecture — where the agent chose tools you did not expect, or stalled waiting for context it was never given.
Re-audit as the process settles
Processes drift, and the right pattern drifts with them. Exceptions that were rare become weekly: that is the signal to promote a reactive agent to deliberative. Coordination overhead outgrows its benefit: that is the signal to collapse a multi-agent team into one autonomous agent with skills. Re-run the five questions quarterly.
Why the model around the model decides what your agent can do
Search 'agent models' and you get two answers. One school means machine learning models — the trained networks behind language understanding. The other, the one that matters when you are deploying agents, means architecture: how the agent is wired to perceive its environment, decide what to do next, and act on real software. The two meanings collide on vendor pages, and the collision costs buyers — teams pick a platform for its model and discover later that the architecture cannot run their process.
Architecture is the decision that outlasts every model upgrade. A reactive agent built on this year's frontier model still only responds to inputs; point a deliberative agent at the same weights and it plans, evaluates options, and sequences tool calls. When the next model ships, you swap a component. The pattern — what the agent remembers, how far it may act, whether it delegates — is the part you will live with.
Most agent platforms skip the question entirely. They offer a creation form, not an architecture choice, and what you get is a reactive bot wearing an autonomous agent's vocabulary. Knowing the four patterns and the five components underneath them turns that conversation around: you can audit any platform — including this one — and establish precisely which agent model you are buying.
Five questions that tell you which agent model fits
Ask these about the process, not about the agent. They take ten minutes and prevent the two classic mistakes: over-engineering a lookup into an autonomous agent, or under-powering a planning task into a bot that drops context.
The memory question
Does the process need to recall something from an earlier step or a previous run? Reactive models have no memory at all; deliberative models keep working memory for one run; autonomous models persist state across runs. Anything involving follow-ups, accumulations, or 'last time' needs memory — which rules out the reactive pattern immediately.
The branching question
Count the decision points where the next action depends on what just happened. One fixed path is reactive territory. A handful of evaluated branches suits a deliberative model. Branches that generate new branches — where the agent must plan its own plan — call for an autonomous pattern.
The timeline question
Does the work fit inside one session, or does it live across days and weeks? Reactive and deliberative models run and stop. Autonomous models wake on a schedule, check conditions, act, and sleep — the only pattern that owns a standing goal.
The handoff question
Does the work split cleanly between domains — research, drafting, verification — each with its own tools? Handing all of it to one general-purpose agent produces a generalist doing four jobs badly. A multi-agent model gives each domain a specialist and a manager to coordinate them.
The cost-of-error question
What does a wrong action cost, and can it be undone? High stakes plus irreversible actions call for tighter gates and a narrower pattern — reactive or deliberative with human approval on every write. Exploratory work with cheap failure is where autonomous models earn their runtime.
Five ways an agent model differs from a machine learning model
Search results mix the two meanings of 'model'. The distinctions below are the ones vendor pages gloss over — and the ones that decide whether an agent can run your process.
A machine learning model maps input to output — text in, prediction out. An agent model decides what happens between those mappings: which input to read next, which tool to call, when to stop and ask a human. The model is a component; the agent model is the design.
You train a model; you compose an agent model. Instructions, memory, tools, approval gates, and teammates are assembled, not learned. Composition happens in configuration — which is why changing an agent's architecture takes an afternoon, not a training run.
A model's capabilities are fixed when training ends. An agent model's behavior changes the moment you rewire it — add a memory layer, narrow the tool list, insert an approval gate. No weights involved.
Models are judged on benchmarks; agent models are judged on process outcomes — cycle time, exception rate, how often a human had to step in. A top-scoring model inside the wrong pattern still loses to a modest model inside the right one.
Upgrading a model swaps one component. Choosing an agent model designs the machine. That is why the architecture decision — not the model picker — is where an agent deployment succeeds or stalls.
Agent models compared: reactive, deliberative, autonomous, multi-agent
Four patterns cover nearly every agent deployed today. Most production agents are hybrids — the table shows the pure forms so the trade-offs stay visible.
| Reactive | Deliberative | Autonomous | Multi-agent | |
|---|---|---|---|---|
| Who decides the next step | The input itself — a fixed respond function | The agent, after weighing options against its goal | The agent, including whether to set new sub-goals | A manager agent, which delegates and arbitrates |
| Memory | None — each input is handled fresh | Working memory across one run | Persistent workspace across runs and days | Shared state plus per-agent workspaces |
| Time span | Seconds — one turn | Minutes to hours — one planned run | Hours to weeks — scheduled or triggered over time | Days to months — ongoing delegation |
| Unexpected input | Fails or misroutes | Plans around it if it fits the goal | Adapts or asks, then keeps working | Manager reroutes it to the right specialist |
| Cost profile | Lowest — one call | Moderate — reasoning plus tools | Highest — continuous runtime | Scales with agent count and coordination traffic |
| Best fit | Classification, routing, extraction | Analysis with a plan: audits, reviews, research briefs | Standing goals: reporting, monitoring, follow-up | Work with real handoffs: research, draft, verify |
The five components every agent model is built from
Every agent model, whatever the marketing calls it, is assembled from five components. Patterns differ in which components they include and how much authority each one gets. The list doubles as a vendor audit: ask which components an agent actually ships with, and the architecture reveals itself.
Perception layer
How the agent takes in the world: triggers, inboxes, webhooks, document readers, database watchers. Every pattern has one — but a reactive model stops here, responding to whatever this layer passes it.
Reasoning layer
The language model plus the instructions that turn context into decisions. Present in all four patterns; what changes is its authority — from executing a fixed response to choosing the next action outright.
Tool layer
The connected apps the agent may call. Access can be pre-wired to specific connectors, or chosen at runtime from a wide catalog. Runtime selection is what lets an agent handle an input format nobody anticipated.
Memory layer
Working memory lasts one run; a persistent workspace lasts across runs — state, references, notes. This is the component deliberative and autonomous models add, and the reason an agent can follow up on what it did yesterday.
Coordination layer
Delegation, review, and conflict resolution between agents. Only multi-agent models carry it, and it is where most multi-agent failures start — which is why delegation depth and scoping belong in the design, not the hopes.
The four agent models at work
The same company can run all four patterns side by side — each process matched to the architecture it needs instead of forced into one.
Reactive: invoice intake
An agent reads each incoming invoice, extracts the vendor, total, and due date, checks the format, and routes it to accounting with the booking fields filled. No memory, no planning — accurate classification at speed. It is the least impressive pattern and the one that breaks least often.
Deliberative: churn review
An agent pulls usage data for at-risk accounts, forms hypotheses about why each one is cooling, cross-checks against support history, and drafts an intervention plan per account — before anything is sent to a customer. The plan is the product: a human reviews the reasoning, not just the output.
Autonomous: weekly operations report
Given a standing goal — compile Monday's operations report — the agent gathers data from spreadsheets and the database, chases missing numbers, drafts the analysis, and publishes with anomalies flagged. Week three looks nothing like week one: it has learned where the data lives and which gaps matter.
Multi-agent: competitive analysis
A manager agent receives the brief and splits it: one agent researches competitors, another drafts, a third verifies facts and formats sources. The manager reviews each handoff, sends revisions back, and compiles the final document. Three specialists, one owner, a full record of who produced what.
AI agents for sales — how the deliberative pattern runs pipeline reviews
AI agents for customer support — triage and routing with a reactive front line
AI agents for operations — reporting and monitoring on the autonomous pattern
Choosing an agent model is the right question when
- You are about to automate a process and need to size the agent to it, not stretch the process around a platform
- A previous automation kept breaking on inputs nobody predicted
- You are comparing platforms and want to know what their 'agent' actually is
- Agent costs are climbing and you suspect the pattern is heavier than the task deserves
The architecture question can wait when
- The task is one deterministic operation on a predictable input — write the script
- You are still mapping the process by hand; the map comes first
- A compliance rule pins every step and forbids deviation
The platform buyer's checklist — how to evaluate what a platform's agent model really is
Where agent models go wrong
The most common failure is a mismatch between pattern and process. A reactive agent handed a planning task drops context on the second step. An autonomous agent pointed at a lookup task burns credits deliberating over what a script would finish in a second. A multi-agent system given a one-person job spends more effort coordinating than working. None of these are model problems — they are architecture problems, and no model upgrade fixes them.
Multi-agent models add failure modes of their own. Delegation can loop — an agent handing a task back to the agent that handed it over. Instructions drift apart across a hierarchy, so sub-agents optimize for goals the manager no longer holds. Failures propagate quietly when a specialist reports success on incomplete work. The countermeasures are structural: a hard cap on delegation depth, per-agent scoping to the apps each role needs, and run logs that record who delegated what to whom.
Whatever the pattern, the governance floor is the same. Irreversible actions — anything that writes to a connected system — wait at an approval gate. Every decision is traceable in an append-only log. Someone owns each agent's goal and approves changes to its instructions. If a vendor cannot show you where those gates live in their architecture, treat the 'autonomous' label on their site as typography, not architecture.
How Fleece AI implements agent models
Fleece agents run on the autonomous pattern by default: they receive a goal, propose a visible plan, choose their own tools at runtime, and reach 3,000+ apps without pre-wired integrations. The architecture is not a configuration burden — it is the product.
Multi-agent is native, not bolted on. A manager agent delegates to sub-agents in a hierarchy capped at three levels; each sub-agent carries its own goal, workspace, and skills; the manager reviews outputs and decides. Delegation depth limits and per-agent scoping are enforced by the platform, so the failure modes above are engineered out rather than promised away.
Memory is built in. Every agent keeps a persistent workspace — state, references, notes — that survives across runs, which is what enables deliberative behavior over weeks rather than a single session. Overnight, agents review their own runs and propose instruction changes; nothing changes until you approve it.
The pattern stays adjustable after deployment. Start an agent supervised with every write gated; open the gates as the run log earns your trust; promote it from deliberative to fully autonomous when the exceptions it faces are ones you have watched it handle. Architecture is a dial here, not a decision you are stuck with.
Read the docs — how agents, approval gates, and skills are configured
Browse the API reference — run agents programmatically over the REST API
Frequently asked questions
Agent models are the architectural patterns that define how an AI agent perceives, plans, and acts — reactive, deliberative, autonomous, or multi-agent. They are not the language model weights inside the agent; they are the design around those weights that decides what the agent can handle.
No. A machine learning model is trained weights that map input to output. An agent model is the architecture around models: memory, tool access, planning authority, delegation, approval gates. The same weights can power a reactive or an autonomous agent — the agent model is what differs.
The four patterns in production are reactive agents, which respond to inputs with no memory; deliberative agents, which plan before acting within one run; autonomous agents, which pursue standing goals across time; and multi-agent systems, where a manager coordinates specialist agents. Most real deployments are hybrids of two.
Match the pattern to the constraints. Memory needed across runs points to autonomous; planning within one run points to deliberative; clean handoffs between domains point to multi-agent; none of these — a straight input-output job — points to reactive. When in doubt, start narrower and promote later.
Yes — that is one of the advantages of architecture over training. In Fleece AI you can add memory, skills, or hierarchical delegation to an existing agent and watch it move from reactive to autonomous behavior. The underlying model stays the same; the design around it is what you adjust.
A multi-agent system is a set of specialized agents coordinated by a manager. Each agent owns one domain — research, drafting, verification — with its own tools and workspace. The manager delegates, reviews results, resolves conflicts, and compiles the outcome. It fits work with genuine handoffs, not tasks one agent can finish alone.
No. You describe the process in plain language; Fleece proposes the architecture — plan, tools, and approval gates included. Configuration covers which apps the agent may touch and who approves what. Custom skills are optional, for patterns you want to standardize across agents.
Pick the architecture, then deploy it
Describe one process in plain language. Fleece proposes the agent, shows its plan, and asks before anything irreversible — start supervised and loosen the pattern as the run log earns your trust.
Powered by Fleece AI · autonomous agents for 3,000+ apps