The standard list (Wooldridge and Jennings, widely adopted). An intelligent agent is expected to exhibit: AUTONOMY Operates without direct human intervention, and has control over its own actions and internal state. It decides FOR ITSELF what to do to satisfy its objectives. THE DEGREE MATTERS: autonomy is a spectrum, not a switch. · a tool does exactly what it is told · a semi-autonomous agent proposes and a human approves · a fully autonomous agent acts and reports THE DESIGN RULE FROM THE APPLICATIONS TOPIC APPLIES: the degree of autonomy should be inversely proportional to the cost of an error. High-stakes irreversible decisions keep a human in the loop, not because the agent is incapable but because accountability must rest somewhere. REACTIVITY Perceives its environment and RESPONDS IN A TIMELY FASHION to changes that occur in it. "Timely" is the operative word, and it connects directly to the real-time design topic: a response that is correct but late is a failure in a hard real-time setting. PRO-ACTIVENESS Does not simply act in response to its environment; it exhibits GOAL-DIRECTED behaviour by TAKING THE INITIATIVE. THE TENSION WITH REACTIVITY IS THE CENTRAL DESIGN PROBLEM OF AGENT ARCHITECTURE: · a purely reactive agent never pursues anything; it is a collection of reflexes · a purely proactive agent pursues a plan while the world changes underneath it, and continues executing a plan whose preconditions no longer hold · BALANCING THEM means being persistent enough to achieve goals but responsive enough to abandon a goal when it becomes impossible or pointless A delivery robot that will not stop for an obstacle is too proactive; one that abandons its route at every distraction is too reactive. SOCIAL ABILITY Interacts with other agents — and possibly humans — via some COMMUNICATION LANGUAGE, and may engage in cooperation, coordination and negotiation to satisfy its objectives. This is the property that makes MULTI-AGENT SYSTEMS a distinct field: coordinating self-interested agents is a game-theoretic problem, not merely an engineering one. OTHER PROPERTIES COMMONLY LISTED: LEARNING / ADAPTIVITY Improves performance over time from experience. Note that an agent can be intelligent without learning — a well-designed expert system reasons expertly and never learns — so this is desirable rather than definitional. RATIONALITY Acts to achieve its goals and does not act so as to prevent them, given its beliefs. Recall from the concepts topic that this does not require omniscience. BENEVOLENCE The assumption that agents do not have conflicting goals and will therefore always try to do what is asked. A convenient simplifying assumption, and FALSE in most real multi-agent settings — which is why negotiation exists. VERACITY Will not knowingly communicate false information. MOBILITY The ability to move around a network or physical environment. TEMPORAL CONTINUITY A continuously running process rather than a one-shot computation that terminates. This distinguishes an agent from a function call, and it is why agents have persistent internal state. FLEXIBILITY and ROBUSTNESS Multiple ways to achieve a goal; graceful degradation when something fails.

WHAT MAKES AN AGENT DIFFERENT FROM AN ORDINARY PROGRAM — a question worth answering precisely, because "agent" is used loosely: ORDINARY PROGRAM AGENT ───────────────────────────────────────────────────────────── invoked, runs, terminates runs CONTINUOUSLY computes a function of its maintains STATE across input interactions does what it is told decides what to do no notion of goals has objectives it pursues passive PROACTIVE as well as reactive no model of its environment perceives and models its environment ───────────────────────────────────────────────────────────── THE HONEST BOUNDARY: these are matters of degree, and calling a program an agent adds nothing if it merely responds to input. The label earns its place when the system's behaviour must be described in terms of what it is TRYING to do rather than what it computes — which is the INTENTIONAL STANCE (Dennett): describing a system using beliefs, desires and intentions because doing so is a more compact and predictive description than the mechanical one. THE PROPERTIES CONFLICT — and stating the trade-offs is what distinguishes understanding from recitation: AUTONOMY vs PREDICTABILITY The more freedom an agent has, the less you can guarantee about what it will do. A fully autonomous agent may find a strategy nobody anticipated — including strategies nobody wanted, which is the reward-hacking result from the agents topic. MITIGATION: constrain the ACTION SPACE rather than trying to anticipate the behaviour. An agent that cannot delete records will not find a clever reason to. REACTIVITY vs PRO-ACTIVENESS as above — persistence against responsiveness. RESPONSE TIME vs DELIBERATION QUALITY A better decision takes longer to compute, and in a dynamic environment the world moves while you deliberate. The classic resolution is a LAYERED ARCHITECTURE: fast reactive behaviours at the bottom guaranteeing a timely response, slower deliberative planning above, with the reactive layer able to override. WORKED — a delivery robot with a 100 ms control loop: the reactive layer must decide within 100 ms, so it can only run cheap collision checks the planning layer may take 2 seconds to replan a route, during which the reactive layer keeps the robot safe → 20 control cycles pass during one replan, which is why the two layers must be separate. A single deliberative loop that took 2 seconds to decide whether to brake would be lethal. SOCIAL ABILITY vs SELF-INTEREST An agent maximising its own utility may do so at the expense of the group. This is the TRAGEDY OF THE COMMONS in software form, and it appears in real systems: independently rational retry policies produce a thundering herd that keeps a recovering service down — which is exactly the failure the inter-organisational computing topic described. LEARNING vs STABILITY A learning agent's behaviour changes over time, so a system validated on Monday may behave differently on Friday. Regulated domains often forbid learning in deployment for precisely this reason: the certified artefact must remain the artefact that was certified. THE PRACTICAL PATTERN IS TO LEARN OFFLINE AND DEPLOY A FROZEN MODEL, so that changes pass through the same change-control process as any other release.

A WORKED SPECIFICATION, because the properties are only useful when committed to concretely. An agent that manages revision scheduling in a study tracker: PROPERTY THE COMMITMENT ───────────────────────────────────────────────────────────── AUTONOMY SEMI-autonomous. It may reorder and suggest, but it may not mark a topic complete on the student's behalf, and it may not change the exam date. Rationale: those are the student's claims about their own knowledge, and an agent asserting them would corrupt the data the agent itself learns from. REACTIVITY Recomputes within 500 ms of a topic being ticked, so the next suggestion is current when the student looks for it. PRO-ACTIVENESS Initiates a revision prompt when a topic has been untouched for longer than its estimated retention window — WITHOUT being asked. This is the property that makes it an agent rather than a query. SOCIAL ABILITY None required. Single-agent environment. Explicitly recorded as "not needed", so a later reader knows it was considered. LEARNING Learns the individual student's retention rate from their tick history. Learns OFFLINE, nightly; the deployed model is frozen between updates so behaviour is reproducible for a given day. TEMPORAL Persistent per user; state survives sign- CONTINUITY out, because it lives server-side. VERACITY Never presents an estimate as a certainty. A predicted retention of 60% is shown as an estimate, because a student who trusts a wrong confident prediction studies the wrong thing. ───────────────────────────────────────────────────────────── WHAT THE EXERCISE PRODUCED: two hard limits on autonomy with reasons, a numeric reactivity budget, an explicit "not needed" for social ability, and a decision to freeze the learned model between updates. NONE OF THAT IS OBVIOUS FROM "BUILD A REVISION SCHEDULER", and every item would otherwise have been decided implicitly by whoever wrote the code. THE GENERAL POINT: THE PROPERTIES ARE A CHECKLIST FOR SPECIFYING AN AGENT, in the same way PEAS is a checklist for specifying its task environment. Going through them forces the questions that are expensive to answer late — particularly the autonomy limits, which are a requirements decision masquerading as an implementation detail.