Agent-to-Agent Handoffs Across Company Boundaries: Vendors, Carriers and Partners

The ticket you cannot close on your own

A parcel has been sitting at a sort facility for three days, two days past its promised delivery date. The customer emails at 11:40 p.m. asking where it is. Your AI agent reads the thread, pulls the order from Shopify, checks the tracking number, and finds exactly what the customer already knows: last scan, Tuesday, 6:14 a.m.

Everything useful after that point lives inside somebody else's operation. No amount of orchestration inside your own stack produces the answer, because the answer isn't in your stack.

This is the handoff almost nobody designs for.

Most of the writing on agent collaboration covers multi-agent orchestration inside your own system, where a router agent hands work to a billing specialist and an orchestrator stitches the outputs back together. That's a solved architecture at this point. The interesting problem in 2027 is the one that starts when your agent has to ask a carrier's agent, a payment provider's agent, or a reseller's agent for something, and neither side controls the other.

What you lose the moment you cross the boundary

Inside your own system, four things are free. Across a company boundary, all four have to be built.

• Shared identity. Your billing agent knows who the customer is because it queried the same database your order agent did. A carrier's agent has no idea who your customer is, and shouldn't. It knows a tracking number and a shipper account.
• Shared state. An internal orchestrator holds the whole conversation in memory. Across the boundary there is no shared memory, only whatever you put in the request and whatever comes back.
• Shared vocabulary. "Delayed" means one thing in your ticket taxonomy and something narrower in a carrier's exception codes. Your "refund" may map to their "adjustment" or to nothing at all.
• Recourse. When your internal agent fails, you fix it. When a partner's agent returns nonsense at 2 a.m., you file a ticket and wait like everyone else.

That last one deserves more weight than it usually gets in architecture discussions. Cross-company handoffs are not primarily a protocol problem. They're a contract problem wearing a protocol costume.

Three shapes, and only one of them is easy

Ask and wait

Your agent sends a read-only question to a partner's agent and uses the answer to compose a reply. Where is this shipment. Is this serial number under warranty. Has this payout cleared. Nothing changes on either side; you're borrowing a fact.

This is the pattern to start with, and honestly most teams should stop here for the first six months. The blast radius of a wrong answer is a wrong email, which is bad but survivable. The blast radius of the next two patterns is money moving.

Act on behalf

Your agent asks a partner's agent to do something: reroute a parcel to a pickup point, cancel a subscription that a reseller owns, issue a replacement part from a distributor's inventory. Now you need authorisation that proves your request represents a real account holder's intent, not just your own agent's enthusiasm.

The authorisation question here is the same one covered in verifying that an agent represents a real account holder, pointed in the opposite direction. There, you're the party receiving a claim. Here you're the party making one, and the partner has every reason to be sceptical of you.

Hand over the ticket

The rarest and most dangerous shape. Ownership of the customer conversation moves to the partner, who then emails your customer directly. Warranty claims that become a manufacturer's problem, insurance claims that become an underwriter's, chargebacks that become the acquirer's.

Transfer of ownership means transfer of tone, transfer of SLA, and transfer of the customer's opinion of you. We've seen teams automate this handoff and then discover a month later that their CSAT dropped for reasons entirely outside their system. If you build this one, instrument it before you scale it.

The contract you need before the first request

Before any of these patterns runs in production, both sides need to agree on six things. Not in a Slack thread. In a document, versioned, with an owner on each side.

• Capability declaration. What can each agent actually do, and what is explicitly out of scope? Published as a signed agent card if you're on A2A, as an OpenAPI spec if you're not. The format matters less than the fact that it's machine-readable and versioned.
• Identity and authorisation. How does the partner know a request came from your agent, and how does your agent prove a customer authorised the action? Short-lived scoped tokens, not shared API keys sitting in a config file since 2024.
• Idempotency. Every action-taking request carries a key so a retry after a network timeout doesn't reroute the parcel twice. This sounds obvious and it's the single most common omission we run into.
• Error taxonomy. A finite set of failure codes with agreed meanings, so "cannot complete" and "not authorised" and "temporarily unavailable" are distinguishable. Free-text error strings force one agent to interpret another's prose, which is where hallucination creeps in.
• Response-time commitment. What is the timeout, and what happens after it? Silence must have a defined meaning.
• Data minimisation. The carrier gets a tracking number and a delivery instruction. It does not get the customer's email history, order value, or lifetime spend just because your request payload was easy to build wide.

