← AIMA

BOOK NOTES · AIMA · CHAPTER 2

Chapter 2 — Intelligent Agents.

artificial-intelligencechapter-2master's-notesfirst-principles

// the one-minute version

Agents and environments, rationality, PEAS task specifications, environment properties, reflex and model-based architectures, goals, utilities, learning agents, and safe task design. The chapter is best remembered as a sequence of explicit choices: define the problem, preserve the information that matters, specify how alternatives are produced and scored, and test the resulting behavior under conditions that could prove the design wrong.

Consider a warehouse robot at a crowded packing station. It sees partial camera views, receives delayed inventory updates, shares aisles with people, and must trade speed against collision risk. Saying 'move boxes efficiently' hides nearly every design decision.

An agent receives a limited percept history, maintains only an approximation of the world, and must choose before uncertainty disappears. This is why the chapter begins before the algorithm. The real work is to decide what counts as state, improvement, success, and unacceptable failure. Once those nouns are explicit, equations and pseudocode become tools for answering a concrete question rather than rituals copied from a library.

This is an independent companion to Artificial Intelligence: A Modern Approach by Stuart Russell and Peter Norvig, 4th US edition. It follows the official chapter structure, but its prose, examples, diagram, derivations, study prompts, and evaluation advice are original. It is written for a master's student who must be able to explain not just what an algorithm does, but why its assumptions make the result meaningful and where the evidence stops.

chapter promiseBy the end, you should be able to reconstruct intelligent agents from first principles, work one mechanism by hand, identify invalid shortcuts, compare a simple baseline fairly, and design an experiment whose result can be defended in a viva or research review.

01 Start with the world, not the algorithm

Agents and environments, rationality, PEAS task specifications, environment properties, reflex and model-based architectures, goals, utilities, learning agents, and safe task design.

Write the problem in one sentence with four nouns: observation, decision, objective, and evidence. The observation is all information legitimately available at decision time. The decision is the output or action the system controls. The objective describes preference and cost. The evidence is the held-out observation that would support or contradict a claim. If one noun is missing, a mathematically correct implementation can optimize a task nobody intended.

Next identify the boundary between world state and system state. The world contains more detail than any representation can preserve. A search node, feature vector, belief state, chromosome, particle, rule base, prototype, or detector is therefore a deliberate compression. Good compression retains distinctions that change future decisions. Bad compression merges situations that require different actions or preserves detail that expands computation without improving choice.

Then establish a baseline. A random policy, straight-line heuristic, nearest prototype, fixed rule, linear model, or uniform sampler may look unsophisticated, but it reveals whether the problem is difficult and whether a complicated mechanism has earned its cost. The baseline receives the same data, evaluation budget, and stopping rule. Without that discipline, complexity is mistaken for progress.

AIMA Chapter 2: the reasoning loop WORLDWhat can the agent see?STATEWhat must it remember?CHOICEWhich action is rational?EVIDENCEDid the claim survive? A failure returns to assumptions, representation, objective, or evidence.

A compact map for reading the chapter: every impressive output should be traceable back to an explicit problem and test.

02 Conceptual map: five pieces that must not blur together

Read the concepts below as connected modules. Each owns a different decision and therefore a different failure mode. Their boundaries are the scaffolding for derivations, implementations, and error analysis.

1. PEAS as a task contract

Performance measure, Environment, Actuators, and Sensors force a vague product request into observable terms. A bad performance measure can make competent optimization produce unwanted behavior.

Build the idea from a contract rather than a slogan. Name the information available before the computation, the state or representation carried forward, the candidates the mechanism can consider, and the rule that makes one candidate preferable. Then name the output passed to the next stage. In intelligent agents, this discipline prevents a familiar mistake: observing a good final answer and retroactively assuming that every hidden step was correct.

The first-principles question is, what uncertainty or search burden does peas as a task contract remove? If it compresses observations, identify what disappears. If it searches, identify which alternatives are unreachable. If it learns, identify the feedback signal and the distribution that generated it. If it ranks, state whether the score is calibrated, ordinal, or only locally meaningful. These distinctions turn vocabulary into an implementable model.

For a master's-level experiment, construct one clean example where this mechanism should help, one minimal counterexample that violates its assumption, and one ablation that removes only this mechanism. Keep data, evaluation budget, and stopping rule fixed. A measured change then supports a narrow causal claim about the component rather than a vague claim about the entire system.

