AIMA Chapter 2 — Intelligent Agents.

This chapter is where AIMA stops talking about AI in the abstract and starts talking like a systems designer. It gives you a lens that is shockingly reusable. Whether the thing is a thermostat, a chess engine, a voice assistant, a clinical decision support system, or an autonomous taxi, you can ask the same questions: what does it sense, what can it do, what counts as success, what kind of world is it living in, and what internal architecture is enough for the job?

01 What an agent is, in the most general sense

An agent is anything that can perceive its environment through sensors and act upon that environment through actuators. That definition is intentionally broad. A human is an agent: eyes, ears, skin, and so on are the sensors; hands, legs, and speech are actuators. A robot is an agent: cameras and lidar are sensors; wheels, motors, and grippers are actuators. Even software can be an agent. A chess program “perceives” the board state from the current position, and its actuator is the move it outputs. A trading bot perceives market data and acts by placing orders.

The power of the definition is that it cares about the loop, not the material. We are not saying “an agent must be a robot” or “an agent must be conscious.” We are saying an agent is something embedded in a decision cycle. It gets information, it does some internal processing, and it pushes an action back into the environment.

This is why the agent idea became the dominant unifying idea in AI textbooks. It is flexible enough to describe simple rule-following systems and sophisticated learning systems with the same outer language. Once you see that, the whole subject starts to feel more coherent.

02 Agent function vs agent program: the idea and the implementation

AIMA makes a subtle but very important distinction between an agent function and an agent program. The agent function is the ideal mathematical mapping from a percept sequence to an action. Formally, if \(P^*\) means all possible percept sequences and \(A\) means the set of actions, then the function is

The agent program is different. It is the actual piece of code running on some architecture — a machine, a processor, a robot body, a phone, or a server. The program is how we approximate or implement the desired function. In other words, the function is the abstract behaviour we want; the program is the concrete mechanism that tries to produce it.

Why does this distinction matter? Because when we evaluate intelligence, we usually care about the behaviour of the mapping, not whether the source code looks elegant. At the same time, engineering constraints live at the program level. A theoretically perfect function might be impossible to implement because the program would need infinite memory, impossible sensing, or too much time.

That last sentence already hints at why memory matters. Some environments can be handled by looking only at the current percept. Others require remembering hidden state, previous observations, or earlier actions. The agent architecture you need depends on the environment class.

03 Rationality: doing the right thing with limited information

Chapter 2 sharpens the idea from Chapter 1: a rational agent is one that does the right thing. But “right” here must be read carefully. It means the action that is expected to maximise the performance measure, given the percept sequence so far, the agent's built-in knowledge, and the actions available to it. Rationality is judged using the information available at decision time, not using perfect hindsight.

This means rationality is not omniscience. An omniscient agent knows the actual outcome of every action before acting. Real agents do not get that luxury. Rationality is also not perfection. If the agent's sensors are noisy, its knowledge is incomplete, or time is limited, then “the right thing” might only be the best available gamble.

The notion of “doing the right thing” also depends completely on the performance measure. If you define success badly, the agent can behave in ways that are technically rational and practically awful. A delivery agent rewarded only for speed may drive recklessly. A content recommender rewarded only for time spent may optimise addiction instead of wellbeing. Rationality does not rescue a bad objective.

That is why AI design begins with task specification. You must say what “better” means before you can ask whether the system is intelligent.

04 Performance measures are external, explicit, and non-negotiable

AIMA insists that the performance measure be defined externally. That is a quiet but deep design principle. We do not ask the agent how happy it feels. We define a measure of success from the task's point of view. For a vacuum agent, success might be a clean floor with low energy use and low noise. For a taxi, success might include safety, legality, speed, comfort, and fuel efficiency. For a chess engine, success is simple: win, or at least avoid losing.

The performance measure is external because the world, not the agent's self-image, determines whether the job got done. This is why “happiness” is not a valid performance measure in the textbook sense. It is too internal, too vague, and too easy to decouple from the actual task. An agent could be “happy” while failing completely.

Designing good performance measures is much harder than it looks. If you omit a constraint, the agent may exploit that omission. If you mash several objectives together carelessly, you may get surprising behaviour. This becomes a huge issue in modern AI safety and reward design, but the textbook already plants the seed in Chapter 2.

05 PEAS: the cleanest way to describe a task environment

PEAS stands for Performance measure, Environment, Actuators, Sensors. It is the standard Chapter 2 framework for specifying an agent task. Whenever a question asks you to “design an intelligent agent” for some application, PEAS is usually the expected starting format because it forces you to define the job before arguing about the architecture.

PEAS sounds simple because it is simple. That is the point. A clean task description prevents fuzzy thinking. If you cannot fill out PEAS clearly, you probably do not yet understand the actual AI problem you are trying to solve.

