Multi-Agent Orchestration on Salesforce: What Makes Agent-to-Agent Handoffs Work in Production

The short answer: multi-agent orchestration on Salesforce means one orchestrator agent owns the conversation and hands each task to a specialist agent that owns a narrow domain. What makes it reliable in production is not a bigger prompt on the orchestrator, it is a tight handoff contract between agents: what gets passed, what comes back, and who is allowed to act. Salesforce moved Agentforce multi-agent orchestration to general availability on 15 June 2026, and the Agent2Agent (A2A) protocol extends the same pattern to agents that do not run on Salesforce.

What is multi-agent orchestration on Salesforce?

It is a routing architecture. One primary agent is the user's only point of contact and holds the session context. Behind it sit specialist agents, each scoped to a bounded domain and equipped with its own actions: Apex, Flow, prompt templates, external APIs.

The routing is not a decision tree. The Atlas Reasoning Engine reads every registered agent's description, instructions and available actions, then picks the best fit at runtime. That has a consequence teams underestimate: an agent description is routing logic, not documentation. Vague descriptions produce vague routing.

Why does one big prompt stop working?

Almost every team tries the single-agent version first. It demos well and degrades in production, for reasons that are structural rather than fixable:

• Instruction dilution. Rules that matter in one workflow leak into another, and the model averages them.
• Tool sprawl. Past roughly a dozen actions, selection accuracy drops and the wrong tool starts firing.
• No blast radius. One agent with refund rights has refund rights in every conversation it ever holds.
• Untestable changes. A new paragraph about returns can silently change warranty behaviour, and there is nothing to unit test.

A specialist with one job and five actions has none of those problems. The complexity does not vanish. It moves to the seams between agents, which is where it belongs, because a seam can be specified.

What does an orchestrator plus specialists look like in production?

1. An orchestrator that resolves intent, holds context and escalates. It carries no business actions of its own.
2. One specialist per bounded domain, for example entitlement checks, field dispatch or billing adjustments, each with its own action set and its own test cases.
3. A structured context payload passed between them instead of free text.
4. A human approval gate on anything irreversible or financial.
5. Tracing on every hop, so a bad outcome is attributable to one agent rather than to "the AI".

Scale is why this matters. In our ASSA ABLOY programme (FocusCura and Phoniro), the operational surface is 11,000 connected devices producing up to 2.5 million events a week across three markets, and weekly cases fell from 3,000 to 350 with no added support staff. Nobody holds an operational load of that shape inside a single prompt.

What makes a handoff between agents reliable?

This is the part vendor material skips, and it is where production systems actually break. Treat every handoff as an interface, not a conversation.

• Typed in, typed out. If you cannot write the handoff as a function signature, the orchestrator will invent one, and it will invent a different one tomorrow.
• Pass identifiers, not prose. A CaseId and an AssetId survive a handoff. A paraphrased summary does not.
• Give the specialist a way to refuse. "I cannot proceed, the entitlement has lapsed" is a routable answer. Silent improvisation is not.
• Make actions idempotent. Orchestrators retry. A retry must never issue a second refund.
• Version the descriptions. Routing depends on them, so editing one is a production change and belongs in review.

The seam is the product. Agents are the easy part; the contract between them is the engineering.

Where do A2A and MCP actually fit?

A2A handles delegation across platforms. An agent publishes an agent card describing what it can do; a client agent discovers it, delegates a task, and receives messages and artifacts back. That is how an Agentforce orchestrator reaches a specialist running somewhere else entirely.

MCP is the other axis. It gives a single agent access to tools and data. We build MCP servers so one agent can act across the systems a business already runs, instead of forcing every action back through a CRM screen.

Rule of thumb: A2A is agent to agent, MCP is agent to system. Reaching for the wrong one is the most common architecture mistake we see.

How do you roll this out without breaking the seams?

1. Start with three agents on one workflow that already has clean data. Agents layered over messy data multiply the mess.
2. Instrument before you scale. If you cannot trace a single hop today, you will not debug ten agents next quarter.
3. Give every specialist a named human owner.
4. Test routing adversarially, with ambiguous and multi-intent requests, not with the happy path.
5. Keep a kill switch per specialist, so one bad agent does not take the whole workflow down.

FAQ

Is multi-agent orchestration available in production on Salesforce today?

Yes. Salesforce moved Agentforce multi-agent orchestration to general availability on 15 June 2026, with A2A support for agents outside the platform.

How many specialist agents should we start with?

Three, on one workflow. Prove the handoffs and the tracing first, then add domains one at a time.

Does a bigger model remove the need for orchestration?

No. A stronger model improves reasoning inside an agent. It does not give you scoped permissions, per-domain tests or an attributable failure. Those come from the architecture.

What breaks most often in production?

Handoffs. Context lost between agents, misrouting caused by a vague agent description, and retries that repeat an action which was never idempotent.

Do we have to rebuild agents that live on other platforms?

No. A2A lets an Agentforce orchestrator delegate to third-party agents, so a non-Salesforce specialist can join the same workflow.

Tekunda builds multi-agent systems on Salesforce and off it, including agent-to-agent orchestration running in production. If you are moving from one agent to a team of them, designing the seams is the work worth doing first.