Multi-Agent Context Passing: The Lossy Compression Problem Every Interviewer Asks About

The core challenge of multi-agent systems is context passing, not single-agent capability.
The article addresses context passing in multi-agent systems, a high-frequency interview question. Berkeley found nearly 40% of failures come from misaligned information between agents, not weak single agents. It covers four strategies by token cost—full passing, structured brief, shared blackboard, and message passing with stateless sub-agents—distills the four-word principle externalize/curate/compress/isolate, offers a seven-field summary checklist, and lists three anti-patterns.
Multi-agent systems are becoming a hot topic in LLM applications, but many developers stumble on context-passing questions in interviews. In his systematic course on Bilibili, creator Peng Yu specifically breaks down this high-frequency hard question: how do multiple agents pass context between each other? This article walks you through the engineering logic behind it.
Why Multi-Agent Context Passing Is the Core Challenge
In a multi-agent system, each agent has its own context window. When a task needs to flow between multiple agents, how context gets passed becomes the key issue. Peng Yu points out that many people's first instinct is to dump the entire history onto the next agent—but that's exactly where the problem begins.

UC Berkeley analyzed over 1,600 real execution traces and found that nearly 40% of failures were not due to insufficient capability of a single agent, but to misaligned information between agents—information lost during handoff, or parties continuing execution on contradictory assumptions. This data shows that whether a single agent is easy to build is a secondary concern; how context flows between them is the primary problem.
Context Window is the maximum number of tokens an LLM can process in a single inference, including the input prompt and generated content. It determines how much information an agent can "see" at once, and directly constrains the upper limit of information that can be passed during multi-agent handoffs. Window sizes vary greatly across models (from a few thousand to over a million tokens), but even with a large enough window, stuffing in the full history brings cost, latency, and "lost-in-the-middle" problems. Therefore, the context window is not a free warehouse but a scarce resource that must be carefully budgeted—this is the fundamental reason multi-agent context passing must be engineered.
Four Main Passing Strategies: From Full to Isolated
Peng Yu sorts out four mainstream approaches by token cost from high to low, each with its applicable scenarios and trade-offs.

Full passing: Move the entire history over as-is. High cost, and it inflates with every hop, but with minimal information loss. Suitable for short chains within two hops where accuracy requirements are extremely high.
Structured brief: Don't pass history; pass a summary object with well-defined fields. Cost is constant, and it forces the sender to think clearly about what actually matters. This is the default choice for the vast majority of production systems.
Shared blackboard state: Put state in a public space outside the conversation; whoever needs it reads it. The cost is that it becomes a global variable shared by a stochastic process—one agent writes something wrong, another reads it as truth, and the error gets laundered. If you really use it, it must be append-only, signed, and clearly specify who wrote it, based on what, and with what confidence—making it like an audit log rather than a rumor wall.
Message passing with stateless sub-agents: Give the other party only the fields it needs—not one more. A Microsoft team compared approaches on the A2A protocol and ultimately chose this: domain agents are fully stateless, and the coordinator embeds compressed history directly into the message it sends. The benefit is that "who can see what" becomes a governable, controllable problem.
A2A Protocol (Agent-to-Agent Protocol) is a class of communication specifications for multi-agent collaboration, designed to let agents built on different frameworks and by different vendors discover each other, negotiate, and exchange task information. It typically defines message formats, capability descriptions (Agent Card), task lifecycle, and other elements, so that handoffs between agents no longer rely on hardcoding. The Microsoft team's comparative experiment on A2A essentially evaluated: on top of a standard protocol, whether choosing "passing the full conversation history" or "passing compressed structured messages" affects system reliability and cost. Understanding A2A helps elevate the context-passing problem from "single-machine internal implementation" to "cross-agent interoperability."
The Four-Word Principle: Externalize, Curate, Compress, Isolate
With the mechanisms covered, what the interviewer really wants to hear is the design philosophy behind them. Peng Yu distills it into four words: externalize, curate, compress, isolate.
Externalize: Don't stuff large objects into the prompt; write them to a file and keep only a reference.
Curate: Don't expect to prepare all materials at once; fetch them when needed.
Compress: Always summarize at boundaries. In Anthropic's research system, a sub-agent explores tens of thousands of tokens, but gives the main agent only a condensed conclusion of 1,000 to 2,000 tokens.
Isolate: Give each sub-agent a clean window containing only its own piece of work. Peng Yu likens it to a "context firewall"—it absorbs the dirty, heavy work and hands back only the distilled answer, keeping the main window clean.

