Opening

The marketing team has an agent that turns a brief into a published post. It researches the topic, writes the draft, reviews it against the brand guide, and publishes it to the blog. All in the same loop, with the same context, and the same tools.

Here's how it was configured, more or less word for word. You are the content agent. Research, write, review rigorously, and publish only when it's excellent.

And the tools. Web search, fetch a page, read the brand guide, write and edit the draft, check plagiarism. And also publish the post, post to social media, update the CRM, and send the newsletter.

One Friday, the agent published a draft with a competitor's figures, copied from a page it read during research. The review step was in the prompt. But it was the same model, with the same context full of web pages, reviewing its own text, with the publish tool within reach the whole time. In this lesson, you'll learn to see this smell, and where to make the cut.

The diagnosis

Here's the shape. The whole task goes to one agent.

It holds every tool, and a prompt that tries to describe every role.

Untrusted content from the research enters the same context that will decide whether to publish.

Whoever reviews is whoever wrote, looking at the same material.

And the side effect tool is available from the very first step.

How do you spot it? One agent handles steps of different kinds. Research, production, review, and execution, all mixed together.

Every tool, read and side effect alike, is available at every step.

The system prompt describes several roles. You are researcher, writer, and reviewer.

Review happens in the same context that produced the work. And by the end of the task, that context still carries all the raw material from the start.

And a problem in one step forces changes to the prompt for all of them.

Why it happens

It starts small. The agent only wrote drafts. Publishing was just one more tool.

One agent looks simpler. One prompt, one loop, one deploy. Splitting looks like needless complexity.

Good models cope in the demo. On short tasks, the single agent works fine. The problem only shows up at scale, or in odd cases.

And nobody draws the boundaries. Without someone asking which steps really exist, they blend together.

What it costs

The first cost is quality. Review in the same context tends to agree with what was produced. The model rereads its own reasoning, not the result with fresh eyes.

Then security. Untrusted content read during research sits in the same context as the side effect tools. That's the recipe for an attack where instructions hide inside the pages an agent reads. A mega agent that researches and publishes in the same context is the classic target.

Then context. The end of the task carries the clutter of the start. That's context rot.

And maintenance. Changing how review works means editing the prompt that also researches and writes. And each change affects everything.

Picture the same pattern in an online store. An agent that answers delivery questions, looks up the order, and issues refunds. A simple where is my package still has the refund tool on the list. Text in a product description, or a creative user, pushes the model toward the side effect.

A challenge

Here's one for you. The content agent researches, writes and publishes. You can make one change this week. Which cut reduces the most risk?

Take the publish tool out of the model's loop, and publish in a code step, with approval. A side effect tool available during research is the risk that already broke on Friday. Isolating the effect is the smallest cut. Research and writing can wait for the next slice.

Adding a second role whose only job is to review rigorously, in the same context with the same tools, isolates nothing. The reviewer still sees the pages, and can still publish. And telling the agent to forget the pages after the draft doesn't remove a single token, or a single tool.

The treatment

There are two refactorings. Extract subagent, when there are steps with their own tools and context, like research and review. Each becomes a subagent that returns only its result. And introduce a router, when the agent handles different kinds of requests, each needing different tools. Often, the final step, publish, pay or send, doesn't even need a model. It becomes code, behind approval.

Here's the smallest cut that already reduces harm. Research reads the web in an isolated context, and returns cited facts. Not raw pages.

Writing gets the brief plus those facts, without the pages.

Review gets the draft plus the brand guide, without the writer's reasoning.

And publishing is code, with a person in the loop, if the channel is public.

But don't overcorrect. The opposite is a smell too. A pipeline of five agents with job titles. A researcher, an analyst, a writer, a reviewer, and an editor. Each takes the previous one's text, and returns nearly the same text. It costs five times as much, with no real split of tools or context. That smell has a name of its own, decorative multi-agent. Split where the nature of the work changes, not where the org chart wants a job title.

Is it this smell?

Three cases to sharpen the eye. A support agent answers questions, looks up orders, and issues refunds, with one prompt and one set of tools. Refunds above a hundred dollars go to a person. Is it a mega agent? Yes. The approval covers big amounts, but the question answering path still has the refund tool within reach. A router would separate the paths.

A research agent reads sixty pages and writes a report. No side effects at all. But the report sometimes ignores sources read early on. That's a milder version, mixed with context rot. Split the reading into subagents that return cited summaries.

And an engineer using a terminal assistant to edit a repository, approving every change it proposes. Read and write tools in one agent, under continuous supervision. That's fine. The smell hurts when the same loop reads the web, and fires a side effect, with nobody watching.

Wrap-up

So here's the idea to take with you. When one agent researches, writes, reviews and acts, every step inherits every risk. Separate the reading from the acting, give review fresh eyes, and turn the final side effect into code with approval. That's usually the cut that matters most.

In the next lesson, we'll make the main cut step by step: extract subagent. See you there.