Wire a few AI agents together and every hand-off ends up in a transcript. People read that transcript the way they read an access log: the message is in there, so it must have done something. But a 200 status code only says the request was handled. It doesn't say whether the handler did the right thing with it. If Agent A tells Agent B the meeting moved to Room 4, the log proves B got the sentence. It doesn't prove B would have acted any differently if A had said Room 9, or said nothing at all.
You find out the same way you debug any system you can't understand by reading the code. Change one input, hold everything else still, and watch whether the output moves.
Poke one message
Zhao et al. built exactly that test in Are Agents Listening to Each Other?. They ran it across four agent-team designs, two models and two simulated environments, and their code is public. The procedure goes like this:
- Freeze a decision. Snapshot the receiving agent right before it acts, along with the messages it just received.
- Measure the noise. Model outputs vary from run to run, so from that frozen moment you sample the agent's next action repeatedly under different random seeds. How far the answers wander when nothing has changed is your noise floor.
- Change one fact in one message. Room 4 becomes Room 9. Keep the kind of statement, the recipient, the stated certainty and any time reference identical, and leave every other message alone.
- Resample and compare. If the answers shift past the noise floor (the study's original bar was average noise plus 1.5 standard deviations), that message drove the decision. If no message clears the bar, the decision had no driver. As far as that edit could tell, the agent's next move didn't depend on anything it was told.
Where you set the bar decides the answer
The study ran 793 tests on 426 frozen decisions, since many decisions got more than one kind of edit. Under the original bar, which judged each message on its own, 38.7% of tests found no driver. Under a revised bar, 75.3% found none.
The revised bar accounts for how many messages arrived together, and it's calibrated on held-out "identity" runs, where a message goes through the swap machinery and comes out unchanged. My read on why that matters: when five messages arrive together, noise gets five chances to clear the bar by luck, so the bar ought to rise with the count. And resampling an untouched moment probably understates the wobble the editing step adds on its own. The published summary doesn't give the exact cutoff, and the authors don't claim either number is the true rate.
Same agents, same data, and the headline swings from under two in five to three in four. The authors take that as evidence of how sensitive the result is to calibration, and they're right. Pick your bar before you look at results, tune it on your own identity runs, and publish it next to the number. Otherwise you're grading your own exam with the answer key open.
What earns a place in shared memory
Messages go by. Shared memory sticks around, at least for the rest of the task. A note one agent writes shapes every agent that reads it afterward, and, as an earlier Foundations piece argued, nobody downstream can tell whose judgment it carries.
In Learning to Share, Fioresi et al. ran three agent teams in parallel and put a trained gatekeeper in charge of deciding, step by step, what went into their shared memory. The gatekeeper was rewarded for task success and for saved notes that got used in successful runs, and penalized for saving too often. On GPT-5.1, across two benchmarks of multi-step assistant tasks (higher is better):
| Approach | AssistantBench | GAIA |
|---|---|---|
| Gatekeeper decides | 26.7 | 49.1 |
| Share nothing | 24.0 | 47.9 |
| Save everything | 23.0 | 44.2 |
Saving everything scored below sharing nothing. Anyone who has tried to debug from a log where nothing was filtered out will recognize the problem. Keep the full transcript for the humans doing the postmortem, and be strict about what goes into shared memory.
The perturbation test and the gatekeeper's reward cover each other's blind spots. A saved note is just a step's output that later agents will read, so you can perturb it like any other message: swap one fact, watch the reader's next action. That evidence is causal but local. Zhao and colleagues call their measure "prompt-level next-action sensitivity," and it can't see past the next step. The gatekeeper sees the longer horizon, but only as correlation: the note got used, and the run succeeded.
Neither paper puts the two together. If I were deciding what gets into shared memory, the perturbation score would be a flag rather than a verdict. A note the gatekeeper loves that moves nothing when you edit it deserves some suspicion. A note that scores zero might matter three steps later, so it gets a second look before anybody turns it away.
-
The missing calibration cutoff: The exact numerical rule behind the 75.3% figure may sit in the authors' Revision 3 review archive, which hasn't been inspected yet and is worth checking before anyone copies the bar.
-
Runtime numbers that disagree: The Learning to Share speedups need a careful reread, because the authors' accompanying poster prints a GAIA runtime of 781 seconds while the paper's admission table says 792, and its percentage savings don't reconcile with the raw times.
-
Perturbation as a reliability metric: Rabanser and colleagues' Towards a Science of AI Agent Reliability treats robustness to perturbations as one of four reliability dimensions, and finds that capability gains buy surprisingly little of it.
-
Poisoned notes, delayed effects: For what happens when the wrong thing gets past the memory door, Visual Inception shows poisoned uploads steering an agent when they're retrieved during later planning, hitting their goal about 85% of the time in a mock commerce setup before the authors' defense cut that to around 10%.