Sub-agent is an agent instance spawned by a main agent (also called a coordinator or orchestrator) to perform a specific subtask. It typically has an independent context window, receives only inputs relevant to the subtask, and returns results to the main agent when done. The value of sub-agents lies in decomposing complex tasks into units that can be processed in parallel or in isolation, while using a "clean window" to prevent the main context from being polluted by intermediate processes. In Anthropic's multi-agent research system, a sub-agent exploring tens of thousands of tokens returns only a 1,000-2,000 token conclusion—a typical use of sub-agents as a "context firewall."
What a Summary Should Contain: A Seven-Field Checklist
A summary isn't something you just scribble down. Peng Yu provides a directly usable field checklist: task (rewritten in the sender's own understanding), discovered constraints (e.g., "this code must not be touched"), locked-in decisions (with reasons), paths tried but failed, conclusions (each tagged with a source label: tool-verified, model-inferred, or inherited from upstream), confidence and completion level, and pointers to the original context.
Among these, "paths tried but failed" has an especially high cost-benefit ratio—without it, downstream will definitely walk the dead ends again. And "pointers to the original context" reminds us: a summary is a cache, not a replacement; when it's insufficient, you can always trace back.
There's an easy pitfall when writing summaries: the perspective should be "what the next agent needs," not "what I just did." What you write from these two perspectives is completely different.
Three Anti-Patterns and a One-Sentence Summary
Peng Yu also summarizes three anti-patterns that will earn you bonus points if you mention them in an interview: mindlessly forwarding the complete history while dressing it up as "no information loss"; using a prose paragraph as a handoff with no schema, so important things quietly disappear; and forcibly splitting a linear process into multiple agents—that's not multi-agent, that's function calling.
If you can only remember one sentence: the difficulty of multi-agent systems has never been about building a single agent, but about designing how context flows between them. Every handoff is a lossy compression. Treat it as a first-class citizen and engineer the boundaries—that is the system itself.

For developers preparing for LLM job interviews, this question is worth chewing over repeatedly. It tests not memorized concepts, but a genuine understanding of system boundaries and engineering trade-offs.
One-line Summary
The core challenge of multi-agent systems is context passing, not the capability of a single agent.
Paragraph Summary
The article centers on context passing in multi-agent systems, a high-frequency interview question. Berkeley's analysis of over 1,600 real traces found that nearly 40% of failures stem from misaligned information between agents rather than insufficient single-agent capability. The article sorts four strategies by token cost from high to low: full passing, structured brief, shared blackboard, and message passing with stateless sub-agents, noting that structured brief is the default for most production systems. It then distills the four-word principle "externalize, curate, compress, isolate," provides a seven-field checklist for summaries, and emphasizes writing from the perspective of "what the next agent needs." Finally, it summarizes three anti-patterns: mindlessly forwarding full history, prose-style handoffs without a schema, and forcibly splitting linear processes into multiple agents.
Related articles

How Did Da Vinci Prove the Sun Is Hot? A Neglected Chapter in Science History
How did da Vinci use a concave mirror experiment to overturn Aristotle's cold sun theory? This article traces this neglected chapter in science history, revealing the embryo of scientific thinking in the 15th century and da Vinci's cold observations on solar heat and the nature of life.

SharpLogic: Formalizing Bug Detection for LangGraph Routing Graphs with k-CNF
SharpLogic, an open-source project, maps LangGraph-style multi-agent routing and retry graphs to k-CNF, using a Rust kernel to count deadlocks and failing paths (#F counting), offering a Python AgentGuard hook and CLI for pre-release formal gate checks. This article analyzes its principles, its complementary relationship with evals, and the community's concern about modeling costs.

PPO Training of a Franka Robotic Arm for Pick-and-Place: A Reinforcement Learning Starter Project
A reinforcement learning project using PPO to train a Franka Panda robotic arm for pick-and-place in PyBullet, covering tech stack choices, task design challenges, and future text/voice command interaction plans—a good reference for beginners.