Why Multi Agent Systems in Logistics Break When AI Agents Pass Work to Each Other 

Multi agent systems in logistics often fail now; one AI agent passes a shipment to the next, even when each agent works well on its own. A booking agent confirms space on a vessel; a customs agent files the declaration, and each one passes its own test. Then the two disagree about the same container, and the shipment stalls between them. 

Multi agent systems are setups where two or more AI agents, each with one narrow job, work on the same task and pass results to each other. In freight, those jobs map to quoting, booking, documentation, customs and exception handling. Handoffs are the weak point: the moment one agent’s output becomes another agent’s input. 

Adoption is moving fast. Gartner forecasts that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025. In the same August 2025 forecast, it expects one-third of agentic AI implementations to combine agents with different skills by 2027. Task-specific agents are agents built for one job, such as filing a customs entry. 

For a CTO running an agent pilot at a 3PL, freight forwarder or shipper, the useful question is which handoff fails first, and who owns the fix. 

Key takeaways 

• Handoffs cause a large share of agent failures. In a UC Berkeley-led study of more than 1,600 failure traces, problems between agents made up about a third of all failures. 

• Every handoff needs a contract. A fixed format that names the shipment version, units, confidence and next owner stops silent data loss. 

• One field, one owner. When the booking agent and the customs agent disagree, a written authority map decides, and a named person breaks ties. 

• Test with past shipments. Replaying closed shipments through the agents and scoring each handoff catches failures before a live container is at risk. 

Follow one export shipment through four agent handoffs 

One common pilot design splits an export shipment across five agents: quote, booking, documentation, customs and exceptions. Each agent can pass its own test while the shipment still fails, because the error sits in what one agent hands to the next. Four handoffs show where that happens and why. 

This worked example is illustrative. It uses common ocean export steps, not a named client project. In it, 18 pallets of pump parts travel in one 40-foot container. 

Handoff 1: quote agent to booking agent 

Pricing starts with a quote agent, which reads the customer’s first email and has a gross weight of 19,800 kg. Two days later, the customer sends a revised packing list showing 22,400 kg. A booking agent then reads the quote summary and books against the old weight. 

What broke: stale state. Booking worked from a copy of the shipment that was two days old. That mismatch surfaces close to the cut-off, when the shipper declares the verified gross mass (VGM), the container weight that the SOLAS convention requires before loading. 

Handoff 2: booking agent to documentation agent 

A carrier confirms the booking but moves the documentation cut-off a day earlier and swaps the vessel. Downstream, the booking agent passes on “booking confirmed” together with the original request details. Next, a documentation agent drafts shipping instructions against the old cut-off, and they reach the carrier late. 

What broke: requested data passed as confirmed data. That handoff message did not separate what the forwarder asked for from what the carrier confirmed. 

Handoff 3: documentation agent to customs agent 

Next in line, the documentation agent describes the goods as “pump spare parts,” while the commercial invoice lists “check valves.” A customs agent classifies the goods from the documentation summary and picks up a Harmonized System (HS) code for pump parts. An HS code is the international product code that customs authorities use to set up duty. 

What broke: a conflict with no owner. A later check flags that the invoice says valves. Two agents now hold different HS codes for the same line, and neither has the authority to overrule the other. So the customs agent files anyway, because its instruction is to meet the filing deadline. Result: an amended declaration and a possible customs query. 

Handoff 4: customs agent to exception agent 

A customs hold notice arrives. An exception agent reads “hold” and rebooks the container onto the next vessel. Meanwhile, the customs agent is already resolving the hold and expects release within hours. Still, the container rolls to the later sailing, and the customer receives two updates that contradict each other. 

What broke: two agents acting on one record. Neither agent checked whether another agent held an open task on the same shipment. 

Where do multi agent systems fail? 

Multi agent systems fail most often at three points: a task that was specified unclearly, agents misreading or dropping each other’s output, and weak checks on the result. Research on open-source agent frameworks puts problems between agents at about a third of all failures, so handoff design matters as much as model choice. 