Finally, keep peas as a task contract distinct from environment dimensions. They cooperate but answer different questions. Collapsing them makes diagnosis impossible: a weak result could come from missing information, an unsuitable representation, bad optimization, invalid candidates, or a metric that rewards the wrong behavior. Clear interfaces are useful even when one end-to-end model learns several stages jointly. That is the durable habit behind agent design.

2. Environment dimensions

Fully versus partially observable, deterministic versus stochastic, episodic versus sequential, static versus dynamic, discrete versus continuous, and single- versus multiagent properties determine which internal machinery is necessary.

Build the idea from a contract rather than a slogan. Name the information available before the computation, the state or representation carried forward, the candidates the mechanism can consider, and the rule that makes one candidate preferable. Then name the output passed to the next stage. In intelligent agents, this discipline prevents a familiar mistake: observing a good final answer and retroactively assuming that every hidden step was correct.

The first-principles question is, what uncertainty or search burden does environment dimensions remove? If it compresses observations, identify what disappears. If it searches, identify which alternatives are unreachable. If it learns, identify the feedback signal and the distribution that generated it. If it ranks, state whether the score is calibrated, ordinal, or only locally meaningful. These distinctions turn vocabulary into an implementable model.

For a master's-level experiment, construct one clean example where this mechanism should help, one minimal counterexample that violates its assumption, and one ablation that removes only this mechanism. Keep data, evaluation budget, and stopping rule fixed. A measured change then supports a narrow causal claim about the component rather than a vague claim about the entire system.

Finally, keep environment dimensions distinct from reflex and model-based agents. They cooperate but answer different questions. Collapsing them makes diagnosis impossible: a weak result could come from missing information, an unsuitable representation, bad optimization, invalid candidates, or a metric that rewards the wrong behavior. Clear interfaces are useful even when one end-to-end model learns several stages jointly. That is the durable habit behind agent design.

3. Reflex and model-based agents

A simple reflex maps the current percept to an action. A model-based agent maintains hidden state so it can act when the present observation does not reveal everything relevant.

Build the idea from a contract rather than a slogan. Name the information available before the computation, the state or representation carried forward, the candidates the mechanism can consider, and the rule that makes one candidate preferable. Then name the output passed to the next stage. In intelligent agents, this discipline prevents a familiar mistake: observing a good final answer and retroactively assuming that every hidden step was correct.

The first-principles question is, what uncertainty or search burden does reflex and model-based agents remove? If it compresses observations, identify what disappears. If it searches, identify which alternatives are unreachable. If it learns, identify the feedback signal and the distribution that generated it. If it ranks, state whether the score is calibrated, ordinal, or only locally meaningful. These distinctions turn vocabulary into an implementable model.

For a master's-level experiment, construct one clean example where this mechanism should help, one minimal counterexample that violates its assumption, and one ablation that removes only this mechanism. Keep data, evaluation budget, and stopping rule fixed. A measured change then supports a narrow causal claim about the component rather than a vague claim about the entire system.

Finally, keep reflex and model-based agents distinct from goals and utility. They cooperate but answer different questions. Collapsing them makes diagnosis impossible: a weak result could come from missing information, an unsuitable representation, bad optimization, invalid candidates, or a metric that rewards the wrong behavior. Clear interfaces are useful even when one end-to-end model learns several stages jointly. That is the durable habit behind agent design.

4. Goals and utility

Goals distinguish success from failure; utility ranks competing successful states and expresses tradeoffs. Expected utility is essential when actions have uncertain outcomes.

Build the idea from a contract rather than a slogan. Name the information available before the computation, the state or representation carried forward, the candidates the mechanism can consider, and the rule that makes one candidate preferable. Then name the output passed to the next stage. In intelligent agents, this discipline prevents a familiar mistake: observing a good final answer and retroactively assuming that every hidden step was correct.

The first-principles question is, what uncertainty or search burden does goals and utility remove? If it compresses observations, identify what disappears. If it searches, identify which alternatives are unreachable. If it learns, identify the feedback signal and the distribution that generated it. If it ranks, state whether the score is calibrated, ordinal, or only locally meaningful. These distinctions turn vocabulary into an implementable model.

