Before you build, two questions decide your architecture: should this be one agent or several, and what triggers it, a person chatting, or an event? This is a decision guide: when to split into specialists, the three ways to organize them, and how event-driven agents run without a human.
New to these words? Read chapter 02 "Key terms". Agents working together: chapter 29. Serving many customers: chapter 32.Start with one narrowly scoped agent. Split into several only when one agent gets unwieldy: the prompt grows complex, tool selection gets unreliable, performance drops. The test is like a team, you do not hire one person for sales, engineering, support, and finance. Instead of one agent doing thirty tasks, build three that each do ten related ones: clearer instructions, simpler tools, easier to debug.
Tasks have a natural order. Agent 1 retrieves, agent 2 analyzes, agent 3 writes the report. A pipeline.
A supervisor reads the request, works out the intent, and delegates to the right specialist. A widely used pattern.
Agents collaborate dynamically, with no central boss, handing off to whoever fits the moment.
A file lands in S3, or an email arrives. No one is chatting.
Amazon EventBridge catches the event.
A Lambda invokes the agent on Runtime.
The agent processes it and scores its confidence.
It routes the result: act automatically, or send for human review.