A UC Berkeley-led team annotated more than 1,600 failure traces from seven open-source agent frameworks in its study, Why Do Multi-Agent LLM Systems Fail? (arXiv, revised October 2025). It grouped failures into system design issues, inter-agent misalignment, and task verification. Inter-agent misalignment, meaning agents that misread, ignore or withhold each other’s work, accounted for roughly 32% of the failures. 

Inside that group, the largest single failure mode was a mismatch between what an agent reasoned and what it then did, at about 13% of all failures. Failing to ask for clarification also appears in the data. Both map directly onto Handoff 3, where the customs agent saw a conflict and filed anyway. 

Stronger models alone will not fix handoffs. Its authors found that much of the failure comes from how the system is designed, so swapping in a stronger base model leaves the same handoff problems in place. 

Governance trails adoption. Deloitte’s State of AI in the Enterprise report (January 2026), a survey of 3,235 IT and business leaders across 24 countries, found that only 21% of organizations have a mature governance model for agentic AI. Put another way, about four in five organizations are running agentic AI development ahead of their governance. 

For logistics of AI agents, governance at the handoff means three written answers: what each agent may pass on, what it may change, and who decides when two agents conflict. 

What should an agent handoff contract include? 

An agent’s handoff contract is a fixed, written format that sets out what one AI agent must pass to the next, which version of the shipment record it refers to, and who decides if the two agents disagree. It replaces free-text summaries with named fields that the receiving agent can check before acting. 

These fields cover the failures in the shipment example: 

• Shipment ID and record version. Receiving agents reject a handoff that points to an older version of the record. This closes to Handoff 1. 

• Field status. Each value is marked as requested, confirmed by a carrier or authority, or estimated. This closes to Handoff 2. 

• Units and formats. Weight in kilograms, dates with a time zone, and HS codes at a stated number of digits. 

• Confidence and open questions. Sending agents list what they are unsure about, so the next agent asks before it acts. This closes to Handoff 3. 

• Next owner and deadline. Each handoff names the agent or person who acts next, and by when. 

Here is a trimmed example of one handoff, from the documentation agent to the customs agent: 

{ 
  "shipment_id": "EXP-20481", 
  "record_version": 7, 
  "from_agent": "documentation", 
  "to_agent": "customs", 
  "goods_description": { "value": "check valves, steel", "status": "confirmed_by_invoice" }, 
  "gross_weight_kg": { "value": 22400, "status": "confirmed_by_shipper" }, 
  "open_questions": ["Packing list says pump parts; invoice says check valves"], 
  "tie_breaker": "customs_broker_on_duty", 
  "act_by": "2026-11-06T14:00:00Z" 
} 

Teams buying custom AI development services should ask to see this contract format before the first agent is built. An AI agent development company that cannot show one is likely to pass free text between agents and find the gaps in production. 

Who settles it when two agents disagree on the same shipment? 

Each field in the shipment record should have exactly one owning agent, and a named person should break the ties that agents cannot settle. A non-owning agent may flag a conflict but may not overwrite the value. This single rule stops the booking agent and the customs agent from correcting each other in a loop. 

A simple authority map for the export shipment looks like this: 

Field or decision	Owning agent	Who breaks a tie
HS code and export declaration	Customs agent	Licensed customs broker on duty
Vessel, cut-off and equipment	Booking agent	Operations lead for the trade lane
Gross weight and packing details	Documentation agent	Shipper contact, through customer service
Rebooking after a delay or hold	Exception agent	Operations lead for the trade lane
Declared value and Incoterms	No agent	Account manager

Set a time limit on every conflict. If the owning agent has not resolved a flag before the next cut-off or filing deadline, the system routes it to the tie-breaker with both values, the source documents and each agent’s reasoning attached. 

In Handoff 4, this rule would have blocked the exception agent from rebooking, because the customs agent held an open task on the same container. A lock on the shipment record, released when the task closes, is often enough. 

Should logistics AI agents share one shipment record or message with each other? 

