Lexdatum.

Multi-vendor agent orchestration reaches mainstream enterprise software

Salesforce’s Winter ’27 release brings A2A-based third-party orchestration into a major enterprise suite, validating interoperability as a procurement requirement.

First published1 September 2026

Read in Spanish →

Editorial diagram for Multi-vendor agent orchestration reaches mainstream enterprise software

Salesforce’s Winter ’27 release brings A2A-based third-party orchestration into a major enterprise suite, validating interoperability as a procurement requirement.

Salesforce’s Winter ’27 release includes third-party agent orchestration across A2A-compatible environments. The company says Agentforce can coordinate agents from AWS, Azure, Google and other ecosystems, or participate as a subagent when an external orchestrator owns the workflow.

A product announcement does not prove seamless interoperability in every real environment. It does signal that multi-vendor agent coordination has moved from standards discussion into the roadmap of mainstream enterprise software.

The one-platform agent strategy is weakening

Large enterprises already run multi-cloud, multi-SaaS estates. Agent architecture will inherit that reality.

A customer-service agent may live near CRM. A supply-chain agent may sit on a different cloud. A coding agent may be chosen by engineering. A regulated workflow may require a private model. An acquired company may bring its own platform.

Attempting to consolidate every agent before creating value is unrealistic. Allowing each one to coordinate through proprietary point-to-point integrations is equally unsustainable.

Interoperability becomes a procurement requirement.

Orchestration has several possible owners

A multi-agent workflow can be coordinated by:

  • a domain platform such as CRM or ERP;
  • a neutral enterprise orchestration layer;
  • a custom application;
  • a specialist agent;
  • an event-driven workflow engine.

There will not be one correct answer for every process. The owner should be the layer with the clearest business state and accountability.

For a customer-service resolution, CRM may own the case and coordinate other agents. For a cross-enterprise procurement workflow, a neutral orchestrator may be more appropriate. For a software release, the delivery platform may own the state.

The mistake is allowing orchestration ownership to emerge accidentally from whichever vendor built the first demo.

A2A reduces plumbing, not responsibility

A2A can standardise discovery, delegation, status and results. It does not answer the enterprise questions:

  • May this agent delegate this task?
  • Which user or business event authorised it?
  • What data can cross the vendor boundary?
  • How is the recipient’s output verified?
  • Which party owns an outage or incorrect action?
  • Where is the complete trace stored?
  • Can the organisation stop the workflow across all platforms?

These controls must travel with the task or be enforced by a shared gateway and policy plane.

The agent mesh needs architecture

As third-party orchestration becomes common, organisations will need an agent mesh analogous to earlier API and service-mesh layers.

It may include:

  • registry and discovery;
  • agent identity and trust;
  • policy and delegated authority;
  • trace propagation;
  • task lifecycle;
  • routing and fallback;
  • data-classification enforcement;
  • cost allocation;
  • incident isolation;
  • version compatibility.

The mesh should not make every agent reachable by every other agent. Its first job is controlled segmentation.

Skills and capabilities are the unit of reuse

Salesforce’s parallel work on MCP servers and reusable skills reinforces a complementary pattern. A2A coordinates agents horizontally. MCP exposes capabilities vertically. Skills package the knowledge and logic required to use them.

Together, these layers can produce a multi-vendor architecture:

business event → orchestrator → specialised agent → governed capability → system of record

Each boundary has a contract. Each action can be traced.

Procurement questions change

Enterprise buyers should add interoperability requirements to new agent platforms:

  • support for open protocols and exportable traces;
  • documented identity and delegation;
  • portable tool schemas;
  • ability to act as coordinator and subagent;
  • model and framework flexibility;
  • version and conformance testing;
  • clear data transfer and residency terms;
  • an exit strategy for stored state and skills.

“Integrates with everything” is not sufficient. Buyers need the exact protocol, control and portability model.

The Lexdatum view

Multi-vendor agent systems are not a future edge case. They are the default outcome of how enterprises buy technology.

The strategic objective is not universal agent conversation. It is controlled composition: each platform contributes the capability it owns, while identity, policy and evidence survive every handoff.

The companies that define their orchestration layer now will avoid recreating the integration silos of the last software era.

Sources


Research note: This analysis is based on public information available on 31 August 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported metrics are identified as such. This is not legal, security or investment advice.

Discuss this architecture with Lexdatum

Discuss this architecture

A 60-minute conversation with a partner. No commitment, no sales script. If this architecture fits a real problem, we will tell you how to start.

Discuss this architecture