For a master's-level experiment, construct one clean example where this mechanism should help, one minimal counterexample that violates its assumption, and one ablation that removes only this mechanism. Keep data, evaluation budget, and stopping rule fixed. A measured change then supports a narrow causal claim about the component rather than a vague claim about the entire system.

Finally, keep goals and utility distinct from learning-agent anatomy. They cooperate but answer different questions. Collapsing them makes diagnosis impossible: a weak result could come from missing information, an unsuitable representation, bad optimization, invalid candidates, or a metric that rewards the wrong behavior. Clear interfaces are useful even when one end-to-end model learns several stages jointly. That is the durable habit behind agent design.

5. Learning-agent anatomy

A performance element acts, a critic evaluates, a learning element improves behavior, and a problem generator encourages informative exploration. Keeping these roles distinct clarifies feedback and failure.

Build the idea from a contract rather than a slogan. Name the information available before the computation, the state or representation carried forward, the candidates the mechanism can consider, and the rule that makes one candidate preferable. Then name the output passed to the next stage. In intelligent agents, this discipline prevents a familiar mistake: observing a good final answer and retroactively assuming that every hidden step was correct.

The first-principles question is, what uncertainty or search burden does learning-agent anatomy remove? If it compresses observations, identify what disappears. If it searches, identify which alternatives are unreachable. If it learns, identify the feedback signal and the distribution that generated it. If it ranks, state whether the score is calibrated, ordinal, or only locally meaningful. These distinctions turn vocabulary into an implementable model.

For a master's-level experiment, construct one clean example where this mechanism should help, one minimal counterexample that violates its assumption, and one ablation that removes only this mechanism. Keep data, evaluation budget, and stopping rule fixed. A measured change then supports a narrow causal claim about the component rather than a vague claim about the entire system.

Finally, keep learning-agent anatomy distinct from peas as a task contract. They cooperate but answer different questions. Collapsing them makes diagnosis impossible: a weak result could come from missing information, an unsuitable representation, bad optimization, invalid candidates, or a metric that rewards the wrong behavior. Clear interfaces are useful even when one end-to-end model learns several stages jointly. That is the durable habit behind agent design.

compressionDefine the state, define the legal alternatives, define what information changes preference, define the update or decision rule, and define held-out evidence. The algorithm's name is less important than this contract.

03 Derive the central mechanism

An equation becomes useful only when its symbols correspond to inspectable objects. Mark observed values, learned values, hyperparameters, random variables, and outputs. Record units and legal ranges. Then calculate one small case by hand before trusting an implementation.

// central relationshipAgent as a mapping from history to action
f : P* → A, a_t = f(p_1, …, p_t)The abstract agent function maps the complete percept history to an action. An implemented program approximates that function using internal state, a model, goals, utility, and learned knowledge on a particular architecture.

To reconstruct the mechanism, begin with the smallest nontrivial input. Enumerate candidates explicitly. Compute one score or update and predict its direction. Check invariants: probabilities should normalize, legal states should remain legal, costs should have consistent units, and the update should reduce the intended error or shift search in the stated direction. A tiny trace catches sign errors and hidden assumptions that a large benchmark conceals.

Separate the model from the decision procedure. A model may estimate a value, heuristic, affinity, membership grade, fitness, or transition score. A policy, search strategy, selection operator, threshold, or defuzzifier converts that estimate into behavior. Changing the second can alter outcomes while the learned parameters stay fixed. Both therefore belong in the versioned system specification.

Also separate the optimization objective from the scientific claim. Training loss, fitness, reward, or internal error is a surrogate. The claim may concern solution quality, safety, robustness, data efficiency, interpretability, or adaptation under drift. Show empirically that improvement in the surrogate predicts the behavior named in the claim.

Finally state computational cost. Time may scale with branching factor, population, dimension, horizon, number of prototypes, rule count, or expensive objective calls. Memory may be the limiting resource. A method that wins with ten times the evaluations has answered a different question from a method that wins under an equal budget.

04 The running story, step by step

From a real request to inspectable evidence

Consider a warehouse robot at a crowded packing station. It sees partial camera views, receives delayed inventory updates, shares aisles with people, and must trade speed against collision risk. Saying 'move boxes efficiently' hides nearly every design decision.

Step 1 — freeze the decision context. Record what is known now and what is unavailable until later. Remove labels, future observations, expert corrections, and simulator internals that production will not possess. This step prevents leakage from becoming apparent intelligence.

