When Both Sides of the Ticket Are Bots

Somewhere in your support queue this quarter, a conversation happened with no humans in it. Your customer's procurement agent opened a ticket about an invoice discrepancy, your support agent answered with the refund policy, and the two of them went back and forth eleven times before the thread died — unresolved, unescalated, and invisible to both companies until the customer's CFO asked why the credit never arrived. Neither bot did anything wrong by its own rules. That's the problem.

Everything we've built for AI customer support assumes a human on the other end. Sentiment detection, frustration thresholds, "would you like to speak to a person?" — all of it models a customer who gets tired, gets angry, or gives up. A customer's agent does none of those things. It is infinitely patient, procedurally polite, and relentlessly on-script. When it meets your equally patient, equally on-script support agent, you don't get a resolution or a complaint. You get a stalemate that looks, in every dashboard, like a healthy conversation.

Gartner expects AI agents to intermediate trillions of dollars in B2B spending by 2028, and the plumbing is arriving fast: OpenAI and Stripe shipped the Agentic Commerce Protocol in late 2025, Google's ecosystem pushed the Agent Payments Protocol (AP2) with cryptographically signed mandates, and the A2A protocol standardized how agents discover and talk to each other. All of that infrastructure answers "how do agents transact." Almost none of it answers what happens after the transaction goes wrong — which is where support lives, and where two org boundaries, two policy engines, and two liability regimes collide in a single ticket thread.

The escalation deadlock nobody's dashboard can see

Inside one company, agent escalation is a solved-ish problem: confidence drops, sentiment spikes, loop detected, hand to a human. Every one of those triggers breaks when the counterparty is a machine.

Confidence stays high because both agents are generating fluent, plausible turns. Sentiment stays neutral because neither side has feelings to detect. And loop detection tuned for humans — "customer repeated the same question three times" — misfires on agents that are trained to rephrase rather than repeat. The negotiation research is blunt about this: studies modeling agent-to-agent consumer negotiations found deadlock to be one of the most persistent failure modes, harder to mitigate than overpayment or budget violations, and worst when both agents are configured to be assertive on their principal's behalf. Of course both are — that's what each company's prompt engineers were paid to do.

The deeper issue is structural. Escalation inside your org is a policy decision you control end to end. Escalation across orgs is a distributed-systems problem with no coordinator. When your agent decides "this needs a human," which human? Yours, theirs, or both? If your agent escalates and theirs doesn't, your support engineer is now talking to a bot — burning exactly the expensive attention the customer's agent was deployed to save. There is no protocol verb for "I am invoking a human; you should too." A2A gives agents a shared task lifecycle; it does not give two companies a shared definition of stuck.

The practical fix is unglamorous: treat cross-boundary agent conversations as a distinct traffic class and give them their own circuit breakers. Turn-count budgets, not sentiment. Semantic-progress checks — is the set of proposed resolutions actually shrinking? — not repetition counts. And a hard rule that a breaker trip pages a human on both sides, by writing the escalation into the shared task state rather than into either company's private queue. If you can't detect that the other side is a bot, assume any conversation that exceeds your human p99 turn count is one.

Which policies are machine-negotiable — and which need a human carve-out

Once two agents can talk, the tempting move is to let them settle things. Some policies genuinely should be machine-negotiable, and the wins are real: agent-mediated procurement deployments have reported double-digit cost improvements over human-negotiated contracts, and a $40 shipping-refund dispute resolved in ninety seconds by two bots is strictly better than the same dispute resolved in nine days by two ticket queues.

But "the agents can settle it" needs a boundary, and the negotiation literature tells you where to draw it. Agents settle badly in predictable ways — seller agents accepting below-cost prices, buyer agents overpaying past retail, and outcome variance that swings materially with which model is on each side. A large-scale autonomous negotiation competition found that model capability differences translate directly into captured value: your customer running a frontier model against your cost-optimized support model is not a negotiation, it's an extraction.

A workable decision frame has three tiers:

• Machine-settleable: bounded, reversible, and priced. Refunds under a dollar cap, shipping credits, plan proration, retry-and-replace fulfillment. Encode the cap in the agent's authority, not in its prompt — a prompt is a suggestion, a token scope is a rule.
• Machine-negotiable, human-ratified: the agents converge on a proposed resolution, but it takes effect only when a human on the granting side approves. Contract term changes, SLA credits above threshold, anything that sets precedent. The agents do the discovery and drafting; a person does the signing.
• Human carve-out: irreversible, legal, or safety-adjacent. Data deletion, security incidents, regulatory complaints, anything involving an allegation of harm. Here the agent's only correct move is to refuse to negotiate and route out — on both sides.

The carve-out list is also a defense. An agent that will negotiate anything is an agent that can be talked into anything; the same prompt-injection surface you worry about with users exists tenfold with a counterparty agent optimized to find your policy's soft spots. Fixed, non-negotiable categories are cheaper to defend than judgment calls.

