We ended the last chapter on a shift you may have felt without naming. You built context, so the AI knows your world. You built skills, so it knows your methods. Put those together and it stops being a chat you steer message by message and starts being something you could actually hand a job to. That something is an agent. This chapter is about what an agent really is, what it is not, and the one decision you will make every time you use one.
Let me start by clearing away the hype, because the word "agent" has been used to sell a lot of things that do not exist yet.
What an agent actually is
An agent is a Claude instance with three things: a role, its own context, and a job it can run without you babysitting every step. That is it. A role, so it knows what it is for. Its own context, so it is focused and does not carry the clutter of everything else you do. And a job it can carry from start to finish, so you hand over the whole thing and get back a result, instead of steering each move.
The plainest way to feel the difference. A chat is a conversation where you drive every turn. An agent is a teammate you give a job description and a task, who then goes and does the task and brings it back. You are not typing the next step. You gave it the job and it ran the job.
Now, just as important, what an agent is not. It is not magic. It is not autonomous in the science-fiction sense, off doing whatever it decides. It is not a replacement for your judgment, and it is only ever as good as the context and skills you gave it. An agent with no context and no skills is just a chat with a fancier name. Everything you built in the last two chapters is what makes an agent worth having. The agent is the container. Your context and skills are what is inside it, and empty containers do empty work.
The decision you make every time: main session or subagent
Here is the practical fork you will stand at constantly. You have a piece of work. Do you do it right here, in your main working session, or do you hand it off to a subagent, a separate agent with its own focused context, to go run on its own?
The answer comes down to size and independence. If it is quick, exploratory, part of the back-and-forth you are already in, keep it in the main session. Thinking, iterating, short tasks, the stuff where you want to stay in the loop turn by turn, that stays with you. But if it is a big, self-contained job, something with a clear brief and a clear finish that does not need you hovering, that is a subagent. Give it the brief, let it run in its own context, get back the result. The gain is not only that it runs on its own. It is that a subagent gets its own clean context, so it stays sharp and focused on its one job instead of dragging along everything else you have been doing.
You will get a feel for this fast. Big and independent goes to a subagent. Small and iterative stays with you. When in doubt, ask whether you would want to review each step or just review the result. Review each step, keep it close. Review the result, hand it off.
When a human belongs at the handoff, and when they do not
Once you have a few agents, the question becomes how they work together, and there is a lot of confusion here, so let me be straight about what is actually possible before I tell you what I recommend.
Both of these patterns are real and both work. The first is parallel agents on independent tasks. You set several agents going at once, each on its own separate piece of work, and they run side by side. Nothing needs to pass between them because their tasks do not depend on each other. The second is directly wired agent chains, where agents know about each other and hand work straight from one to the next, or even message each other, without a human in the middle. Agent teams that coordinate among themselves are a real, increasingly common pattern. Neither of these is a mistake or a hack. They are both normal ways to run agents in 2026.
So my rule is not "agents cannot talk to each other." They can. My rule is narrower and it is a deliberate quality choice for one specific kind of work: sequential, dependent work where one agent's output becomes the next agent's input and where judgment matters at each step. That is the case where I keep myself at the handoff, and here is exactly why.
Example: my role-scoped team, with handoffs through me on the dependent work [from my own system]. I run work across quite different modes: discovery and research, design and strategy, building, and go-to-market. No single generalist assistant does all of those well, because each one wants a different context and a different way of thinking. So I do not use one assistant that tries to be all of them. I use a small team of role-scoped agents, each with its own job. A planner that proposes the route and writes the briefs but does not do the work itself. A designer who owns the whole path from discovery research and strategy through to the designed solution, the concepts, the PRDs, the customer journeys, the design system, deliberately one role carrying it from research to validated concept to design instead of splitting research off from design, which is the service design way I have always worked. A builder that owns architecture, code, tests, and deploy. A marketer that owns launch, go-to-market, and outreach. A content specialist that owns multi-channel editorial content. Each one is sharp precisely because its context is narrow. The designer is not distracted by go-to-market. The builder is not trying to also be a strategist.
Now watch the distinction. When these agents are doing independent work, I let them run in parallel and I review the results at the end. That is genuinely how I work most days, several Claude Code sessions open side by side, each advancing a different piece, exactly like the workshop with several benches going that I described back in chapter two. No human is needed between agents that are not depending on each other. You just need to review what came out.
But my content and product pipeline is not independent work. It is a chain. Research feeds design, design feeds build, and each step takes the previous step's output as its starting point. On a chain like that, an unreviewed handoff is dangerous, and not because the agents are incapable. It is because a mistake made early gets swept downstream, each agent building confidently on top of the last one's error, and by the time you notice, the mistake is three steps deep and expensive to unwind. So on the dependent chain, the work passes back through me. When the designer finishes, the result comes to me and I decide what goes forward. When the builder finishes, same thing. I am the handoff point on purpose, on the sequential work, because that is where a small early error turns into a large late one. I am describing the shape of this, not handing you the setup, because the shape is what you need. The setup itself is in the free starter download at the end of the next chapter, ready to fill in with your own roles.
Example: the prospect-research agent. Here is a smaller version you could use tomorrow. You have a sales call coming and you want a competitor or a prospect properly researched first. The naive way is a scattered chat where you ask for one thing, read it, ask for the next, steering every step, doing the thinking yourself and using the AI as a search box. The built way is a research agent with a defined job: research this prospect, along these lines, and bring me back a structured summary. You give it the brief and it runs the whole thing. What changed is that you stopped micromanaging the steps and started reviewing the result. That is the first real taste of handing over a job instead of a message, and once you feel it, the way you work starts to shift.
So here is the honest advice, scoped properly. On dependent chains, keep a human at the handoff while you are still learning. Not because wiring agents together is impossible, it plainly is not, but because you should learn what good output looks like at each step before you take yourself out of the chain. You cannot judge whether a handoff is safe to automate until you have watched enough of them to know a good one from a bad one. Sit in the seat first. Then, once you can recognize good output at a step, you can start building checks that do the recognizing for you, and step out.
That last sentence is the whole next horizon, so let me point at it. The further you go with agents, the more the real question stops being "can they hand off to each other," which they can, and becomes "where does the human still need to stand." The answer keeps moving as you build checks that can replace your eyes at more and more handoffs. That is loop engineering, and it is exactly what the bonus chapter opens up.
The bridge to a whole system
You now have all the parts. Surfaces, so the work sits where it can be seen. Context, so the AI knows your world. Skills, so it knows your methods. Agents, so you can hand over whole jobs. The next chapter puts them together into something that runs, and I am going to show you a real one doing exactly that.