Here is the pattern I see over and over. A team ships their first Agentforce agent. It handles order status, answers a few product questions, maybe files a case. The demo lands, leadership is happy, and the obvious next move is to make it do more. So they add returns. Then billing. Then technical triage. Then a few HR questions because why not, it is already there.

Six months later that agent has forty actions, an instruction set the length of a short novel, and a habit of picking the wrong action at the worst possible moment. Nobody broke anything. They just kept adding, and the agent quietly crossed a line.

That line has a name. It is the point where capability sprawl outruns the reasoning engine's ability to choose well.

There is a second force at work, and it is organizational rather than technical. The Sales Ops team owns lead qualification. The Support team owns ticket resolution. Finance owns collections logic. When you cram all of that into one monolithic agent, you have also crammed three teams into one set of instructions they all have to edit carefully without stepping on each other. That is a governance problem disguised as a configuration file.

Multi-Agent Orchestration, going GA on June 15 with the Summer '26 release, is Salesforce's answer to both forces at once. Instead of one agent that does everything, you build a team of specialists, each with a tight scope, sitting behind a single primary agent that the customer actually talks to. The split solves the reasoning problem and the ownership problem in the same move.

The core idea is simple enough to explain over coffee. A customer talks to one agent, the primary agent. That agent does not try to answer everything itself. It figures out what the customer actually needs and hands the task to whichever specialist is built for it. The specialist does the work, passes the answer back, and the primary agent delivers it. The customer never knows a handoff happened.

Think of it like a good front-desk manager at a busy office. You walk in, explain your problem once, and they connect you to the right person. You do not get routed through a phone tree. You do not repeat yourself five times. That is the experience the primary agent is built to give.

The Three Roles in Play

The detail that matters most for architects is how Atlas decides. It does not follow a fixed decision tree or match keywords. It reasons from the descriptions every time, fresh, based on the task in front of it. The enhanced Atlas architecture that powers this routing delivers roughly 50% lower latency than earlier versions, which is what keeps the supervisor pattern from becoming a bottleneck at enterprise scale.

This changes how you write agent descriptions. In a single-agent world, the description was mostly a label. In a multi-agent world, it is the thing that determines whether work lands on the right specialist or the wrong one. Be explicit about what each agent handles. Be just as explicit about what it does not handle. A description that says "handles customer inquiries" is useless to Atlas. A description that says "handles return authorizations, refund status, and exchange eligibility, but not billing disputes or shipping questions" is something the engine can actually route against.

Salesforce's own architecture guidance lays out a set of orchestration archetypes, and they are worth knowing by name because they map to genuinely different problems. You do not pick one and stick with it forever. You compose them as your needs grow.

Within SOMA, you also choose how specialists collaborate, and this is where the design gets interesting. Two collaboration shapes cover most real systems.

A practical example brings it together. Imagine a high-value contract being drafted. The orchestrator swarms the task: a legal agent reviews the clauses, a credit agent checks the customer's recent payment history in Data 360, and a supply chain agent confirms inventory for the quoted items. All three run at once, report back, and the orchestrator assembles a single answer. No human stitched those three systems together. The architecture did.

The Agent2Agent protocol, or A2A, is the piece that lets multi-agent systems extend past the edge of Salesforce. It is an open standard that defines how agents find each other, exchange structured information, and collaborate securely across platforms. Salesforce did not invent a proprietary handshake here. They adopted an open one, which is the right call for a feature whose whole point is crossing boundaries.

The mechanics are worth understanding at a high level. A2A uses a client-server model: a client agent orchestrates the work, and a remote agent processes the task through structured, stateful messaging. The protocol defines how agents communicate, not how they think. A specialist's internal reasoning stays private. That separation is what lets a Salesforce orchestrator delegate to a non-Salesforce agent without either side exposing its internals.

Here is the honest framing for most Salesforce teams in mid-2026: A2A is infrastructure to understand, not infrastructure to deploy on day one. The cross-platform scenario, where a procurement agent on one cloud talks to a logistics agent on another and a CRM agent in Agentforce, is real and it is coming. But it requires mature agents already running in multiple systems. That is not a first-week configuration. It is a target state you design toward.

A2A pairs naturally with MCP, the Model Context Protocol, and the two solve different problems. MCP gives an agent reach into tools and data beyond Salesforce. A2A gives agents the ability to delegate to each other within a trusted orchestration layer. One extends what a single agent can touch. The other extends how many agents can work together. You will use both, and knowing which one a given problem calls for is part of the job now.

Multi-agent systems introduce a failure mode that single agents simply do not have. It shows up at the seam, the moment work passes from one agent to another. This is where context can quietly drop, and when it drops, the downstream specialist makes a decision based on an incomplete picture.

Governance Scales With Agent Count

Every specialist you add is another identity that can read and write data. In a single-agent world you governed one thing. In a multi-agent world you govern a fleet. Salesforce builds the controls in: orchestration runs within Einstein Trust Layer guardrails, agents operate against a shared data model, and Agentforce Observability lets you monitor performance, trace interactions, and enforce policy across the whole system. The platform gives you the levers. You still have to pull them.

The best multi-agent rollouts I have seen share a rhythm. They do not start by drawing an org chart of fifteen agents. They start with one agent, let it earn its complexity, and split only when the signals show up. Then they grow the team one specialist at a time, testing each seam as they go.

Salesforce's direction makes the bet clear. The architecture guidance says Agentforce was designed for multi-agent orchestration from the start, with that orchestration sitting underneath the Atlas Reasoning Engine itself. The Summer '26 release moves it from something you assembled with custom Apex into something you configure. Gartner expects multi-agent systems to handle 15% of day-to-day work decisions autonomously by 2028. The platform is being built for a world where teams of agents are the default, not the exception.

For architects, the question shifts. It is no longer "should we build an agent." It is "where do the boundaries between our agents belong, and who owns each one." That is an org-design question as much as a technical one, and it is the question worth spending real time on before anyone touches a config screen.

Start with one agent that does one thing well. Let the seams reveal themselves. Then build the team your business actually needs, one well-described specialist at a time.