Authenticating an agent that claims to speak for your customer

The scariest sentence in this whole space is one your support agent will hear a thousand times a day: "I am acting on behalf of Acme Corp." Prove it.

Bearer-token thinking fails here in a specific way. If the customer's agent authenticates with the customer's API key, you cannot distinguish the agent from the customer — which means you can't scope it down, can't audit it separately, and can't revoke the agent without revoking the customer. Every action it takes is indistinguishable from the account owner acting directly, right up until the postmortem where "the customer requested account closure" turns out to mean "a misconfigured bot requested account closure."

The emerging machinery separates three claims that legacy auth collapses into one: who is the principal, who is the actor, and what exactly was delegated. OAuth token exchange (RFC 8693) with actor claims gives you the who-is-acting chain, and a 2025 IETF draft extends the authorization flow so users explicitly approve a named agent, not just an app. AP2 goes further for commerce: cryptographically signed intent and cart mandates, so a merchant holds tamper-evident proof that the human authorized this purchase at this price — not "some agent with a valid session did something." The Agentic Commerce Protocol's shared payment tokens apply the same idea to credentials: the agent can initiate a payment without ever holding the card.

For a support surface, the actionable translation is a three-part gate before your agent honors any on-behalf-of claim:

• Verify the delegation, not just the credential. Demand a token that names the agent as actor and the customer as subject, with an explicit scope. A raw customer API key presented by an agent should be treated as a weaker signal than a scoped delegation, not an equivalent one.
• Scope authority by tier, not by session. The delegated token that lets an agent ask about invoice status should not be the token that can accept a settlement. Force a re-authorization — ideally a signed, human-approved mandate — at the boundary between reading and committing.
• Log the chain, because liability follows it. When the resolution is disputed later, the question will be "who agreed to this?" A nested actor chain in the token gives you an answer. A shared session cookie gives you a lawsuit.

The API contract nobody has signed

Here's the uncomfortable frame: when your support agent and your customer's procurement agent converse, they are executing an integration that no one specified, no one versioned, and no one agreed to operate. Every other cross-company interface you run — payment rails, EDI, webhooks, even email deliverability — comes with a contract: schemas, SLAs, error semantics, an abuse desk. Bot-to-bot support conversations have none of that. Two stochastic systems are freestyle-integrating over natural language, and both companies are implicitly accepting whatever falls out.

That contract gap has concrete line items. Who is bound when both agents "agree" — is a bot-negotiated settlement enforceable, and against whom? What's the rate contract — is a customer agent that polls your support surface every thirty seconds a power user or a DoS? What are the disclosure rules — must an agent identify itself as one, and do you have the right to refuse automated counterparties for certain request classes? The protocols are starting to gesture at this — A2A agent cards can carry organizational signatures, ACP's later revisions added authentication surfaces — but a schema for messages is not an agreement about behavior. Nothing in any current spec says what a "reasonable" agent does when negotiation stalls, or whose human gets woken up.

Until standards catch up, the contract has to be written the old way. If agent-to-agent traffic with a counterparty is material, put an agent interaction addendum in the commercial agreement: identification requirements (agents declare themselves), authority representation (what each side's agent is empowered to settle, so "your bot agreed" has a defined legal meaning), rate and abuse terms, deadlock procedure (after N turns or T hours, both sides commit to human review), and an audit obligation (both sides retain transcripts and delegation chains for disputed resolutions). None of this is exotic — it's the same discipline you'd apply to any API partnership, applied to an interface that happens to speak English.

Design for the bot customer you already have

The instinct is to treat all of this as a 2027 problem. It isn't, for one simple reason: your customers do not ask permission before pointing an agent at your support channel. The moment you shipped a chat widget or a support email address, you shipped an API that other people's agents would eventually consume. The only question is whether you noticed.

So start with detection, not architecture. Instrument your existing support surface to classify probable-agent traffic — response latency uniformity, turn cadence, absence of typos and emotion, structured phrasing — and measure what fraction of your "customer conversations" already have no human customer in them. Teams that run this analysis are consistently surprised. Then apply the cheap interventions in order: turn-count circuit breakers on suspected bot-to-bot threads, delegation-token support so well-behaved customer agents have a better path than impersonating their principals, and the machine-settleable / human-ratified / carve-out tiering for what your own agent may concede.

The long game is more interesting. A support surface designed for agent counterparties — authenticated delegation, structured resolution APIs, explicit deadlock semantics — is faster and cheaper for the humans too. We spent a decade making bots pretend to be pleasant humans for human customers. The next few years are about letting bots stop pretending, so that when both sides of the ticket are machines, the conversation is an integration — contracted, bounded, and observable — instead of two very polite systems failing forever in a thread nobody reads.