Agentforce Multi-Agent Orchestration: Architecture Patterns for Production (Summer '26)

Multi-agent orchestration reached general availability in Salesforce on June 15, 2026. That's the easy sentence. The harder one: most teams treating it as a configuration task rather than an architecture decision will hit production problems within 60 days.

This guide covers the architecture patterns that work, the failure modes that don't, and the specific decisions you need to make before you build your first agent team.

---

What Changed in Summer '26: GA, Atlas 3.0, and A2A

Multi-agent orchestration is now generally available under Summer '26 (API v67.0). Three components underpin it:

Atlas Reasoning Engine 3.0 — the coordination layer that reads specialist agent descriptions and routes tasks based on semantic match, not fixed decision trees. This is the key shift from prior implementations: routing is dynamic. The orchestrator doesn't follow a flowchart; it reads descriptions and makes routing decisions in real time.

Agent2Agent (A2A) protocol — enables secure agent-to-agent communication across vendors. A Salesforce orchestrator can delegate to a specialist agent running on Azure, Google Cloud, or an open-source framework. With 150+ organizations running A2A in production as of mid-2026, multi-vendor agent ecosystems are no longer experimental.

Agent descriptions as routing signals — this is new behavior that operators must internalize: in Summer '26, the reliability of your multi-agent system depends primarily on how well you write agent descriptions, not on how complex your routing logic is.

---

The Core Architecture: Orchestrator and Specialists

The production pattern has two layers:

Manager Agent (Orchestrator)

The Manager Agent is the single entry point for all user interactions. It:

• Receives incoming requests from any configured channel
• Reads the descriptions and available actions of registered specialist agents
• Routes the work (or parts of it) to the appropriate specialist
• Holds the conversation context across specialist handoffs
• Returns a unified response to the user

The Manager Agent doesn't solve problems — it delegates them. Its quality is measured by routing accuracy, not by how many actions it can perform itself.

Specialist Agents

Specialist agents are scoped, single-domain agents that handle one category of work with depth. Examples:

Each specialist is built in Agentforce Builder, grounded in its specific data sources, and registered under the Manager Agent. The Manager reads each specialist's description to know when to use it.

---

How Atlas 3.0 Routes Work

When a user sends a message, Atlas 3.0 on the Manager Agent runs this sequence:

1. Intent classification — what is the user asking for?
2. Description scan — Atlas reads the descriptions of all registered specialist agents
3. Semantic match — Atlas scores each specialist against the intent; selects the best match
4. Delegation — the Manager passes the request and relevant context to the specialist
5. Response aggregation — the specialist's output returns to the Manager, which synthesizes the final user response

If a request spans multiple specialists (e.g., "cancel my order and update my billing address"), the Manager can run delegations in parallel or sequence and aggregate the results.

What this means for you: you cannot control routing by writing flowchart logic in the Manager Agent. You control routing by writing accurate, specific specialist agent descriptions. A vague description ("handles customer needs") produces misdirected routing. A specific one ("handles order cancellations, shipment tracking, and return initiation for retail customers with purchase history in Commerce Cloud") routes reliably.

---

The Seam Problem: Where Most Production Systems Break

The seam is the boundary between the Manager Agent and a specialist. Crossing it requires:

• Passing conversation context (what the user has already said)
• Passing session state (what data has already been retrieved)
• Passing partial results (if the Manager has already gathered some information)
• Receiving the specialist's output in a format the Manager can synthesize

Most production failures in multi-agent systems don't happen inside individual agents — they happen at the seam. Three specific failure modes:

Context loss at handoff. The specialist receives the routed task but not the conversation history. The user has to repeat information they already provided. CSAT drops immediately.

Fix: Pass the full conversation context object when delegating, not just the most recent message. In Agent Script, this is the @conversation.history variable.

State fragmentation. The Manager runs two specialist delegations in parallel, each retrieves overlapping data (e.g., both query the customer's account), and the results conflict.

Fix: Use Inline Actions in the Manager to pre-load shared context before any specialist delegation begins. Both specialists then receive the same baseline data rather than querying independently.

Aggregation failure. The Manager receives responses from two specialists and can't synthesize them coherently because they're formatted differently or reference different records.

Fix: Standardize specialist output format. Define a response schema for each specialist (structured fields, not free text) that the Manager expects and can merge.

---

Cross-Vendor Orchestration with A2A

A2A (Agent2Agent) protocol lets your Salesforce Manager Agent delegate to agents built outside Salesforce. The protocol handles authentication, context passing, and response formatting across the vendor boundary.

Example architecture:

Salesforce Manager Agent
├── Salesforce: Order Management Specialist
├── Salesforce: Account Health Specialist
├── Azure: Logistics & Carrier Agent (3PL integration)
└── Google Cloud: Fraud Detection Agent (ML model)

The Manager routes to whichever specialist is registered, regardless of where it runs. From the user's perspective, it's one conversation. From the architecture's perspective, it's a distributed system.

A2A in practice:

• Register external agents in Agentforce Builder under External Agent Connections
• Provide the agent's endpoint URL, authentication credentials, and description
• Atlas reads the external agent's description the same way it reads internal specialists
• Context passes over HTTPS with Salesforce's Einstein Trust Layer enforcing data governance

With 150+ organizations running A2A in production, the patterns are established. The main constraint: external specialist agents must expose a compatible API endpoint. Most LangGraph and CrewAI deployments can be A2A-compatible with a thin adapter layer.

---

Building Your First Multi-Agent System: Sequence Matters

Don't build the Manager Agent first. Build the specialists.

Step 1: Build and validate each specialist independently. Each specialist should work correctly as a standalone agent before you wire it into an orchestration system. A specialist with a 40% failure rate on its own domain will drag down every multi-agent workflow it participates in.

Step 2: Write specialist descriptions as routing signals. After validating each specialist, rewrite its description explicitly for routing. Include: what domain it covers, what data it accesses, what use cases it handles, and what it doesn't handle. For how to write and configure descriptions in Builder, see the Agentforce Builder guide.

Step 3: Build the Manager Agent. Register validated specialists. The Manager's configuration is minimal: channel setup, Inline Actions for shared context pre-loading, and a fallback path for requests that don't match any specialist.

Step 4: Test routing explicitly. Send 20–30 test inputs that should route to each specialist. Record where Atlas actually routes them. Rewrite descriptions for any specialist with a routing accuracy below 90%.

Step 5: Test handoff seams. Run test conversations that cross multiple specialists. Check that context passes cleanly, responses aggregate correctly, and the user never has to repeat information.

---

When Not to Use Multi-Agent Orchestration

Multi-agent architecture adds complexity. Some scenarios don't need it:

Use a single agent when:

• Your use case is in one domain (service-only or sales-only, not both)
• Your data sources are already unified in Data Cloud
• Your team doesn't have the bandwidth to maintain multiple specialist agents

Use multi-agent when:

• You need to serve multiple distinct domains from one entry point
• Different domains require different data access, knowledge bases, or escalation paths
• You're integrating non-Salesforce specialist agents via A2A
• Your conversation volume justifies the operational overhead

Most mid-market deployments start with a single well-configured agent and graduate to multi-agent when a second domain adds enough volume to justify a dedicated specialist.

---

Operational Requirements: What You Need to Run This in Production

Multi-agent orchestration isn't a set-and-forget deployment. Plan for:

Description maintenance. When a specialist's scope changes (new product line, new policy, new data source), its description must update. Stale descriptions produce routing drift over time.

Seam monitoring. Set up alerts for handoff failures — context loss, aggregation errors, unexpected escalations. Agentforce Command Center provides conversation-level traces; use them.

Specialist-level CSAT tracking. Track satisfaction at the specialist level, not just the overall conversation. A low-CSAT specialist is a routing bottleneck; the Manager keeps sending work to it, and the user keeps having a bad experience.

A2A health checks. External specialist agents running on other clouds need uptime monitoring independent of Salesforce's status. If the logistics agent goes down and the Manager doesn't have a fallback, routing to it produces a silent failure.

For the data foundation that determines whether specialists can retrieve the context they need at the seam, see Salesforce Data Cloud: Why It's the Foundation Every AI Agent Needs.

And for the ROI implications of multi-agent vs. single-agent architectures, the Agentforce ROI Benchmarks covers how deflection rates and TCO shift as you scale from one to many agents.

---

Quick Reference: Multi-Agent Architecture Checklist

Before you build:

• Define each specialist's domain scope (what it handles and what it doesn't)
• Validate each specialist as a standalone agent before orchestration
• Write specialist descriptions as routing signals, not marketing copy
• Plan shared context pre-loading via Manager Inline Actions

At the seam:

• Pass @conversation.history on every specialist delegation
• Standardize specialist output schemas
• Pre-load shared data in Manager Inline Actions before parallel delegations
• Test every seam with simulated multi-domain conversations

In production:

• Monitor routing accuracy per specialist
• Track CSAT per specialist, not just per conversation
• Alert on handoff failures and aggregation errors
• Schedule description reviews when specialist scope changes