Step 2 — choose representation. Translate the problem into states, features, rules, vectors, trees, populations, or prototypes. Demonstrate that legal real situations have representations and that elementary moves can reach the solutions of interest. Document repair and normalization.

Step 3 — establish preference. Define cost, utility, loss, fitness, affinity, membership, or value. Use several toy candidates to show the ordering matches domain intent. Try to game the objective deliberately; every successful exploit reveals a missing term or constraint.

Step 4 — run the mechanism. Save intermediate states: frontier size, value backups, weight updates, population diversity, prototype motion, pheromone, detector coverage, or rule firing. A final result without a trace is hard to debug and easy to misinterpret.

Step 5 — make the decision. Apply the actual cutoff, selection, search budget, action constraint, or output conversion. Preserve uncertainty when the application permits abstention, clarification, escalation, or a set of alternatives.

Step 6 — test the claim. Compare with simple and strong baselines under matched information and compute. Use multiple seeds for stochastic procedures, confidence intervals for sampled evaluations, and slices for conditions that stress assumptions.

Step 7 — inspect failures as mechanisms. Group errors by representation, objective, optimization, inference, distribution shift, and measurement. Count each category. The result should tell the next researcher what to change and what not to change.

05 Common traps and why they fail

common catches & gotchas

  • Writing an agent architecture before defining PEAS. The visible symptom is often a plausible average result that breaks under one targeted condition. Trace the failure to the precise assumption, add that condition as a named evaluation slice, and repair the experimental contract before increasing model complexity.
  • Assuming the latest percept contains the whole state. The visible symptom is often a plausible average result that breaks under one targeted condition. Trace the failure to the precise assumption, add that condition as a named evaluation slice, and repair the experimental contract before increasing model complexity.
  • Using a reward that can be gamed. The visible symptom is often a plausible average result that breaks under one targeted condition. Trace the failure to the precise assumption, add that condition as a named evaluation slice, and repair the experimental contract before increasing model complexity.
  • Confusing rationality with moral acceptability. The visible symptom is often a plausible average result that breaks under one targeted condition. Trace the failure to the precise assumption, add that condition as a named evaluation slice, and repair the experimental contract before increasing model complexity.

These errors share a structure: two layers that need separate evidence are silently joined. Performance on observed samples becomes a claim about future environments; a biological analogy becomes a guarantee; a model score becomes a safe action; a relative comparison becomes global quality; a visually attractive result becomes a validated structure. Repair the argument by naming the missing layer and measuring it directly.

When results look suspiciously strong, audit leakage before inventing a sophisticated explanation. Duplicated records, preprocessing fitted before splitting, future information, repeated simulator seeds, benchmark-specific tuning, and using the test set for model selection can all create clean tables and invalid conclusions. Reproducibility begins with data lineage.

06 A master's-level evaluation plan

Start with a claim matrix. For every claim, name the metric, unit of analysis, baseline, ablation, stress condition, uncertainty estimate, and confounder. “Works better” is not a claim. “Reduces median objective evaluations by 20% on held-out functions of the same dimensional range, at equal success threshold and tuning budget” can be tested.

Correctness

Verify toy cases, invariants, boundary conditions, and a trace against a hand calculation. A benchmark cannot rescue an incorrect update.

Comparative quality

Match data access, evaluations, wall-clock accounting, stopping criteria, and tuning budget across baselines.

Robustness

Vary seeds, noise, initial conditions, dimension, constraints, drift, and adversarial or rare cases that attack assumptions.

Operational value

Measure latency, memory, sample cost, safety violations, interpretability burden, and human intervention in the intended workflow.

For stochastic algorithms, publish the distribution rather than the single best run. Report sample count, median and spread, failure rate, and paired comparisons when runs share instances. Averages alone can hide catastrophic failures and heavy tails. For learning systems, keep training, development, and final test decisions separate; for search, account for every objective or simulator evaluation.

Use ablations to establish responsibility. Remove or neutralize the component named in the claim while holding other choices fixed. If the difference disappears, the component may be redundant or the benchmark may not exercise it. If a gain appears only after a much larger tuning budget, report the budget as part of the method.

Close with validity limits: which environments, dimensions, data distributions, noise levels, and resource budgets were tested? Which were not? A careful boundary increases credibility because it prevents the experiment from claiming more than it observed.