06 Three PEAS examples worked in detail

Agent	Performance measure	Environment	Actuators	Sensors
Automated taxi	Safe, legal, fast, comfortable, profitable, fuel efficient	Roads, traffic, pedestrians, weather, maps, regulations	Steering, accelerator, brake, gear, horn, display, route planner	Cameras, lidar, radar, GPS, speedometer, map data, microphones
Medical diagnosis system	Correct diagnosis, useful treatment advice, low harm, good resource use	Patients, diseases, tests, guidelines, hospitals	Display recommendations, request tests, rank diagnoses, alerts	Symptoms, test results, history, images, vitals, clinician input
Chess-playing program	Win games, avoid losses, use time well	Chessboard, rules, opponent, clock	Legal move output	Board state, move history, clock state

Automated taxi. This is the classic AIMA example because it is hard on almost every dimension. The performance measure is not merely “reach the destination.” If you ignore comfort, legality, and safety, you get pathological behaviour. The environment is open, dynamic, uncertain, and full of other agents who may not behave predictably. The sensors are multimodal. The actuators interact with physics in real time. This is why autonomous driving is such a famous AI grand challenge: it forces nearly every problem in the textbook into one application.

Medical diagnosis system. This example teaches a different lesson. The agent may never physically act on the world like a robot, but it still counts as an agent because recommending a test or ranking diagnoses influences decisions. The performance measure must account for accuracy, safety, false negatives, treatment usefulness, and maybe even cost. The environment includes uncertainty, incomplete information, delayed test outcomes, and human experts in the loop.

Chess-playing program. This is much cleaner. The rules are explicit, the environment is discrete, the sensors are effectively perfect, and the objective is crisp. That is why game playing became such an early AI laboratory. It is still hard, but it is cleanly hard.

07 The six environment axes — where problems become easy or brutal

AIMA classifies task environments along six major axes. These axes matter because different environments demand different kinds of agent architecture. The more hostile the environment, the more internal sophistication you usually need.

The exam line you must know is that the real world is usually bad on every axis. It is partially observable, multi-agent, stochastic, sequential, dynamic, and continuous. That is why “real intelligence” is so much harder than toy examples.

08 The five agent types, from weakest to most general

AIMA presents five increasingly powerful agent types. You can think of them as answers to the question: how much internal machinery does the agent need in order to behave well in its world?

1. Simple reflex agent. This agent uses condition–action rules of the form “if current percept matches condition X, do action Y.” It has no memory of the past and no model of unobserved state. A thermostat is the classic example: if temperature is below threshold, switch heater on; otherwise off. This can work beautifully in fully observable, simple environments.

2. Model-based reflex agent. This agent adds internal state. It keeps track of aspects of the world that are not directly visible in the current percept. A navigation system or a robot vacuum often needs this because the world is only partly observable. The internal model helps bridge the gaps.

3. Goal-based agent. This agent does not merely react. It reasons about future actions relative to explicit goals. Once you ask “which action sequence gets me to the destination?” you are already in goal-based territory. Chess search is a clean example.

4. Utility-based agent. Sometimes there are many goal-satisfying outcomes, and they are not equally good. Reaching the destination is not enough; reaching it safely, comfortably, and efficiently is better. Utility functions let the agent compare competing outcomes under uncertainty.

5. Learning agent. This is the most general template because it can improve from experience. It may contain any of the previous types as its performance element, but it also includes machinery for self-improvement. This is why learning agents are presented last: not because they erase the earlier architectures, but because they can wrap around them and adapt them.

09 Why learning agents are the most general architecture

The learning agent architecture in AIMA has four components: the performance element, which selects external actions; the learning element, which improves the performance element; the critic, which tells the agent how well it is doing relative to the performance measure; and the problem generator, which suggests exploratory actions that might lead to informative experience.

This architecture is powerful because it separates acting from improving. A hand-coded planner can become a learning planner. A rule-based diagnosis system can learn better probabilities. A utility-based robot can learn a better world model or policy. In that sense, learning is not one narrow technique. It is an extra dimension of generality.

Modern AI has made this point even louder. Systems that learn from data, interaction, simulation, and human feedback dominate many application areas precisely because manual programming cannot anticipate every edge case.

10 Agent architectures in code terms: from table-driven to utility-based

AIMA sometimes introduces a deliberately naive table-driven agent first. Imagine storing a giant lookup table that says, for every possible percept sequence, which action to take. In theory this exactly defines an agent function. In practice it is ridiculous because the number of percept sequences grows exponentially. Storage explodes, lookup becomes meaningless at scale, and the table cannot generalise.

