PEAS and CATWOE: Two Frameworks That Independently Arrived at the Same Idea
Before you build an agent, you need to specify what it actually is — and it turns out two entirely separate disciplines, working on entirely separate problems, converged on the same first move: force the specification into the open before any design decision gets made by accident. This page works through both frameworks against the same example, so the overlap (and the real difference) is visible directly rather than argued about in the abstract.
PEAS: specifying an agent from the inside
Russell and Norvig's PEAS framework names four things any rational agent specification needs before anything else: Performance measure (how do you know it's doing well), Environment (what is it operating in), Actuators (how does it act), Sensors (how does it perceive)1. Skipping any one of these doesn't just leave a gap — it lets the actual specification happen implicitly, inside whatever code gets written first, which is exactly the failure mode this site's material on assumptions engineering warns about in a different context.
PEAS comes with a second, equally useful piece of vocabulary: a taxonomy of environment properties that determines how hard the agent's job actually is — fully or partially observable (can the agent see everything relevant right now), deterministic or stochastic (does the same action always have the same result), episodic or sequential (does one decision affect the next), static or dynamic (does the world change while the agent is thinking), discrete or continuous, and single-agent or multi-agent1.
The same system, specified with CATWOE
This site's Software Engineering material already builds a full example around a university assignment-extension system, using Checkland's CATWOE to force multiple stakeholders' worldviews into the open before designing anything2. Reuse the same system here, but now imagine automating the triage decision with an agent, and specify it both ways.
CATWOE, from the student-support worldview: Customers are students requesting extensions; Actors are the personal tutors and panel; the Transformation turns disclosed circumstances into a fair, timely decision; the Weltanschauung is that extensions exist to let work be judged fairly despite hardship; Owners are the department; Environmental constraints are university regulation and data protection law.
PEAS, for an agent automating the same decision: Performance measure might be consistency with panel decisions on comparable past cases, turnaround time, and appeal rate. Environment is partially observable (the agent can't directly verify a student's claimed circumstances), stochastic (requests arrive unpredictably and evidence quality varies), sequential (a lenient or strict pattern of past decisions plausibly affects what a fair decision looks like next time), dynamic (policy can change mid-year), and single-agent unless multiple automated triage systems interact. Actuators are the decision notification and record update. Sensors are the submitted form, uploaded evidence, and the student's request history.
Where they overlap, and where they don't
Both frameworks force the same discipline: write the specification down before building anything, because an unspecified system still makes these decisions, just implicitly and unaccountably. But they interrogate different blind spots, and a complete design needs both.
PEAS can be perfectly well-formed while silently serving only one stakeholder's worldview. Nothing in a PEAS specification asks whose definition of "doing well" the performance measure encodes. An agent optimised purely for turnaround time and appeal rate is a coherent, buildable PEAS specification — and it's also exactly the exam-board Weltanschauung from the CATWOE comparison, smuggled in as if it were a neutral engineering choice rather than a contested value judgement. CATWOE is what catches that; PEAS has no equivalent check built in.
CATWOE has no equivalent of PEAS's environment taxonomy, and that taxonomy is doing real work: knowing the environment is partially observable and stochastic tells you directly that a rule-based, fully-deterministic agent is the wrong architecture for this problem before you've written a line of code, in a way "the environment is messy" doesn't capture with the same precision.
Practical implication: specify an agent with PEAS, and separately ask whose CATWOE root definition its performance measure actually encodes. If you can't answer that second question, the first specification was never as neutral as it looked.
Where this connects
- Soft Systems Methodology: Untangling Messy Problems with CATWOE — the full CATWOE method and the assignment-extension example this page builds on.
- Where Requirements Get Hard: Wicked Problems, CATWOE's Slippery Names, and Assumptions Engineering — why a well-formed specification isn't the same claim as a complete one, argued from the requirements-engineering side.
- Agent Archetypes: Five Tiers on One Diagram — what an agent does with a PEAS specification once it has one, from bare reflex through to imagination-augmented.