Multi-Agent Orchestration in Salesforce: A Practical Guide to Agentforce Super Agents

You built your first Agentforce agent. It answered order questions, so you added billing. Then returns. Then promotions, password resets and a few escalation rules. Six months later the instructions read like a legal contract, the agent sometimes picks the wrong subagent, and nobody on the team wants to touch it before a release.

If that sounds familiar, you are ready for Multi-Agent Orchestration in Salesforce. In this post we will learn what it is, how the Super Agent and Connected Subagent model works, when you should (and should not) use it, how Agent Script gives you deterministic control over routing, and how to test and monitor the whole thing in production

What Is Multi-Agent Orchestration in Salesforce?

Multi-Agent Orchestration is an Agentforce capability where one primary agent owns the conversation and delegates work to specialist agents that each own a single domain. The user only ever talks to one agent. The specialists work behind it.

Salesforce describes the primary agent as a single “front door” for every agent you deploy. It reads the request, works out the intent, routes each task to the specialist best suited for it, and then combines the results into one reply.

Think of it like a good service desk lead. The lead doesn’t fix the laptop, process the refund and book the meeting room personally. They know exactly who does each of those things, they hand the work over with the right context, and they get back to the customer with one clear answer.

Key terms you need to know

Salesforce renamed a few things in 2026, so let’s get the vocabulary straight before we go further.

Term	What it means
Super Agent (orchestrator / primary agent)	The single entry point. Talks to the user, routes requests and consolidates responses.
Connected Subagent	A completely separate agent in the same org that the Super Agent delegates a task to. It does the work and hands the result back.
Subagent (formerly Topic)	A logical group of instructions, actions and conditions inside one agent. Topics were renamed to subagents in April 2026. Functionality did not change.
Agent Router	The entry point for every user utterance. In Agent Script, this is the start_agent block.
Atlas Reasoning Engine	The reasoning layer behind Agentforce. It reads agent descriptions, instructions and actions to decide where a request goes.

The most common confusion is between a subagent and a Connected Subagent. A subagent is internal routing inside one agent. A Connected Subagent is a whole other agent with its own instructions, actions, data access and release cycle. Multi-Agent Orchestration uses Connected Subagents.

Why a Single Agent Stops Scaling

A single agent with a handful of subagents is perfectly fine for many use cases. The trouble starts when you keep adding domains. The Salesforce Admins team calls out three failure modes:

1. Context overload. Long, competing instructions cause the agent to skip guardrails or misroute requests.
2. Specialization collapse. A generalist agent applies domain logic less reliably as more domains are piled on.
3. Boundary limits. One agent cannot neatly respect different data access, permissions or ownership for very different parts of the business.

Splitting everything into separate agents is not the answer either. Then the user has to figure out which bot to talk to, and they end up repeating their order number to three of them. Orchestration gives you the best of both: specialists in the back, one conversation in the front.

How Multi-Agent Orchestration Works (Step by Step)

Here is what happens behind the scenes when a user sends a message

1. Understand. The user talks to the Super Agent. Every utterance lands on the Agent Router first.
2. Route. The Atlas Reasoning Engine reviews each Connected Subagent’s description, instructions and available actions and picks the best fit.
3. Execute. The Super Agent passes input variables (user identity, a case number, an order ID) to the specialist and waits. The specialist runs its own reasoning and actions, usually autolaunched Flows, or Apex for heavier logic.
4. Respond. The specialist returns its result. The Super Agent takes control back, consolidates the answer and replies in one consistent voice.

One line from the research on this topic stuck with me: agent descriptions are no longer documentation, they are routing logic. Treat every description like code

Single Agent or Multi-Agent? How to Decide

Don’t reach for orchestration just because it’s new. Use this quick guide.

Stay with a single agent (with subagents) when:

• One team owns all the work.
• The jobs are closely related and share the same data.
• Example: an HR FAQ agent with Benefits, Payroll and Time Off subagents, all reading from the same HR system.