That is the point of the example. It shows why we need structure. A simple-reflex architecture compresses behaviour into rules over current percepts. A model-based architecture adds internal state. A goal-based architecture adds deliberation over future possibilities. A utility-based architecture adds ranking among outcomes rather than just yes/no goal achievement.

This ladder also mirrors later chapters. Search algorithms power goal-based and utility-based decision-making. Learning can improve models, heuristics, utilities, or even raw percept-to-action policies.

11 Perception–action loop: the recurring heartbeat of AI

This loop is the heartbeat that unifies AI. Percepts arrive. The internal state or model is updated. The program chooses an action. The environment changes. New percepts arrive. Whether the agent is reactive, deliberative, utility-based, or learning-capable, it lives in this cycle.

Once you internalise this loop, later chapters stop feeling disconnected. Search is about choosing actions by simulating futures. Game playing is search with an opponent. Reinforcement learning is about improving the loop from reward. Robotics is about grounding the loop in a physical environment.

12 Common exam traps and practical gotchas

Why is a table-driven agent considered naive if it is mathematically correct?

Because correctness in principle is worthless if the representation is exponentially large and impossible to fill, store, or generalise from. It is a conceptual starting point, not a practical design.

When do we need a model-based reflex agent instead of a simple reflex one?

Whenever the current percept does not reveal the entire relevant world state. Memory and an internal model become necessary under partial observability.

Why is a utility-based agent stronger than a goal-based one?

Because goals usually divide outcomes into acceptable and unacceptable. Utility can compare multiple acceptable outcomes and handle uncertainty by ranking expected desirability.

Are all modern AI systems learning agents?

Many important ones are, but not all. Some systems deliberately combine learning components with fixed rules, planners, or safety constraints. The learning-agent template remains useful because it explains how improvement can be layered onto behaviour.

Why does Chapter 2 spend so much time on environment type before algorithms?

Because the shape of the world tells you what kind of internal machinery is necessary. A partially observable, dynamic world pushes you toward state, prediction, and adaptation. A clean fully observable world may only need simple rules or search.

13 Picking the right agent architecture is a fit problem

One mistake beginners make is assuming the “best” agent type is always the most advanced one on the ladder. In practice, the right architecture depends on the environment and the cost of sophistication. If a thermostat can solve the heating problem with a tiny condition–action rule, adding goal search, utility calculations, and online learning may be overkill. Extra machinery brings compute cost, debugging difficulty, and new failure modes. Intelligence design is therefore not about showing off the fanciest architecture; it is about matching representational power to the structure of the task.

This is also why PEAS and the six environment axes come before the architecture discussion. You do not pick the architecture first and then invent the world around it. You first ask: is the environment fully observable or partially observable? Are there explicit future goals? Are there trade-offs among several acceptable outcomes? Is the world changing? Can the designer write down enough knowledge in advance, or must the system improve from experience? Those answers point naturally toward reflex, model-based, goal-based, utility-based, or learning-heavy designs.

For example, a spam filter is often close to episodic, and a learned classifier may be enough because each email can be judged mostly on its own. A warehouse robot, by contrast, needs internal state, planning, collision handling, and probably learning for adaptation. A chess engine needs search because the right move depends on future consequences. A self-driving stack needs utility because “reaching the destination” is not enough; comfort, legality, risk, and passenger safety all matter. Seeing architecture choice as a fit problem helps you answer design questions more intelligently than simply repeating definitions.

There is a second lesson hiding here too: many real systems are hybrids. A robot vacuum may use a simple reflex rule for obstacle avoidance, a model-based map for remembering cleaned areas, a goal-based planner for room coverage, and a learning component for improving behaviour over time. Textbook categories are clean for teaching, but engineering systems often blend them because different subproblems demand different tools.

That hybrid view is useful when revising. Instead of asking “which one category is this system?”, ask “what minimum capability must this subproblem have?” If the current percept is enough, reflex may be enough. If hidden information matters, add state. If you must look ahead, add goals and search. If multiple futures are all acceptable but unequally good, add utility. If the environment shifts over time or the designer cannot hard-code every rule, add learning. This layered way of thinking makes Chapter 2 much more practical and is exactly how later AI systems are often assembled.

14 Takeaways and chapter cheatsheet

• An agent perceives through sensors and acts through actuators.
• The agent function \(f : P^* \to A\) maps percept histories to actions; the program is the implementable approximation.
• Rationality means doing the right thing given available information and the performance measure, not knowing the future.
• PEAS is the default template for specifying agent tasks.
• The six environment axes explain why some tasks need memory, planning, utility, or learning.
• The five agent types form an increasing ladder of power, with learning agents as the most general architecture.
• Good agent design is about matching the architecture to the task environment, not automatically choosing the fanciest-looking model.