Technology · Agent interoperability

Connected agents.
Clear handoffs.

Agent-to-agent interoperability matters when a customer request crosses systems owned by different teams. A2A provides a way for agents to exchange work; a useful integration also needs identity, ownership and a verifiable result.

Map your agent handoffs

Reviewed 19 September 2026 · Protocol and integration guidance

WHY THIS MONTH MATTERS

The platform boundaries are opening.

On 2 September 2026, Genesys announced an expanded enterprise agent ecosystem, including A2A interoperability with Salesforce Agentforce and ServiceNow. Its release says capabilities with these platforms are available and will expand, while describing the A2A work in forward-looking terms. Confirm the exact handoff, region and entitlement before treating it as ready for your project. Genesys announcement and availability notes.

A2A itself predates this announcement. The new enterprise relevance is the prospect of connecting existing customer-service, CRM and operations investments. The first buyer question is concrete: which request currently gets retyped or loses its owner when it moves between systems?

A2A AND MCP

Choose the interface for the job.

Agent2Agent (A2A) standardises communication between agents. Model Context Protocol (MCP) connects agents to tools and data. A2A can carry an ongoing task between systems without exposing an agent’s internal implementation; MCP gives an agent access to a specific capability. They can be used together. Official A2A overview.

Our design rule is to use the smallest interface that meets the need. Reading an order status is usually a tool call. Asking another team’s agent to investigate a delivery exception may require a task with progress, clarification and an eventual result. A stable business API remains a good choice when all the steps are already known.

PROPOSED CUSTOMER-SERVICE FLOW

ONE REQUEST, EXPLICIT OWNERS

Service agent

identify the request
Access policy

identity + permitted data
Operations agent

investigate exception
Verified result

evidence + task status
Service owner

approve the response

Illustrative architecture, not a claim of a shipped QQuantum.ai integration or universal vendor compatibility.

THREE USEFUL HANDOFFS

Delivery exceptions

A support agent asks an operations agent to reconcile order, warehouse and carrier evidence. The reply includes the case reference and next owner, rather than an unsupported promise to the customer.

Employee onboarding

An HR workflow hands an approved starter request to an IT agent. Track each access request separately, verify completion and leave exceptions with the responsible team.

Supplier evidence

A procurement agent asks a specialist reviewer to assess a document pack. Return the required fields, evidence references and unresolved questions. Approval stays with the named procurement owner.

WORKED EXAMPLE

Keep the delivery promise grounded.

Proposed pilot: a customer asks why an order is late. The service agent passes an authorised order reference and a bounded investigation request. The operations agent checks approved sources and returns the latest confirmed event, its timestamp and any uncertainty. The service agent drafts a response from that evidence.

A timeout must leave a visible pending case. A retry must not create a second refund or replacement. Give every handoff a correlation identifier, a deadline and a clear owner; enforce allowed actions at the receiving service. An incoming agent’s request is context, not authority to expand permissions.

Test missing orders, stale carrier data, duplicated messages and a customer withdrawing the request. Measure resolved cases, repeat contacts, manual corrections and elapsed time against the existing workflow. If a single API lookup solves the problem, retain that simpler design.

WHAT TO AGREE FIRST

A task contract before a connection.

Define the input, expected evidence, status transitions and failure behaviour with both system owners. Decide what may be stored, who can cancel work, and how a person resumes a partially completed case. Shared context should contain only what the receiving agent needs.

A platform announcement does not establish interoperability for every pair of agents. Verify supported protocol versions, authentication and task behaviour in a small integration test. Our multi-agent architecture guide covers orchestration choices, while managed runtimes address how an individual agent’s work is executed.

QUESTIONS

QUESTIONS — 3

No. A2A concerns communication between agents; MCP connects an agent to tools and data. A workflow may use both.

No. This month’s relevance is enterprise platform adoption and integration announcements. The protocol already existed.

No universal compatibility is assumed. Confirm the concrete product capability, protocol version, authentication and rollout status with each provider, then test the handoff.

Keep reading

Research

September AI briefing

→

Technology

Managed Agent Runtimes