BRIDGE: Selectively Repairing Handoffs Between Agents Instead of "Fixing Everything"

OFFLINE (HandoffProbe, once per model):
  take past runs → break a handoff → run two continuations:
  "as is" and "with repair" → compare outcomes with tests
  → get a table: which repair helps / hurts / does nothing for which failure

ONLINE (BRIDGE, at every handoff):
STEP 1: Build a graph: messages, tool outputs, contract obligations
STEP 2: Find "gaps" (frontiers) → 3 types:
        • delivered but not used
        • fact never appeared at all
        • fact went to the wrong recipient
STEP 3: Take the earliest gap, collect admissible repairs (ASK / INTEGRATE / VERIFY / DECOMPOSE / RETRIEVE)
STEP 4: Gate: benefit − risk − cost > 0, harm risk below threshold, enough data?
        no → forward the message as is
STEP 5: Snapshot the state, apply the repair
STEP 6: Check: gap closed, existing links intact?
        yes → send the fixed version; no → roll back, send the original

Steps 1–4 and 6 are handled by a code controller, no LLM required. An LLM call is needed only for the ASK repair ("ask the sender").

Task: You're automating sales proposal prep. The chain has three agents: "Requirements Collector" (reads the client's email from HubSpot) → "Proposal Copywriter" → "Reviewer". The client's email contains hard facts: budget up to $45,000, deadline June 15, prices must include sales tax, never mention the competitor "Acme". Time after time, one of these facts gets lost at the seam. And when you added "have the copywriter double-check everything just in case," things got worse: it started rewriting paragraphs that were already correct.

Prompt (system instruction for a controller agent that inspects every handoff):

<Role>
You are the handoff controller in a chain of agents. You do not write the proposal.
You check whether the required facts reached the next agent,
and you intervene only when it is truly necessary.
</Role>

<Contract>
Required facts (id | essence | produced by | needed by):
F1 | Budget no more than $45,000 | Requirements Collector | Copywriter
F2 | Deadline June 15 | Requirements Collector | Copywriter
F3 | Prices must include sales tax | Requirements Collector | Copywriter
F4 | Never mention the competitor "Acme" | Requirements Collector | Copywriter, Reviewer
</Contract>

<Frontiers>
For each fact, determine its status from the conversation history:
- OK: the fact was delivered to the recipient and reflected in their work
- UNCONSUMED: the fact was delivered, but the recipient did not use it
- ABSENT: the fact never appeared anywhere
- MISROUTED: the fact went to someone who doesn't need it
If there are several gaps at once, work on the earliest one in the chain.
</Frontiers>

<Repairs>
Choose the repair strictly by gap type:
- UNCONSUMED → INTEGRATE: insert the fact into the outgoing message to the recipient
- ABSENT → ASK: ask the sender one precise question about this fact
- MISROUTED → INTEGRATE: forward the fact to the right recipient
Forbidden: ASK about a fact that has already been delivered (it distracts the recipient).
Forbidden: INTEGRATE for a fact that never appeared in the conversation.
</Repairs>

<Gate>
Intervene only if all of the following hold:
1. The missing fact is on the required list.
2. Losing it changes the outcome (budget, deadline, prohibition: yes; tone and minor wording: no).
3. A suitable repair from <Repairs> exists.
Otherwise, return status FORWARD and pass the message on unchanged.
</Gate>

<Verify>
After the repair, re-check: is the fact now in the message to the recipient?
Are the other facts still in place? Was nothing extra rewritten?
If "yes": status COMMIT and the fixed message.
If "no" or you're unsure: status ROLLBACK and the original message.
</Verify>

<Output>
Fact table: id | status | decision.
Then: FORWARD / COMMIT / ROLLBACK and the final message for the next agent.
</Output>

Result: The model returns a table of the four facts with a status and a decision for each. Then comes one of three verdicts: forward as is, fix and send, or roll back to the original. If only a minor nuance went missing, it should forward without edits. If the deadline or budget got lost, it inserts the fact into the message to the copywriter and re-checks the whole list.

The LLM weakness. An agent that receives an incomplete handoff still produces a plausible answer. From the outside you can't see what got lost. Trying to "improve everything" ("double-check," "re-verify," "polish it up") backfires too. The model doesn't know what was the gap and what was normal, so it damages the parts that worked.

The LLM strength. Checking a message against a predefined list of facts is something models do well: it's a simple cross-check. In the study, a single pass over the dependency graph delivered diagnostics on par with multi-step chains, at 32–42% lower cost.

How the method exploits this. It turns a vague "something went wrong" into a concrete typed gap. The type determines which repair is allowed. The gate filters out unnecessary interventions, and verification with rollback keeps a repair from breaking what already works.

Control levers: - Required-facts list (the contract) → shorter list, less noise. Include only what breaks the result if it's missing. - The "Gate" condition → stricter condition, fewer interventions and lower cost. Looser condition, more repairs and a higher risk of doing harm. - The "gap type → repair" table → grow it from your own logs: which repairs actually helped you. - The ROLLBACK verdict → when in doubt, send the original. It's your insurance against a cure worse than the disease.

<Role>
You are the handoff controller between agents working on this task: {task}.
You do not do the work yourself. You check whether the required facts reached
the right agent, and you intervene only when necessary.
</Role>

<Contract>
Required facts (id | essence | produced by | needed by):
{fact_list}
</Contract>

