Agent Memory Errors Handbook: Cases 46–50

This installment is part of the Agent Memory Errors: 100 Cases Handbook series.

Case 46: Multi-Agent & Collaboration Memory Errors — Consensus Protocol Deadlock

Scenario

Three Agents form a committee to vote on approving a loan. The rule requires a 2/3 majority. Agent_A opposes based on credit history, Agent_B supports based on income proof, and Agent_C supports based on collateral. Agent_A demands re-evaluation of income proof, Agent_B demands re-evaluation of credit history, and Agent_C waits for the others.

Error Manifestation

The three Agents loop endlessly on “demand re-evaluation” with no termination condition. The loan application hangs for hours.

Solution

1. Set a maximum number of rounds; when consensus is not reached, escalate to human arbitration or apply a default decision
2. Introduce an arbitrator Agent with higher authority to break deadlocks
3. Use evidence-weighting: assign credibility weights to different evidence sources to reduce subjective disagreement

Principle

Multi-Agent consensus mechanisms can deadlock without a leader or timeout. Human committees face the same problem and need a chairperson or deadline to break ties.

Case 47: Multi-Agent & Collaboration Memory Errors — Subagent Result Aggregation Loss

Scenario

The main Agent decomposes a task into three subtasks for three sub-Agents. Sub-Agent_1 returns “Feasible, but risk X exists,” while sub-Agent_2 and sub-Agent_3 return “Feasible.” The main Agent uses majority voting and takes “feasible” as the final conclusion, ignoring risk X.

Error Manifestation

The main Agent reports “Feasible” without mentioning risk X. After the user executes the plan, risk X materializes, and the user questions why no warning was given.

Solution

1. Apply a risk-first rule in aggregation: any risk or objection raised by a sub-Agent must be explicitly presented
2. Use structured aggregation: require each sub-Agent to return conclusion, risks, and confidence; the main Agent merges all risk lists
3. For low-confidence or disputed sub-results, run a second review by an additional Agent focused on the controversy

Principle

Simple majority voting is dangerous in high-stakes risk scenarios. Minority reports often contain the most important warnings and must not be drowned out by majority opinion.

Case 48: Multi-Agent & Collaboration Memory Errors — Handoff Context Compression Distortion

Scenario

Agent_A handles the first half of the user’s request and hands off a state summary to Agent_B. The summary contains an overview but omits a key constraint the user emphasized: “Budget cannot exceed 5,000.” Agent_B continues from the incomplete summary and recommends a 6,500 solution.

Error Manifestation

The user asks, “Didn’t I say the budget is 5,000?” Agent_B is unaware of the constraint and must apologize and reprocess.

Solution

1. Explicitly mark hard constraints in state summaries: they must be passed verbatim and never compressed or rewritten
2. Add a constraint-verification step: Agent_B confirms the key-constraint list with Agent_A after receiving the summary
3. Use incompressible constraint tokens at the system level so hard constraints survive any compression

Principle

Context compression inevitably loses information, but some information—constraints, promises, safety rules—is unlosable and needs architectural protection.

Case 49: Multi-Agent & Collaboration Memory Errors — Agent Capability Advertisement Mismatch

Scenario

In the service registry, Agent_A advertises itself as “can handle all PDF-related tasks.” In reality it handles only text PDFs, not scanned PDFs (images). The orchestrator receives a scanned-PDF task and assigns it to Agent_A based on the registry entry.

Error Manifestation

Agent_A fails and the task is reassigned, increasing end-to-end latency by 300%. Frequent misallocation reduces throughput.

Solution

1. Require fine-grained capability registration: Agents must declare detailed boundaries (e.g., “PDF: text only; no scanned or encrypted files”)
2. Pre-check capability before task assignment: an Agent should immediately decline a task it cannot handle and explain why
3. Use dynamic capability-task match scores based on historical success rates rather than static registry entries

Principle

Service-registry capability descriptions are often coarse. Coarse descriptions cause misallocation, wasting compute and adding latency. Fine-grained capability modeling is a prerequisite for efficient orchestration.

Case 50: Multi-Agent & Collaboration Memory Errors — Multi Agent Feedback Loop Oscillation

Scenario

Agent_A and Agent_B collaborate to generate content. Agent_A drafts, Agent_B reviews and proposes revisions, Agent_A revises, and Agent_B reviews again. Agent_B’s review criteria are unstable (e.g., judgments on formality vary), causing Agent_A to oscillate between “more formal” and “more colloquial.”

Error Manifestation

After ten iterations the output still oscillates between two versions and cannot converge. The user waits five minutes without a final result.

Solution

1. Set a maximum iteration count and convergence condition: stop when the change between rounds falls below a threshold
2. Freeze review criteria: Agent_B outputs a review checklist on the first pass and applies it consistently thereafter
3. Use diff review: Agent_B reviews only changes between the current and previous versions instead of the whole document

Principle

Feedback loops in Multi-Agent collaboration can oscillate without convergence mechanisms. Like unstable control-system feedback, they need damping such as thresholds and frozen criteria.

Source: Agent Search