An AI agent is not a secret-service sidekick. It is a piece of software that decides for itself: it reads its surroundings through sensors (data streams, interfaces, user queries) and acts on them through actuators (APIs, commands, messages) to reach a goal. The hard part is not writing one. The hard part is knowing that there is no universal agent, and choosing the right kind for the problem in front of you.
That single choice, from the simplest reactive agent to a goal-oriented one, is what separates a system that ships from a demo that quietly dies. The numbers back this up. Gartner expects that more than 40% of agentic AI projects will be canceled by the end of 2027 because of problems like poor orchestration or a badly chosen agent type. In our experience, the projects that end up in that 40% almost never fail on the model. They fail on architecture. This article walks through the agent types our engineers weigh on every engagement, and then shows what a team that has made these calls in production actually brings to the table.
What is the PEAS framework, and why start there?
Before comparing agent types, you have to describe the problem precisely. We use PEAS, the standard lens for specifying any agent, because it forces the questions that most teams skip:
- Performance: what does success actually mean here? Maximising revenue, minimising errors, completing a task cleanly?
- Environment: what world does the agent operate in? Is it fully observable, deterministic, static, discrete? The answers set the true difficulty of the job.
- Actuators: how does the agent change the world? SQL statements, function calls, motor movements.
- Sensors: how does it perceive the world? Input data, sensor streams, user queries, log files.
Defining PEAS is the first and most consequential step, and it leads naturally to the right agent type. Skip it and you are building on sand. In our projects, this is where an experienced engineer earns their keep long before a line of orchestration code gets written.
What are the three foundational agent types?
Agents are usually classified by how complex their internal architecture is and how well they understand their world, a path that runs from reactive automata to systems that plan and learn. Three types mark the milestones on that path. Understanding their mechanics, and their limits, is essential, because even advanced frameworks are far less reliable than the hype suggests. A recent benchmark found that popular solutions correctly complete only about 50% of tasks across 34 realistic programming problems. Many of those failures come from exactly one mismatch: the raw power of an LLM bolted onto the wrong agent architecture for the task.
The simple reflex agent
The most basic building block. It runs on a direct “if-then” rule: perception triggers a condition, the condition triggers an action. No history, no model of the world. IF the temperature sensor reads above 22 degrees, THEN turn off the heating, regardless of how the room got there.
Its strengths are speed, simplicity, predictability, and low compute. Its weakness is that it is blind to context and to the past. Give it a partially observable environment where the sensors do not tell the whole story, and it is helpless. It also cannot work toward a future state. It fits stable, fully observable environments with clean cause and effect: thermostats, basic spam filters, mechanical safety cut-offs.
The model-based reflex agent
When the environment is not fully visible, the simple agent breaks. The model-based agent adds the missing piece: an internal model of the world that records what it cannot see directly. That model is a representation of how the world changes over time and how the agent’s own actions move it.
Its cycle extends the simple one: perceive, update the world model, assess the current state against that model, apply a rule, act. The model lets it tell identical perceptions apart by context. Seeing a closed door, it knows whether it closed the door itself or whether the door has been shut for a while. That is the arrival of internal state and memory, a real step toward flexible behaviour in imperfect, fragmentary environments. A vacuum robot that maps a room so it does not clean the same patch twice is running a basic version of this.
The goal-based agent
Model-based agents still react to the present. Goal-based agents use their model of the world to plan and simulate the future against a defined goal, a description of a desired state (“order packed”, “customer got the right answer”). Action becomes a means, not an end.
Its cycle: perceive, update the model, analyse the goal, search possible paths, select the action. It simulates sequences (“what happens if I do A then B?”) and picks the path it judges will get closest to the goal. That introduces the idea of utility, since not all paths are equally good. This makes it far more flexible: the same architecture can pursue different goals just by redefining them, with no rule rewrite. The cost is real, though, both in the compute needed to search the state space and in the discipline needed to define the goal and its success metrics precisely. In our experience, this is exactly where complex projects, often built from teams of LLM agents, run into orchestration and observability problems, the same problems that keep so many of them out of production.
What are utility-based and learning agents?
The spectrum runs further:
- Utility-based agents extend the goal-based type. When several paths reach the goal, they do not settle for any solution, they score end states with a utility function and choose the optimal one, which makes better decisions possible under uncertainty.
- Learning agents add a learning loop to any of the above: a critic that evaluates performance against feedback, a learning element that updates rules, model or utility function, and an exploration element that tries new actions in search of better results. This is the foundation of modern machine learning and deep reinforcement learning.
Where do these agents actually run?
The theory shows up in systems people touch every day:
- Simple reflex: automatic doors, basic PID controllers, alerts like “if CPU usage hits 95%, send an email”.
- Model-based reflex: most game NPCs (they track a player they occasionally lose sight of), simple location-aware navigation.
- Goal- and utility-based: the heart of advanced systems. Autonomous vehicles (goal: get from A to B safely), e-commerce recommendation engines (goal: maximise expected order value), and the assistants that break a complex query into a sequence of steps (goal: deliver a complete answer). It is in these LLM-based builds that the gap between prototype and production, the one the benchmarks and Gartner keep pointing at, becomes visible.
What do our AI teams bring to the 40% problem?
Knowing the types is table stakes. Turning them into a stable, observable, maintainable production system is a different discipline, and it is the one that decides which side of Gartner’s 40% a project lands on. This is the work our AI engineers do daily:
- Architecture matched to PEAS. Our engineers do not reach for a goal-based, LLM-driven agent because it is fashionable. They map your PEAS first and then pick the simplest agent type that clears the bar, from a reflex rule to a full utility-based planner. Over-engineering fails as reliably as under-engineering.
- Orchestration that holds under load. The failure mode in agentic projects is rarely a single agent, it is coordination between them. We design the handoffs, guardrails, and fallbacks that keep multi-agent workflows coherent when real traffic hits.
- Observability from day one. You cannot fix what you cannot see. We build in tracing, evaluation, and monitoring across the agent lifecycle so behaviour stays legible instead of turning into a black box the moment it ships.
- Production patterns learned the hard way. Retries, cost control, hallucination grounding, human review at the right checkpoints. These are the patterns that separate a convincing demo from a system a regulated business can actually run, and we have them because we have shipped them.
This is also where AI changes the shape of the team, not the vendor. A small, senior group of our engineers, augmented by AI agents that handle the volume, delivers the output of a much larger classic team, and faster, because the people in the loop already know which architecture survives contact with production.
How do you bring this capability in?
The fastest way past the 40% is not another framework evaluation, it is people who have already made these calls. We plug in two ways:
- A dedicated AI team that owns an agentic build end to end, from PEAS through orchestration and observability to production.
- Staff augmentation, dropping a senior ML or AI engineer into your existing team to make the architecture decisions that keep the project shippable.
Choosing the right agent type is not an academic exercise. It is the engineering decision that most shapes whether your project ever reaches production. If you would rather learn from projects we have already delivered than from the ones in Gartner’s 40%, that is exactly what our teams offer.
Bring in a team of experts, augmented by AI → Team augmentation