The One Sentence That Explains Every Multi-Agent Failure I've Seen

A child agent knows only what the parent writes into its prompt.

That's the sentence. Everything else in this article is just me convincing you to take it as seriously as it deserves.

The bug that taught me

Picture a parent agent doing competitive research. It searches the web and finds something important: the competitor just raised fifty million dollars. Great finding. Then it spawns a child agent to write the analysis, with a prompt that says roughly "write a competitive analysis of Company X."

The fifty million never makes it into the child's prompt.

Now, what do you expect happens? When I first started with this stuff I expected one of three things. Maybe the child inherits the parent's context and sees the finding anyway. Maybe it notices something is missing and asks. Maybe it goes and re-searches the web on its own.

None of those happen. The child writes a confident, well-structured, professional analysis with a fifty million dollar hole in it. No error. No warning. Nothing flagged.

Children do not know what they don't know. That's the property you have to design around.

Why it works this way on purpose

My first reaction was that this seemed like a flaw. Why not share memory between parent and child?

Then I built more systems and understood. Isolation is the feature.

A child with a clean context reviews work with genuinely fresh eyes. If you want one agent to critique another's writing, the critic being unable to see the writer's reasoning is exactly what makes the critique honest. Shared memory would make it an agent grading its own homework.

A child with a clean context also can't be polluted. Whatever mess the parent accumulated, whatever half-finished reasoning or irrelevant tool output, none of it leaks into the child's thinking.

And a child with a clean context is predictable. Its behavior depends on its brief and nothing else. You can test it like a function, because it basically is one.

Recommended by LinkedIn

The brief is the interface

Once you accept the isolation rule, the design question becomes: what goes in the brief?

I now write subagent briefs the way I write function signatures, and I hold them to one standard. A stranger with zero context about my project should be able to execute the brief. If they'd have to ask me a question first, the brief is incomplete.

Concretely, every brief gets four sections:

The goal. One or two sentences on what done looks like.

The facts. Everything relevant the parent knows, written out explicitly. This is where the fifty million goes. Nothing is too obvious to include, because obvious to the parent means invisible to the child.

The constraints. What not to do, what to leave alone, where the edges are.

The output format. If I need JSON back, I say so and I show the shape. A child returns a string, and if I want to parse that string, the brief is where I earn it.

The test I use before every spawn

Before spawning any child, I reread the brief and ask one question: if I handed this to a smart contractor who has never seen our codebase, our data, or our conversation, could they deliver?

It takes thirty seconds and it has caught more bugs than any other habit I've built this year. Because here's the uncomfortable part: a missing fact in a brief doesn't fail loudly. It fails silently and confidently, inside output that looks great.

The next article in this series covers money, specifically why the multi-agent version of a pipeline can cost less than the single-agent version, which surprised me the first time I ran the numbers.