Types of AI Agents: A Practical Map for Work Software

A vendor demo opens with a line you have heard before: "our autonomous agent monitors your pipeline and takes action when something goes wrong." Ten minutes of questions later, the truth surfaces. A webhook fires when a deal field changes, a language model writes a sentence about it, and the sentence lands in Slack. That is a real product and it might be useful, but it is the simplest type of AI agent in the textbook, dressed in the vocabulary of the most advanced one. Knowing the difference is the whole skill. This guide maps the classical taxonomy onto the software you can actually buy, so you can hear a pitch and place it in the right box within about five questions.

The taxonomy is not new. It comes from decades of AI research, most familiarly Russell and Norvig's structure of simple reflex, model based, goal based, utility based, and learning agents. What is new is that all five categories are now for sale, priced similarly, and described with the same three adjectives.

The five main types of AI agents, defined properly

Before the marketing translation, the definitions. An agent is anything that perceives an environment through sensors and acts on it through actuators. In work software, the sensors are API reads and event subscriptions, and the actuators are API writes, messages, and file operations. The five types differ in exactly one thing: how much internal machinery sits between perceiving and acting.

Simple reflex agents map a current perception directly to an action using condition-action rules. If the ticket contains the word "refund", route it to billing. There is no memory of what happened a minute ago and no representation of the wider world. The behavior is entirely determined by what is on the screen right now.

Model based reflex agents keep internal state. They maintain a model of how the world evolves and how their own actions change it, which lets them act sensibly when the current perception is incomplete. A monitoring agent that knows yesterday's revenue baseline, and therefore knows today's figure is anomalous rather than merely low, is model based. The rules are still rules, but they run against a picture, not a pixel.

Goal based agents hold an explicit objective and search for a sequence of actions that reaches it. They consider the future rather than only the present. "Find out why last month's churn spiked" is a goal, and the agent has to decide which systems to query, in which order, and when it has enough to answer. Planning, decomposition, and tool selection all live here.

Utility based agents go further. When several action sequences reach the goal, they choose using a utility function that scores outcomes against tradeoffs: cost, speed, risk, confidence. A goal based agent asks "does this get me there?" A utility based agent asks "which of these three routes is best, given that queries cost money and the answer is needed in ten seconds?"

Learning agents improve their own performance over time from feedback. The canonical architecture has four parts: a performance element that acts, a critic that evaluates results against a standard, a learning element that modifies the performance element, and a problem generator that suggests exploratory actions. The defining property is that behavior changes from experience, not because a human edited a prompt.

Two things follow immediately. The categories nest: a learning agent contains a performance element that is itself one of the other four types. And more advanced is not better. A simple reflex agent that routes tickets correctly is a good piece of software. Wrapping it in a planner makes it slower, more expensive, and harder to debug for zero gain.

Simple reflex and model based agents: automation you probably already own

Most of what companies call AI agents today is a reflex agent with a language model in the middle. That is not an insult. It is a description of a well-understood architecture with excellent properties: deterministic triggers, bounded cost, easy testing, obvious failure modes.

The tell for a simple reflex agent is that its behavior is fully explained by its trigger. Ask what happens if you run it twice on the same input. If the answer is "the same thing", it is a reflex agent. Then ask whether it remembers the last time it ran. If not, it is simple rather than model based.

Model based agents in work software are usually the monitoring and anomaly products. They keep state, whether that state is a rolling baseline, an embedding index of your documents, or a record of which alerts already fired. That state is what lets them say "this is unusual" rather than "this crossed a threshold". It is also where most of the engineering effort goes, and where most failures come from, because a stale model produces confident nonsense.

The buyer's implication is about the boundary with plain automation. If the work is deterministic, a rules engine is cheaper and more reliable than a language model doing the same job less predictably. The distinction between an orchestrator that guarantees execution and an agent that decides what to execute is worth internalizing before you buy either, and it is covered in Workflow Orchestration Tools vs Workflow Automation. A surprising number of agent projects should have been a scheduled job with retries.

Goal based and utility based agents: where work software actually lands

Almost every credible business agent sold today is goal based. You give it an objective in natural language, it plans a sequence of tool calls, executes them, evaluates whether the objective is met, and either answers or tries a different path. The model does the planning and tool selection. The tools do the work.

This is the category where "agent" earns its name, because the system genuinely chooses its own actions. It is also where evaluation is hardest, because the same request can take different routes on different runs and both can be correct. For what the pattern looks like applied to specific jobs, AI Agent Examples: 12 That Do Real Work Inside a Company walks through the shapes that hold up in production.

A goal based agent with tool access has a recognizable loop.

The goal based agent loop with a human approval step

Request in chat

A person states a goal in natural language

Plan and decompose

Model breaks the goal into ordered steps and picks tools

Read connected tools

Queries CRM, billing, analytics, mail with scoped credentials

Check against the goal

Is the objective met, or is another step needed?

Answer with citations

Every claim traced to the record it came from

Human approval

Any write action waits for an explicit yes

Write action

Send, update, or create in the source system

