What Are Agents? The Building Blocks of AI Teams
What Are Agents? The Building Blocks of AI Teams
The Day a Single Assistant Failed
It is 7:42 a.m. on a Friday, and Maya is already in trouble. She is the student council vice president at Brookline High, and tonight is the fall welcome dance — the first big event of the year, the one that determines whether the new council looks competent or chaotic. Three hundred students are coming. The gym has to be transformed by 5 p.m. A catering company is delivering food at 6. Parents are volunteering as drivers. Two DJs are scheduled. A weather front is moving in from the west.
Maya's phone is open. She is talking to a popular voice assistant, the kind that comes baked into every modern smartphone.
*"Hey, can you plan the whole event?"*
The assistant cheerfully replies that it can help with calendar reminders, send a few messages, and check the weather. It cannot book the gym. It cannot text all the parents at once. It cannot coordinate three volunteers to set up tables in parallel. It cannot adjust the catering order if the weather forces everything indoors. It cannot, in short, do what Maya needs: orchestrate a hundred tiny decisions in real time, some of them based on information it does not have.
By 8:15 a.m., Maya is hunched over her laptop with four browser tabs open, three group chats, a spreadsheet, and a friend on FaceTime. Things are getting done, but they are getting done because Maya is acting as the *agent* in the loop — perceiving, deciding, delegating, and adjusting. The "smart assistant" on her phone is, in the language we will use in this chapter, a tool. A useful tool. But not an agent.
This book is about what happens when we stop treating AI as a single all-knowing brain and start designing AI teams: collections of specialized software agents, each with its own sensors, its own goals, and its own limited view of the world, that coordinate to get things done. The teams you will build in this book will not look like the lonely chatbot on Maya's phone. They will look more like a well-run student council: a president who delegates, a treasurer who tracks the budget, a logistics lead who books rooms, and a social media manager who talks to the audience. Each member has a job. Each member has limits. Together, they pull off something no individual could.
But before we can build squads, we have to nail down a deceptively simple question: what is an agent, exactly?
What Exactly Is an Agent?
The word *agent* gets thrown around a lot in tech, often loosely. People say "AI agent" when they mean a chatbot. They say "intelligent agent" when they mean a thermostat. They say "software agent" when they mean a script that crawls the web. For this book to be useful to you, we need a precise definition. The one we will use is the standard definition from artificial intelligence research, refined over decades by people like Stuart Russell, Peter Norvig, and Michael Wooldridge. It is short, but every word matters.
> An agent is any entity that can perceive its environment through sensors, act upon that environment through actuators, and is driven by goals.
Let's unpack that sentence.
Perceive through sensors. A *sensor* is anything that gives the agent information about the world around it. For a robot vacuum, sensors are the bump detectors, the cliff sensors underneath, the camera on top, and the wheel encoders that count rotations. For a self-driving car, sensors include cameras, radar, lidar, GPS, and accelerometers. For a software agent that trades stocks, sensors are the price feeds, the news headlines, and the social media streams it monitors. For a chatbot on your phone, the sensor is essentially the text you type or the audio from your microphone. The point is that an agent does not operate in a vacuum — it is always *receiving* signals from somewhere.
Act through actuators. An *actuator* is the opposite of a sensor: it is the part of the agent that changes the world. The Roomba's wheels and brush motor are actuators. The self-driving car's steering, throttle, and brakes are actuators. The stock-trading agent's actuators are the network connections that send buy and sell orders to an exchange. The chatbot's actuators are the screen pixels and the speaker that produce output. Without actuators, an entity is just a passive observer, not an agent.
Driven by goals. Here is the most important part. A thermostat *is* technically an agent in the strictest sense — it has a temperature sensor and it can turn a heater on or off. But a thermostat with a goal of "keep the room at 68°F" is a much more interesting agent than a thermostat that just blindly turns on at 8 a.m. The goal is what makes the perception–action loop meaningful. The agent asks, at every moment: *given what I am sensing right now, what action moves me closer to my goal?*
We can draw the classic agent loop as a cycle:
```mermaid flowchart LR Env[Environment] -->|stimuli| Sen[Sensors] Sen --> Per[Perception] Per --> Rea[Reasoning] Rea --> Act[Action] Act --> Eff[Actuators] Eff -->|change| Env ```
The agent perceives the environment through its sensors, thinks about what to do (reasoning), picks an action, and executes that action through its actuators. The action changes the environment, which produces new stimuli, and the cycle repeats. Forever. That *forever* is important: an agent is not a one-shot program. It is a continuous loop, always sensing, always deciding, always acting.
There is a more formal way to write this. Let the set of all possible perceptions be $P$, and the set of all possible actions be $A$. An agent implements a function:
$$f : P^* \rightarrow A$$
That is, the agent looks at the *entire history* of everything it has ever perceived ($P^*$, the sequence of all past perceptions) and produces a single action. The function $f$ is the agent's *policy* or *behavior*. Different agents have different functions. A perfect chess engine has a function that, given the full history of the game, picks the move most likely to lead to a win. A wandering Roomba has a function that, given its bump sensor history, picks a wheel direction. A self-driving car has a function that, given a continuous stream of camera frames and radar returns, picks a steering angle and acceleration.
The goal of the agent is encoded somewhere. Sometimes it is explicit, like a target temperature. Sometimes it is implicit, baked into the policy by the designer (a chess engine's policy is built by training it on millions of games whose win/loss outcomes define the implicit goal of "win"). Sometimes it is learned, as in a reinforcement learning system where the agent gradually tweaks its policy to maximize a numerical reward signal.
You will see this loop again and again in this book. It is the heartbeat of every system we will build.
Quick check: is a calculator an agent?
A classic classroom puzzle. A calculator takes input (perception), runs a function, and produces output (action). By the bare definition, it has a sensor (the keypad), an actuator (the display), and a goal (display the right answer). So is it an agent?
In this book, the answer is: technically yes, but a boring one. It has no *autonomy* — it does exactly what you tell it. It has no reactivity to a changing world — the world is the keys you press. It has no proactivity — it will never volunteer an answer you did not ask for. It has no social ability — it will not talk to other agents. The next section will dig into the four properties that turn a "thing that does a function" into a *true* agent in the sense we care about. Spoiler: the calculator fails all four.
The Four Properties of True Agents
The strictest definition of an agent fits too much. Rocks, technically, "perceive" gravity. So we add four properties that, taken together, separate agents from ordinary software and ordinary machines. These are the properties that will matter when you start designing a