Most logistics AI agents work well with both: one shared shipment record that holds the current, versioned facts, and messages between agents that carry tasks and handoff contracts. A central orchestrator, sometimes called a supervisor agent, assigns work and enforces ownership. Agents that only message each other, with no shared record, are where versions drift. 

Common patterns for agent orchestration in multi-agent systems, and where each fits: 

• Supervisor patterns. One orchestrating agent assigns each task and checks each handoff. Tracing is simpler, though the supervisor becomes a single point of failure. 

• Peer handoff. Agents pass work directly to each other. Faster to build, and harder to audit when a shipment goes wrong. 

• Shared records with events. Agents read and write one version of shipment record and react to change events. This suits customs work, where an audit trail matters. 

Industry analysts see the same direction. Gartner named multiagent systems among its top supply chain technology trends for 2026 in June 2026 and noted that coordinated agents need strong governance to manage new risks. 

Open standards now cover how agents send messages to each other. Agent2Agent (A2A), an open protocol run by the Linux Foundation, reached version 1.0 with more than 150 supporting organizations by April 2026, and lists supply chain among its adoption areas. Model Context Protocol (MCP) connects agents to tools and data. Neither protocol decides which agent owns the HS code. 

Rao Surapaneni of Google Cloud said in the Linux Foundation’s April 2026 announcement marking A2A’s first year that “AI agents are only as useful as their ability to collaborate.” In freight, that collaboration depends on a written handoff contract and a clear authority map. 

Some steps need no agent at all. Fixed, rule-based steps, such as sending a booking confirmation to the customer, fit standard AI workflow automation, which costs less to run and is easier to audit. 

How do you test agent orchestration before a live shipment? 

Replay closed shipments through the agents and score every handoff, in addition to the outcome. Take shipments from recent months, inject the faults that caused real problems, and check whether each receiving agent noticed the change, asked a question, or escalated on time. A pilot moves to live freight only after it passes. 

1. Build a replay set. Pick 100 to 200 closed shipments with known outcomes, including amendments, rollovers or customs queries. 

2. Inject handoff faults. Change weight after quoting, move a cut-off after booking, and put a conflicting goods description in the invoice. 

3. Score each handoff. Record whether the receiving agent used the latest record version, kept the field status, and raised the right question. 

4. Set pass marks with operations. Agree what share of injected faults the agents must catch before go-live, and which faults they must catch every time. 

5. Keep the set running. Re-run the replay set after every prompt, model or tool change. 

Each failed check points to a specific handoff and field, so both the fix and the go-live decision rest on evidence. 

Agents also need clean connections to the transport management system (TMS), carrier portals, and customs filing software. Weak API integration and orchestration create handoff failures of its own, such as a booking agent reading a carrier’s status that is an hour old. 

A one-week handoff audit for a pilot that is already running 

If agents already run part of your freight operation, a one-week audit shows where the handoffs in your multi agent systems leak before volume grows. It needs to read access to agent traces, a sample of recent shipments, and a few hours a day from one operation to lead. 

• Day 1: List every handoff. Write down which agent passes what to whom, and how it travels: message, shared record, file or email. 

• Day 2: Pull 30 traces. Choose recent shipments that have any amendments and read what each agent received and sent. 

• Day 3: Mark the losses. Note every field that was dropped, changed, or passed without its status. 

• Day 4: Draft the authority map. Assign one owning agent and one human tie-breaker to each field. 

• Day 5: Write the first contract. Start with the two handoffs that lost the most data and add both to a replay test. 

After five days, your team holds a handoff list, a loss log, a first authority map and two working contracts. 

Which of your agents is allowed to change the HS code? 

If the answer depends on which agent happens to run first, your multi agent systems will keep failing at the handoff; however well each agent performs alone. A written contract, an authority map and a replay test fix before the next peak season. 

ViitorCloud’s engineering team works with logistics and freight operators on AI, automation and system integration. In agentic AI development work, that starts with mapping handoffs and building a replay test from past shipments. 

Pick one shipment flow your agents handle today, and book a working session with our engineers to find where its handoffs leak.