None of this is exotic. It's ordinary API contract discipline. What's new is that on both ends of the wire there's now a model that will cheerfully improvise when the contract is ambiguous, and improvisation across a trust boundary is how you end up explaining a duplicate refund to your finance team.

Where these handoffs break

Four failure modes account for most of what we see.

Confident wrong answers, laundered through you. The partner's agent returns a plausible delivery estimate that its own system never generated. Your agent has no way to tell a retrieved fact from a generated one, so it passes the estimate to your customer in your brand voice. The customer holds you responsible, correctly. The defence is structural: require the partner's response to carry a source reference or a status code, and treat prose-only answers as low confidence.

Silent timeouts. Your agent asks, nothing comes back, and the ticket sits in a waiting state with no owner. Nobody notices until the customer follows up angrily on day four. Every outbound handoff needs a deadline and a fallback path, and the fallback should almost always be a human with context, not a retry loop.

Ping-pong. Your agent asks theirs for information; theirs asks yours for clarification; yours asks for clarification of the clarification. Two systems that never get tired can do this for a surprisingly long time. Cap the exchange at a small number of turns per ticket and escalate on breach. The same throttling logic applies here as in rate limiting agent-generated support email, just on your outbound side.

Authorisation drift. A token issued for "check shipment status" gets reused for "reroute shipment" because the scope was written loosely and nobody re-read it after the integration went live. Scope creep in machine-to-machine authorisation is quiet and cumulative, which is exactly what makes it dangerous.

What should never cross the boundary automatically

Keep a human on anything that changes who controls an account, moves money to a destination not already on file, or makes a commitment your partner hasn't agreed to honour. A partner agent saying "we can deliver Thursday" is not a promise you're entitled to relay as a guarantee unless your contract says it is.

The customer doesn't know there's a boundary

And they shouldn't have to care.

The worst outcome of cross-company automation is a customer who receives four emails in a day, two of them referencing systems they've never heard of, none of them containing a date. "We've escalated this to our logistics partner" is not information. It's an org chart.

What works: name the constraint plainly, give a specific next checkpoint, and own the follow-up. "The carrier's last scan was Tuesday at their Hyderabad facility. We've opened a trace with them and we'll write back by Friday 6 p.m. either way." Your agent should hold that commitment as a scheduled task, not as a hopeful sentence in an email body. If the partner hasn't responded by Friday afternoon, the agent writes anyway, with what it has.

For teams running high volumes of carrier-dependent tickets, this pattern is most of the work. The logistics and shipping playbook goes into the ticket taxonomy behind it in more detail.

A build order that survives contact with production

1. Pick one partner and one intent. Usually a carrier and a shipment status query. Read-only, high volume, low blast radius.
2. Define the contract before writing code. The six items above, agreed by both sides, with a named owner each.
3. Run it in shadow mode. Your agent makes the call, logs the partner's answer, and a human still writes the reply. Two weeks of this will tell you more about the partner's actual reliability than their documentation will.
4. Go live with a confidence gate. Only auto-send when the partner's response carries a recognised status code and a timestamp inside your freshness window.
5. Add one action-taking intent. Something reversible. Rerouting to a pickup point is a good first choice; issuing credit is not.
6. Instrument the boundary separately. Track partner response time, partner error rate, and the share of tickets where the partner's answer changed your reply. That third metric tells you whether the integration is earning its maintenance cost.

Six months is a realistic timeline for steps one through four with a cooperative partner. It is not a two-week integration, and any vendor telling you otherwise hasn't tried it with a carrier's IT department.

How Robylon handles the boundary

Robylon's email agents resolve 60–80% of inbound support email autonomously, validated against a customer's own historical tickets during onboarding. A meaningful share of the remainder is exactly this category: tickets that stall because the answer sits with a carrier, a payment provider, or a reseller.

The approach is to treat every external system as an explicit, scoped tool rather than a general-purpose connection. Across 60+ write-access integrations, each action is bound to a defined scope, carries an idempotency key, and produces an audit entry showing which external call produced which sentence in the customer's reply. Where a partner exposes an A2A endpoint, the agent uses it; where they expose a REST API and an email address, it uses those. The customer-facing behaviour stays the same either way: a specific commitment, a scheduled follow-up, and a human in the loop when the action isn't reversible.

Ready to close the tickets that depend on someone else's systems? Robylon AI resolves 60–80% of customer emails autonomously with AI agents that take action across Shopify, Zendesk, Stripe, Salesforce and 60+ other integrations. Start free at robylon.ai