Walk through how shared message history causes quiet context bloat in a multi-agent run

Short answer·Hard·4.0 · 0·~3 min·Asked atApple Roblox Snorkel Ai

Attempt it

A 5 agent crew shows steadily climbing per turn cost as the workflow progresses, with no growth in problem complexity. Walk through how shared message history quietly bloats per agent context and three concrete techniques to bound it.

Free · 2 AI evals / day

The default coordination pattern in a chat-based multi-agent crew is **shared message history**: every agent reads the entire conversation log before deciding what to do next, and every agent's output is appended to that log. The bloat is mechanical. On turn one, the log holds the original task. On turn two, it holds the task plus turn one. On turn twelve, it holds the task plus all eleven prior turns. Every agent on every turn pays to read all of it. If each agent contributes a paragraph or two per turn, the log lands in the tens of thousands of tokens within a dozen turns, and the supervisor (which speaks most often) pays the most because it re-reads the entire history every routing decision. Three fixes bound it. **Summary-on-handoff** compresses prior turns into a short brief before passing control. **Per-agent context filtering** lets each agent see only its own past turns plus the current task, not the whole crew chat. **Structured handoffs** replace the chat-history payload with a typed object that contains only the fields the next agent actually needs. The first two cut what already exists; the third prevents the bloat from forming in the first place. Per-agent context-size telemetry on the dashboard catches the climb early.

**Shared message history** is the default coordination idiom in chat-based multi-agent frameworks, and it is also the default source of quiet context bloat. Each turn appends the speaker's full message to the shared log, and every subsequent agent reads that log as its conditioning context. Per-turn input tokens therefore grow roughly linearly with turn count, and the cost line on the dashboard climbs even though the underlying task complexity is flat. The supervisor's growth is steeper than the workers'. A supervisor in a hub and spoke topology speaks every other turn and reads everything; its per-turn cost is the area under the growing-log curve, not the slope. Three techniques bound the bloat at different layers. First, **summary on handoff**: a small summariser model (or a deterministic code path for structured fields) compresses the prior log into a brief whenever control transfers. The receiving agent sees the brief plus the latest task instead of the full history. Second, **per-agent context windows**: configure each agent to see only its own past turns plus the current task. AutoGen exposes this directly; LangGraph achieves it via state-key filtering on the node input. Third, **structured handoffs with typed payloads**: replace the free-form chat-history pass with a Pydantic or TypedDict object that carries only the specific fields the next agent needs. This is the architecture-level fix and it prevents the bloat from forming rather than trimming it after the fact. The operational glue is per-agent context-size telemetry. A panel that charts input tokens per turn per agent surfaces the climb before it shows up as a runaway invoice.

TL;DR

Shared chat-history coordination makes each agent re-read the growing log every turn, so per-turn cost climbs with turn count. Bound it with summary on handoff, per-agent context filtering, and structured payloads.

Memory aid

Easy to grasp

Picture five colleagues sharing one notebook. Every time someone speaks they write the whole thing into the notebook, and the next person has to read the entire notebook before deciding what to say. After ten exchanges, the notebook is long, and every new speaker spends most of their time re-reading old pages instead of doing new work. The reading time is the cost. Three fixes help. The team can pause and write a one-page summary, then keep going from the summary. Each colleague can be told to read only their own past notes, not everyone's. Or the team can stop using a free-form notebook entirely and instead pass index cards with only the specific facts the next person needs. The notebook is the shared history; index cards are structured payloads.

Key concepts

Multi-Agent Systems Context Engineering Observability and Tracing

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Context bloat in multi-agent crews is one of those failures that does not show up in any single trace yet shows up in the monthly invoice as a steadily rising line. The proximate cause is mechanical: shared message history is the default coordination idiom, and every agent on every turn reads the full growing log. The deeper cause is architectural: the chat-history metaphor hides the real coordination contract behind a familiar interface, and most teams do not notice the bloat until cost climbs past their tolerance.

This deep dive walks the mechanism end to end, separates worker growth from supervisor growth, and works through the three bounding techniques (summary on handoff, per-agent filtering, structured payloads) in order of how much architectural change each one requires. The closing section covers the observability discipline that makes the whole thing measurable.

The mechanism: linear growth, sometimes quadratic

The default chat-history coordination pattern works like this. The team starts with the task as turn zero. Agent A speaks; the framework appends A's full message to the log. Agent B speaks; the framework appends B's message. By turn N, the log contains turn zero plus the first N speakers' full outputs, and the agent about to speak reads all of it as its conditioning context.

If the per-turn output is roughly constant at K tokens, the log at turn N is roughly NK tokens. Each worker that speaks on turn N pays once for an NK input. Summed across N turns, the worker side's cumulative input cost is on the order of (N^2 * K) / 2, which is quadratic in the number of turns.

The supervisor in a hub and spoke topology pays even more. The supervisor speaks every other turn (after each worker), reading the full log each time to decide who speaks next. Its per-call input cost is also growing linearly with turn count, but its call frequency is higher than any individual worker, so its share of cumulative cost dominates.

The practical effect: a five-agent crew with 200-token average outputs running 30 turns burns roughly 30 times the input tokens of a single-shot call doing the same work. The cost climb on the dashboard looks alarming only after several runs have accumulated, which is why teams typically discover the problem on a budget alert rather than during development.

Fix 1: summary on handoff, the operations-layer cut

Fix 2: per-agent context filtering, the framework-layer cut

Fix 3: structured typed payloads, the architecture-layer fix

Observability is the glue

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

AutoGen 0.4's RoundRobinGroupChat and SelectorGroupChat both ship per-agent message-filtering options to scope each agent's input.
LangGraph state-key filtering on node inputs lets each node read only the slice of state it needs rather than the full StateGraph.

What an interviewer would ask next. Try answering before peeking at the approach.

QWhat is the failure mode of summary on handoff and how do you guard against it?

Summariser drift: small fidelity losses accumulate across many handoffs and the brief eventually diverges from ground truth. Guard with a fixed JSON schema on the brief, periodic re-grounding against the raw log on key turns, and unit tests that compare summariser output against held-out reference summaries.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Diagnosing rising per-turn cost as a model-size or rate-limit problem instead of as the shared-log growth pattern that any chat-history crew exhibits by default.

60 second bullets to scan on the way to the call.

Describe the mechanism of shared message history bloat across turns
Explain why supervisor cost grows steeper than worker cost in a hub and spoke topology

Primary sources. Browse if you want the original framing.