Utility based agents are rarer than the marketing suggests. A true one needs an explicit scoring function over outcomes, and most vendors have not defined one because defining it requires the customer to state what they value. What you do see is partial utility reasoning: routing cheap requests to a small model and expensive ones to a large model, stopping a search when confidence crosses a threshold, preferring a cached answer when freshness tolerance allows it. Real utility functions, just narrow ones, and usually about cost rather than business value.

If a vendor claims utility optimization, ask what the function contains and who set it. "The model decides" means a goal based agent with good prompting. A list of weighted factors you can see and edit means genuinely utility based. Cost is often the dominant term, which is why token billing matters before you delegate spending decisions to software; OpenAI API Pricing for Teams: How Token Billing Works covers the mechanics agent runtimes quietly optimize against.

Learning agents, and why the label gets stretched

"It learns from your data" is the most abused phrase in the category, because it describes at least four different things that carry completely different risks.

Retrieval is not learning. Most systems that "learn about your business" are retrieving relevant documents at query time and putting them in the prompt. Nothing is learned. Remove the documents and the behavior reverts instantly. This is the safest architecture and the most common one.

Memory is not learning either. Storing preferences, past instructions, or previous conversations and reinjecting them is state, which makes the system model based, not a learning agent.

Feedback tuning is partial learning. If thumbs-down signals adjust which retrieval sources or prompts get used, the performance element is genuinely being modified by a critic. That is a learning agent in the architectural sense, even if no model weights move.

Weight updates are the strong form. Fine-tuning or reinforcement learning on your interactions changes the model itself. This is rare in general business software, and when it happens it deserves a direct question about what data was used and whether it is shared across customers. Where your text goes and what gets retained is the same question that governs consumer chat tools at work, laid out in ChatGPT Data Privacy at Work: What Leaves Your Company.

The buyer's question is simple: with no configuration changes in between, would the same input give a different answer six weeks from now? If yes, something is learning and you should know what. If no, the word is being used loosely.

What type of AI agent is a vendor actually selling?

This table is the practical core of the guide. Take a product you are evaluating, find the row that matches its observable behavior, and read across.

Five questions place almost any product in this table. What exactly triggers it? Does it keep state between runs, and what kind? Does it plan multiple steps or execute one? Can it write to a system without a person clicking yes? Would identical input produce identical output next quarter?

Reactive vs deliberative agents: the axis that matters at runtime

Cutting the same space differently, the reactive vs deliberative agents distinction splits on whether the system reasons before acting.

Reactive agents respond to stimuli immediately. Latency is low and predictable, cost per action is fixed, and behavior is easy to test because the input space is enumerable. Simple reflex and most model based agents are reactive. Deliberative agents build an internal representation, consider alternatives, and then act. Latency is variable, cost scales with problem difficulty, and behavior is only testable statistically. Goal based and utility based agents are deliberative.

Hybrid architectures dominate serious products: a reactive layer handles events with obvious handling and escalates the rest to a deliberative layer. The design question is where you draw that line, because every escalated event costs more and takes longer. Ask any platform to show you its escalation policy. Whether the policy is inspectable at all is a good proxy for maturity, alongside the criteria in Evaluating an AI Platform: Developer Ecosystem Checklist.

Autonomous agents: what each type of AI agent still needs from a human

"Autonomous" gets used to mean anything from "runs on a schedule" to "operates without oversight indefinitely". A more useful scale describes what the agent is allowed to do without a person in the loop.

Level 0, suggestion. The agent proposes, a person executes. Reading an email draft before sending it.

Level 1, approval per action. The agent can execute, but each write pauses for an explicit yes. Most responsible business agents live here.

Level 2, approval by policy. Actions inside defined bounds execute freely, anything outside escalates. Refunds under a set amount go through, larger ones route to a person.

Level 3, supervised autonomy. The agent acts and reports, humans audit afterward and can roll back.

Level 4, unsupervised. No human in the loop. Appropriate for reversible, low-stakes, high-volume actions, and almost nothing else in a business context.

Autonomy level is orthogonal to agent type. A simple reflex agent can be fully autonomous and frequently is, because nobody approves each spam filter decision. A sophisticated goal based agent can sit at level 1 forever, which is often the correct design. When a vendor says "autonomous agents", the question is not how clever the planner is. It is which level the system is authorized to operate at, and whether that boundary is configurable by you or hardcoded by them.

The honest position on autonomous agents today is that the reasoning is genuinely good and the accountability structures are not. What no vendor can give you is a guarantee about a novel situation nobody anticipated. That gap, not model capability, is why approval steps persist.

Agent classification in AI beyond the classical five

Three other axes of agent classification in AI show up constantly in product decisions.

Single agent versus multi-agent. Multi-agent systems split work across specialists that hand off to each other. The upside is separation of concerns. The downside is that errors compound across handoffs and tracing gets hard. A single well-scoped agent with good tools beats a committee of five for most business tasks.

Environment properties. Classical AI classifies environments as observable or partially observable, deterministic or stochastic, static or dynamic. Business software is the hard corner of all three: partially observable, because APIs expose a fraction of the truth; stochastic, because people do unpredictable things; dynamic, because data changes while the agent reads it. Any agent designed as if the environment were fully observable produces answers that are confidently incomplete.