Move to Multi-Agent Orchestration when:

• Different teams own different parts of the process and want their own release cycle.
• Each domain needs different data access or permissions.
• You want failures isolated, so one broken process doesn’t take the others down.
• You want to reuse the same specialist across several front doors.
• Example: an Employee Services Super Agent that routes to an HR Agent, an IT Support Agent and a Facilities Agent.

The one-sentence test: if you can’t describe a specialist’s job in one sentence without using the word “and”, split it further.

Setting Up a Super Agent with Connected Subagents

This is the build order recommended by the Salesforce Admins team, plus a few lessons from practitioners who have done it.

Step 1: Map your use cases

Group your use cases by functional domain (service, sales, field service), workflow stage (intake, scheduling, fulfilment) or capability (retrieve, analyse, act). Look for the natural places where a human would pause and hand the work to someone else. Those are your agent boundaries.

Step 2: Build and test each Connected Subagent on its own

This is the step people skip, and it hurts later. A weak specialist does not get smarter once you orchestrate it. Build each one as a standalone agent with its own subagents, actions and instructions, and test it until it works by itself.

Step 3: Write precise descriptions

The Super Agent routes by reading descriptions. Vague or overlapping descriptions are the number one cause of misrouting.

Bad: “Helps customers with orders and payments.”

Good: “Handles delivery tracking, dispatch delays and rescheduling for orders that have not yet been delivered. Does not process refunds.”

Notice the second one says what the agent does not do. Negative boundaries help the router a lot.

Step 4: Create the Super Agent

Keep the Super Agent’s instructions focused on routing. Leave domain knowledge inside the Connected Subagents. Some things do belong at the Super Agent level because they must apply to every conversation:

• Guardrails, user policy and compliance (for example GDPR opt-out handling and content safety filtering)
• User verification and context priming (verify once, pass the order or case number along)
• Disambiguation (“I need help with my account” deserves a clarifying question)
• Human handoff and escalation decisions

Step 5: Add one Connected Subagent at a time

Add the first specialist, test routing, then add the next. Repeat until the whole network routes cleanly. Starting with a manager and two specialists is far easier to debug than wiring up seven on day one.

Current considerations

Check these in your org and the latest release notes before you design anything big:

• Salesforce recommends no more than 7 Connected Subagents per orchestrator.
• Supported combinations: Service Agent orchestrator with Service Agent subagents, Employee Agent orchestrator with Employee Agent subagents, and Employee Agent orchestrator with Service Agent subagents.
• Connected Subagents respond, they don’t orchestrate. If one specialist starts trying to call another, revisit your design rather than patching it with instructions.
• Salesforce’s product blog announces the feature as generally available, while some Help and Admins content still labels it Beta. Confirm what your org shows in Setup

Best Practices and Common Mistakes

Do:

• Start with one Super Agent and two specialists.
• Write descriptions that state what an agent does and what it doesn’t do.
• Put shared rules (compliance, verification, escalation) in the Super Agent once.
• Use Agent Script for any route where a wrong turn costs money or breaks compliance.
• Review production routing logs and refine descriptions regularly.
• A/B test the new orchestration against your existing single agent with real traffic.

Don’t:

• Build five specialists on day one.
• Let specialists call each other.
• Copy the same guardrails into every agent.
• Assume there is a dedicated REST endpoint for orchestration. It is configured in Agentforce Builder or Agent Script, and conversations are started through the Agent API as usual.

Summary

Multi-Agent Orchestration is how Agentforce grows up from one overloaded assistant into a team. One Super Agent stays the friendly front door, Connected Subagents do focused work behind it, Agent Script keeps the critical routes predictable, and Observability tells you exactly what happened when something goes wrong.

My advice: pick one messy agent you already have, apply the one-sentence test to its subagents, and split out the first specialist in a sandbox. You will learn more from that one experiment than from any diagram.

Want to get hands-on first? Check out the Apex Hours Agentforce workshop and build your first agent in a free trial org.