What 'AI agent' means before you try to sort types
An AI agent is a system that perceives its environment, decides what to do based on that input, and takes an action that changes something, without a human approving each individual step. That last part is what separates an agent from a tool. A calculator perceives input and acts, but nobody calls a calculator an agent, because the action is trivial and there's no decision layer choosing between options.
The word gets stretched to cover a lot of ground right now. A script that calls an LLM once and posts the output somewhere gets called an agent. So does a system that runs for hours, checks its own work, and decides what to do next based on what it finds. Both get the same label, which is exactly why a taxonomy is useful: it gives you a way to ask what kind of agent you're actually looking at, instead of taking the word at face value.
The four classic types: simple reflex, model-based reflex, goal-based, utility-based
The four types are simple reflex, model-based reflex, goal-based, and utility-based agents, a classic taxonomy from AI textbooks like Russell and Norvig's Artificial Intelligence: A Modern Approach. Each type adds a capability the previous one lacks: memory, then goals, then the ability to weigh tradeoffs between competing ways to reach a goal.
Here's what each one actually does:
Simple reflex agent: acts only on the current percept, using fixed condition-action rules. No memory, no model of the world. It works fine in a fully observable environment and breaks the moment the current input alone isn't enough to decide correctly.
Model-based reflex agent: keeps an internal model of the world, updated from the history of what it has perceived so far. This lets it act sensibly even when the world is only partially visible at any one moment, because it remembers what it saw before.
Goal-based agent: has a model of the world plus an explicit goal, and chooses actions by considering which ones move it toward that goal. This is where planning and search enter the picture. It's no longer just reacting, it's evaluating options against an objective.
Utility-based agent: has a goal and a utility function that ranks different ways of reaching it. Reaching the goal isn't binary success or failure anymore; the agent weighs tradeoffs, like speed against cost against quality, and picks the option that scores best.
The progression matters more than the labels. Each step up adds a decision the agent is now allowed to make on its own, which is also each step up in how much you need to trust it.
Where a blog-publishing agent fits in this taxonomy
Most agents marketed as "AI agents that write and publish" are closer to a simple or model-based reflex pattern than to a goal-based or utility-based one, even when the marketing implies otherwise. A script that gets triggered on a schedule, generates a post from a prompt template, and publishes it is following a fixed condition-action rule: trigger fires, content gets produced, content goes live. There's no weighing of options in that loop.
It starts to look goal-based once the system is given an actual objective, something like "grow organic traffic to this topic cluster" or "fill the content gap around this keyword," and it has to decide what to write about, when, and how, based on that objective rather than a fixed template. It starts to look utility-based once it's making tradeoffs: publish a shorter post now versus wait and do more research, auto-publish this draft versus hold it for review because the topic is sensitive, run three iterations to sharpen an answer versus ship the first draft to hit a schedule. Those are utility judgments, not condition-action rules.
Be honest with yourself about which one you're actually running. Most tools sold as agents today are an LLM wrapped in a pipeline with some tool access: fetch a keyword, generate text, call a publish API. That's a real and useful thing, and it can save a lot of manual work. It just isn't a utility-based agent in the textbook sense, and treating it like one, assuming it's weighing quality against speed when it's actually just following a template, is how you end up surprised by what it published.
Why the distinction matters once an agent has write access to your site
The distinction matters because a reflex-pattern agent will publish whatever the rule tells it to publish, with no internal check on whether it should, while a goal or utility-based agent is at least structured to weigh that decision, which changes what kind of oversight you need to put around it. Write access is the point where the taxonomy stops being academic. An agent that only drafts and never touches the live site can be a simple reflex script and the cost of it doing something dumb is small: you read the draft, you fix it or delete it. An agent that publishes directly is a different risk profile no matter which type it technically is.
This is the practical reason to care about the type. A model-based reflex agent that remembers context across a series of posts can still publish something wrong with total confidence, because remembering isn't the same as judging whether something is true or worth publishing. A goal-based agent chasing "increase publishing frequency" can hit that goal by publishing thin, repetitive posts, technically succeeding at the goal while doing something you didn't want. Knowing the type tells you what the agent is optimizing for and what it isn't checking, not whether it's safe.
If you're running an agent through Floggy's API, SDK, or CLI to draft or publish posts, or running it on a schedule to do ongoing agentic SEO work, this is the question to ask before turning on auto-publish: what is this agent actually deciding, versus just following. If the honest answer is "it follows a template and publishes," treat it accordingly and put a human in the loop somewhere in the chain, at least until you've seen enough of its output to trust the pattern.
AI agent vs agent framework vs chatbot: cutting through the label soup
An AI agent perceives, decides, and acts, sometimes with real consequences like publishing a page; an agent framework is a toolkit for building an agent, not an agent itself; a chatbot is a conversational system that mostly reacts to one message at a time with a human approving the next step by asking the next question. All three get called "AI" in casual conversation, which is where the confusion starts.
A chatbot's default mode is reactive: you send a message, it responds, you send another. Even a chatbot with tool access is still fundamentally waiting on you to drive the conversation forward, turn by turn. It can look agent-like when it calls a tool mid-conversation, but the human is still the one deciding whether to continue, correct course, or stop.
An agent framework is a library or scaffold: it gives you the pieces to build an agent (memory, tool calling, a loop that lets the system take multiple steps without you prompting each one) but the framework itself doesn't perceive or decide anything on its own. It's infrastructure, the way a web framework is infrastructure for building a website, not a website.
An AI agent is what you get when you take that scaffold and give it a goal, tools, and permission to act without a human approving every single step. The meaningful difference from a chatbot isn't the underlying model, it's autonomy over turns: an agent can take several actions in a row, decide what to do next based on the result of the last action, and reach a state where something in the world (a file written, an API called, a post published) has changed without a person clicking anything in between.
What to check before letting any agent type publish unsupervised
Before you let any agent, regardless of which of the four types it resembles, publish to your site without a human reading it first, check that you have a clear line between what it can publish unsupervised and what it must hold for review, and that you can see, audit, and undo whatever it did. The type of agent tells you how it decides. These checks tell you whether you're safe regardless of how it decides.
A short, practical list:
Draft versus publish is a real switch, not a default. Floggy's CMS lets you run an agent in draft-only mode, where everything it produces sits for a human to approve, or in auto-publish mode. Know which one is on before you connect an agent to your API keys.
There's a review step somewhere in the pipeline. Even a light one, someone skimming titles and first paragraphs before they go live, catches a lot of what an agent optimizing for a goal like "publish frequency" will otherwise miss.
You can see what it published. An audit trail of what went out, when, and from which run matters more once volume goes up. If you can't answer "what did the agent publish last week" without checking every post by hand, that's a gap.
Credentials are scoped, not shared. An agent with API or CLI access to your CMS should have only the access it needs, not the same key you use for everything else.
You can roll back or unpublish. Things will occasionally go out that shouldn't have. Knowing you can pull a post down quickly matters more than trying to prevent every bad output upstream.
The agent knows when not to publish. This is the hardest one and the most important. A pattern that ships a post every time it finishes generating one, with no check for uncertain facts, invented numbers, or thin content, is a simple reflex agent no matter what it's marketed as. Build in a check, even a crude one, for the cases where the right move is to hold, not ship.
None of this depends on picking the "right" label for what you're running. It depends on knowing, honestly, what decisions you've handed to the agent and which ones you haven't, and making sure a person still owns the ones that matter.