<Frontiers>
For each fact, determine its status from the conversation history:
- OK: delivered to the recipient and reflected in their work
- UNCONSUMED: delivered but not used
- ABSENT: never appeared anywhere
- MISROUTED: went to someone who doesn't need it
If there are several gaps, work on the earliest one in the chain.
</Frontiers>

<Repairs>
Choose the repair strictly by gap type:
- UNCONSUMED → INTEGRATE: insert the fact into the outgoing message
- ABSENT → ASK: ask the sender one precise question
- MISROUTED → INTEGRATE: forward the fact to the right recipient
- {other_rules}
Forbidden: ASK about a fact that has already been delivered.
Forbidden: INTEGRATE for a fact that never appeared in the conversation.
</Repairs>

<Gate>
Intervene only if the missing fact is required,
losing it changes the outcome, and a suitable repair exists.
Otherwise return FORWARD and pass the message on unchanged.
</Gate>

<Verify>
After the repair, check: the target fact is in place, the other facts are untouched.
Yes → COMMIT and the fixed message.
No or in doubt → ROLLBACK and the original message.
</Verify>

<Output>
Table: id | status | decision. Then FORWARD / COMMIT / ROLLBACK
and the final message for the next agent.
</Output>

<Handoff>
{message_from_previous_agent}
</Handoff>

<History>
{conversation_history}
</History>

What to fill in: {task}: what the chain does. {fact_list}: 3–8 required items, each with an owner and a recipient. {other_rules}: your own "gap type → repair" pairs, if experience has turned some up. {message_from_previous_agent} and {conversation_history}: what the controller inspects at this handoff.

🚀 Quick start: paste this into the chat:

Here's a template for a handoff controller between agents (BRIDGE). Adapt it to my task: [describe your agent chain and what they pass to each other].
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask which agents are in the chain, what they pass and to whom, and which facts must never get lost. That's how it builds the "contract": without an explicit list of required facts, there's no way to tell a real gap from a harmless omission. It will take the rest from the template.

⚠️ The full method needs code: the dependency graph, statistics-based gating, state snapshots and rollback are run by a controller program, not a prompt. A prompt can reproduce the idea and the diagnostics, not the system itself.

⚠️ A prompt-based gate is weaker than a statistics-based one: in the study, letting "the LLM itself decide whether to intervene" delivered noticeably less benefit than deciding from accumulated offline-run statistics. The prompt version of the gate is an approximation.

⚠️ The statistics are model-specific: the "what helps" table transferred across different tasks but did not transfer across different models. Switch models, recalibrate.

⚠️ Needs visible traces: the method relies on the failure showing up in the messages and logs. If the breakdown happens entirely inside one agent's "black box," it's powerless.

⚠️ Small samples: some of the per-component conclusions rest on a small number of runs, and significance there is borderline. The direction is convincing; the exact numbers are fragile.

The idea was simple: stop guessing whether an intervention helps and measure it with replays. First the team took logs of past multi-agent runs and deliberately broke handoffs in them: a fact got dropped, a recipient ignored the data, a message went to the wrong place. From each break point they launched two continuations. One proceeded as is, the other with a repair. Outcomes were scored by tests, not an LLM judge. The result was a table: repair X for failure Y helps, hurts, or changes nothing.

Then the method was tested on two benchmarks with two models. Baselines were Self-Refine, AgentAsk, MOC and VeriMAP. On SILO-BENCH, success rose from 63.3% to 75.6% with one model and from 68.9% to 77.8% with the other. On TeamBench the gain was up to 11.1 points. The table built on synthetic data was applied to TeamBench with no tuning, and it worked. Extra tokens: 2% to 5%. Diagnostics were separately checked on 562 real MAST traces. There the method reached about 70% F1 in a single call instead of two-step chains.

The most practically useful data is in the ablations. Intervening every time drops success to 56.7%, which is 6.6 points below no help at all. Removing rollback costs just as much. Replacing the graph with a flat checklist gives 68.9%. Replacing the statistics with the model's self-assessment gives 70.0%. The paper also shows that matching the repair to the gap type is critical. Inserting missing context fixed about half of the "delivered but not used" cases but did nothing for "the fact is missing entirely." An unnecessary question about something already delivered did harm. The surprise: it's not only weak interventions that break things. Any imprecise "treatment" breaks things too.

🔧 Technique: intervention rules in the agent's instructions file → less "busywork."

This is not the method from the paper; it's a transfer of its findings into AGENTS.md / CLAUDE.md. The effect of this phrasing wasn't measured in the paper, so test it on your own tasks.

## Rules for handing off work between agents
- At the start of the task, write a list of required facts: what it is, who produces it, who needs it.
- At every handoff, check the message against the list. Don't "improve" the message if the required facts are in place.
- A fact is missing that never appeared in the conversation → ask its owner one precise question.
- A fact was delivered but not used → insert it into the message to the recipient. Don't re-ask.
- Never re-ask for something that has already been passed along.
- After an edit, check: the needed fact appeared, the others didn't change. Not sure? Send the original message.

• Paper: BRIDGE: Selective Boundary Repair with Dependency Graph Evidence in Multi-Agent Systems
• Authors: Encheng Su, Pengze Li, Ziheng Hua et al. University of Science and Technology of China (USTC), Fudan University, Shanghai Artificial Intelligence Laboratory, and others.
• Benchmarks: SILO-BENCH, TeamBench, MAST (a taxonomy of multi-agent system failures, Cemri et al., 2025).
• Compared against: AgentAsk, Self-Refine, MOC, VeriMAP.