Tool-using versus closed. A closed agent reasons only over what is in its context. A tool-using agent calls external systems during its run. This is the biggest practical divider in business software, because it determines whether the agent can answer questions about your live data at all. Tool use carries its own engineering surface: auth, pagination, rate limits, idempotency, the same problems covered in Integrating APIs: A Practical Guide for Business Teams. An agent is only as good as the integrations underneath it.

Where Skopx fits, and where it does not

Applying our own framework to our own product, honestly.

Skopx is a goal based, tool-using agent operating at approval-per-action autonomy. You connect the tools your company already uses, nearly 1,000 of them including Gmail, Slack, Stripe, HubSpot, QuickBooks, and Google Analytics. You state a goal in chat. The system plans which systems to query, executes the reads, and answers with citations pointing back at the records each claim came from. The citations exist precisely because a goal based agent's plausible-sounding wrong answer is its characteristic failure mode.

Two features sit in adjacent boxes. The insights engine, which surfaces risks and anomalies across connected tools, is model based: it holds a picture of normal and flags deviations from it. The morning brief is a scheduled reactive layer over the same picture. Workflows, which you build by describing them in chat, compile into deterministic automations. The building is deliberative, the running is reflex, which is exactly the hybrid split described above.

The model is BYOK: you bring your own key for any major model and pay the provider directly with zero markup, on Solo at $5 per month or Team at $16 per seat per month. The relevant point here is architectural, not commercial. Because inference runs on your key, the cost of deliberation is visible to you rather than buried in a seat price, which changes how you think about when to escalate from reactive to deliberative.

Now the boundaries, which matter more.

Skopx is not a self-directing autonomous system. It does not wake up, decide your priorities, and act on live systems without you. Write actions wait for an explicit yes. Anyone selling you level 4 autonomy over your billing system is selling you a risk, not a product.

It is not a learning agent in the strong sense. It does not train models on your data to change its own weights. Retrieval and state are not learning, and we are not going to call them that.

It is also not several categories of software it superficially resembles. It is not a business intelligence tool for building dashboards, and if you need governed, pixel-stable dashboards for a leadership review, build them where they belong; Business Dashboard Examples for Every Team, Explained is a better starting point. It is not a data warehouse and not an ETL pipeline: it queries systems through their APIs rather than centralizing and modeling your data. It is not a CRM and will not replace one. Anything that needs a system of record still needs a system of record. Full details on plans are on pricing.

Choosing the right type of AI agent for a job

Work backward from the task, not forward from the technology.

Deterministic and high volume: use a reflex agent or plain automation. Language models add cost and variance to work that has one correct answer.

Detecting that something is off: you need a model based agent, and the hard part is the baseline rather than the model.

Answering an open question that spans systems: you need a goal based, tool-using agent, and your evaluation should focus on citation quality and what happens when the data is incomplete.

Genuine tradeoffs with money or risk attached: you want utility based behavior, which in practice means defining the utility function yourself.

Something no fixed rule can capture, with a reliable feedback signal: a learning agent may be warranted, along with the governance to match.

The most common mistake is buying one category up from what the task needs. The second is buying autonomy the organization is not ready to supervise. Match the type to the job, set the autonomy level below where you think it should be, and raise it once you have evidence.

Frequently asked questions

What are the five types of AI agents?

Simple reflex agents, which map perception directly to action; model based reflex agents, which keep internal state; goal based agents, which plan toward an explicit objective; utility based agents, which choose among successful plans using a scoring function; and learning agents, which modify their own behavior from feedback. Most business software today is goal based with tool access, wrapped in reflex triggers.

Which type of AI agent is best for business use?

Whichever matches the task. Reflex agents win on deterministic, high volume work because they are cheap and testable. Goal based agents win on open-ended questions that span multiple systems. Choosing a more sophisticated type than the task requires adds cost, latency, and debugging difficulty without adding value.

What is the difference between reactive and deliberative agents?

Reactive agents act on the current stimulus with no planning: fast, cheap, predictable, and poor at novel situations. Deliberative agents build an internal model and reason about alternatives before acting: slower, more expensive, variable in cost, and far better on problems they have not seen. Most production systems combine both, using a reactive layer for routine events and escalating the rest.

Are autonomous agents actually autonomous?

Rarely in the strong sense. Most systems marketed as autonomous agents operate at approval-per-action or policy-bounded autonomy, meaning a person authorizes write actions or defines the bounds within which the agent may act. Ask which specific actions run without human confirmation and whether you can change that boundary. The answer tells you more than any description of the model.

Does an AI agent need to learn to be useful?

No, and most useful ones do not learn at all. Retrieving current data at query time, keeping state, and following good instructions cover the overwhelming majority of business tasks. Learning earns its keep only when you have a reliable feedback signal and a task whose right answer genuinely shifts over time.

How do I tell what type of AI agent a vendor is selling?

Ask what triggers it, what state it keeps between runs, whether it plans multiple steps or executes one, whether it can write to a system without a person approving, and whether identical input would produce identical output six weeks from now. Those five answers place any product in the taxonomy regardless of what the marketing page says.