07 Study lab

Each exercise below is a miniature research loop. Keep a ledger containing the question, exact input, implementation version, seed, budget, result, error category, and interpretation. Separate observation from explanation.

01 · Write PEAS descriptions for a taxi and a tutoring agent

Write a hypothesis first. Record the smallest reproducible input, expected behavior, baseline, measurement, random seed when relevant, and one result that would disconfirm your expectation. Finish with an error table, not only a score.

02 · Classify both environments along every standard dimension

Write a hypothesis first. Record the smallest reproducible input, expected behavior, baseline, measurement, random seed when relevant, and one result that would disconfirm your expectation. Finish with an error table, not only a score.

03 · Convert three reflex rules into a stateful design

Write a hypothesis first. Record the smallest reproducible input, expected behavior, baseline, measurement, random seed when relevant, and one result that would disconfirm your expectation. Finish with an error table, not only a score.

04 · Identify reward-hacking paths in a warehouse objective

Write a hypothesis first. Record the smallest reproducible input, expected behavior, baseline, measurement, random seed when relevant, and one result that would disconfirm your expectation. Finish with an error table, not only a score.

After the four exercises, write one page connecting them. Explain which assumption was most fragile, which baseline was hardest to beat, and which metric changed your judgment. If the exercises merely confirm every expectation, design a harder counterexample.

08 Oral-exam questions

What is the problem this chapter solves before any algorithm is named?

Agents and environments, rationality, PEAS task specifications, environment properties, reflex and model-based architectures, goals, utilities, learning agents, and safe task design. A complete answer names the observation, representation, decision, objective, environment assumptions, and evidence required for the claim.

What does the central equation hide?

It hides representation choices, parameter selection, candidate generation, computational budget, and the gap between an internal score and a real decision. Reconstruct those layers around agent as a mapping from history to action.

How could a strong reported number be misleading?

Leakage, unmatched computation, favorable seeds, a weak baseline, an unrepresentative test set, or a metric insensitive to important failures can all inflate the conclusion without changing the implementation.

What experiment would most efficiently falsify the chapter's main assumption?

Use a minimal case that removes or reverses the information the method depends on, then compare the full method with an ablation at the same budget. State the predicted outcome before running it.

When should a simpler method win?

When data or evaluations are scarce, assumptions fit the simple model, latency and interpretability matter, or the complex method cannot demonstrate a stable gain under fair comparison. Complexity must purchase measurable behavior.

09 Complete chapter summary

Agents and environments, rationality, PEAS task specifications, environment properties, reflex and model-based architectures, goals, utilities, learning agents, and safe task design.

The surface lesson is a set of definitions and algorithms. The deeper lesson is a workflow for trustworthy intelligent systems. Begin with the world and the decision. Compress that world into a representation while documenting what is lost. Define a preference that reflects the real purpose and cannot be trivially gamed. Use an update, search, or inference procedure whose invariants you can trace. Compare fairly. Then test the system where its assumptions are weakest.

  • PEAS as a task contract is a separate design responsibility; define its inputs, assumptions, and evidence.
  • Environment dimensions is a separate design responsibility; define its inputs, assumptions, and evidence.
  • Reflex and model-based agents is a separate design responsibility; define its inputs, assumptions, and evidence.
  • Goals and utility is a separate design responsibility; define its inputs, assumptions, and evidence.
  • Learning-agent anatomy is a separate design responsibility; define its inputs, assumptions, and evidence.

The central relationship—f : P* → A, a_t = f(p_1, …, p_t)—should now function as a map rather than a formula to memorize. You should be able to point to every term in a running example, explain how it changes, predict a failure, and connect the internal computation to external evidence. That ability is what turns chapter knowledge into research competence.

Use this final revision sequence: tell the running story without terminology; redraw the system with terminology; derive one update; compare two variants; name one invalid evaluation; design one ablation; and state the boundary of the strongest defensible claim. If any step is vague, return to the relevant section instead of rereading passively.

copyright and scopeThis is an independent educational companion, not a replacement for the textbook. It uses original wording and examples and covers the chapter's main learning arc for study. Consult the official AIMA book site and the published book for the authors' definitions, figures, pseudocode, citations, exercises, and precise treatment.
← Chapter 1next: Chapter 3 →
© cvam — written in plaintext, served warm