How to Set Up a Super Agent with Connected Subagents

When you start building agents in Agentforce, your first instinct might be to make one agent do everything. One set of instructions, one agent to handle billing questions, delivery updates, promotions, and escalations all at once. It seems like the right thing to do.

But the more you ask a single agent to do, the harder it becomes to write clean instructions, test predictable behavior, and maintain it over time. Subagents (formerly known as topics) start competing with each other for the same requests. The reasoning engine starts to make surprising choices because there’s too much competing context to sort through. And when something breaks, it becomes harder to know where to look.

That’s where multi-agent orchestration comes in. Instead of one agent trying to do everything, you build a team and structure it to route intelligently. To recap from my previous blog on when to build a Super Agent, this means building a Super Agent that’s responsible for the interaction with the end user while it delegates part of what needs to be done to other agents, called Connected Subagents. 

Here’s what I learned building one.

Design your agents with the right scope

Before you build anything, you need to answer one question: What should each agent actually do?

Asking this question will help you use decomposition. Decomposing your subagents in the right way is the most consequential design decision you’ll make in a multi-agent setup. When you get it right, your routing is clean, your agents are easy to reason about, and when something goes wrong, you’ll know exactly where to look. 

Three ways to decompose agents

There are three good ways to decide what the scope for each subagent should be. 

• By functional domain: Mirror how your business activities are organized. A field service agent, a support agent, and a sales agent each own a specific part of the business. The trick here is to keep a close watch so that the domain doesn’t become so comprehensive that it’s better to split into multiple workflow stages or capabilities. 
• By workflow stage: Use this when each stage of a process is substantial and has distinct actions you could reuse in other workflows too. For example, a Scheduling subagent that books interviews today can schedule field service appointments tomorrow. A benefit of this approach is that you can reuse the same Connected Subagent for multiple Super Agents. 
• By capability: Structure around what an agent does: one retrieves, one analyzes, one acts. These can even run in parallel depending on your setup.

You may have noticed that these decomposition strategies go from larger to smaller scopes, and that’s intentional. Initially, you’re most likely to start with agents that represent functional domains. Over time, as the scope of your agents increases, it’s likely that a further decomposition by workflow stage or capability becomes a good strategy. 

Understand when to route to a Connected Subagent 

Not sure when to use a Connected Subagent working with a Super Agent over a subagent inside a single agent? Connected Subagents are typically useful at the areas in your business process where the team or person doing the work changes but there’s a single contact person who stays in charge to ensure all other players do the work in the right timeline. 

Use these questions to help decide when a Connected Subagent is a good idea.

1. Where does the work naturally hand off? Look for moments when execution moves to a different team, a back-office process, or a different system. Those handoff points are usually the same between humans and agents.
2. Is the agent’s work truly independent? Not every self-contained task deserves its own agent. If it’s just one step with no real reasoning behind it, it’s probably an action, not a Connected Subagent. A Connected Subagent needs its own input and output, and enough reasoning, data access, and logic to justify existing as a standalone agent. If the answer is yes to all three, you have a real agent boundary. 

Write instructions for your Super Agent to route reliably

Keep the Super Agent’s instructions focused on routing and leave domain knowledge in the Connected Subagents. The Super Agent is the generalist who delegates to the Connected Subagents while staying the point of contact for the end user. 

Here’s a high-level overview of what happens behind the scenes.

• The user interacts with the Super Agent.
• Your Super Agent’s Agent Router is the entry point for every user utterance. (In Agent Script, you’ll see it as the start_agent block.) 
• The Super Agent reads through the information about its subagents and each Connected Subagent’s description and matches it to what the user needs. 
• The Super Agent interfaces with the user directly and delegates specific tasks to other specialized agents (Connected Subagents).
• The Connected Agent uses actions and data to complete its task and provide a response back to the Super Agent.
• The Super Agent consolidates the response, reasons again, and responds back to the user.

When you’re designing a team of agents that work together, every Connected Subagent needs a clear description of their responsibilities. That’s what lets your Super Agent act as the orchestrator. 

In the ideal world, the Super Agent reads each Connected Subagent’s description and routes the request to the best suited Connected Subagent. A vague or overlapping description is the most common cause for routing issues. If it keeps picking the wrong specialist, review the Connected Subagent descriptions first. 

But sometimes descriptions alone don’t always get you there. Your Super Agent can also have its own subagents to allow you to take capabilities that used to live in the specialized agents, but can be reused across the common team of agents. These include:

• Guardrails, user policy, and compliance. GDPR opt-out handling and content safety filtering belong here at the Super Agent level because these rules need to apply consistently across every interaction, regardless of which Connected Subagent handles it. You don’t want five agents each maintaining their own version of the same compliance logic. 
• User verification and context priming. You’ll need to verify identity only once, and then pass the context to the Connected Subagent. This applies to other information the specialist will need, such as order number or case number. 
• Disambiguation. If someone asks something ambiguous, such as “I need help with my account”, it’s the Super Agent’s job to ask a clarifying question. The Super Agent is in charge of the conversation with the end user, so the clarification belongs here, not spread across each specialist separately.
• Human handoff. The Super Agent decides, based on the answers provided by the specialized agents or the end user, whether human escalation is required. You don’t want that logic fragmented across agents.

You may need more deterministic control over the Super Agent than the large language model (LLM)’s reasoning alone can give you. A few common cases:

• Summarizing, trimming, or filtering user inputs before handing it off to the Connected Subagent
• Running user verification or data gathering before the handoff to the Connected Subagent
• Quality gating what Connected Subagent returns to you before it reaches the user

In my multi-agent orchestration build, the Pronto Delivery Concierge Super Agent delegates to three Connected Subagents: Logistics & Dispatch Agent, Accounts & Promotions Agent, and the Billings Agent. Description-based routing got me there about 80% of the time. I needed negative guardrails to stop requests from landing on the “usual” Connected Subagent under certain conditions, and deterministic logic to enforce order status routing.

If a customer says they’ve waited too long for their delivery and demands a refund, without a conditional, the LLM sees “refund” and routes to the Billing Agent. With a conditional, it checks order_status first. If the order is still in progress, it routes to the Logistics Agent instead, even with “refund” sitting right there in the prompt.

if @variables.order_status == “In Progress”:

    invoke @actions.go_to_Logistics_Dispatch

Before that, I ran the flow action Get Order Details, retrieved the customer’s order status, and stored it in a variable that the conditional references directly. That’s the order_status I referenced in the If/Else condition, using Agent Script under the hood. When the condition is met, the routing is guaranteed. 

One thing to know before you build this yourself: With a single agent, you can use transition to in your If/Else statement to automatically transition to the subagent. In a multi-agent orchestration, that doesn’t work. The transition to can’t route directly to a Connected Subagent. It’s a known limitation. Instead, you route by invoking the action that calls the Connected Subagent.

Your turn: Build your first multi-agent orchestration

Ready to give it a try? Here’s how to approach your first multi-agent orchestration build.

1. Map your use cases. Group them by domain, workflow stage, or capability. Look for the natural breaks.
2. Apply the one-sentence test to each Connected Subagent you’re planning. If you can’t describe it cleanly without “and”, split it.
3. Build and test each Connected Subagent independently. Don’t bring them into the Super Agent until each one is working on its own.
4. Create your Super Agent. Configure it to only route to Connected Subagents. It shouldn’t be making decisions or answering user inquiries directly. Before you add your first Connected Subagent, add at least one deterministic pattern to your Agent Router.
5. Add your first Connected Subagent. Test the routing. Confirm it works.
6. Add the next Connected Subagent. Test again. Repeat until your full network is connected and routing cleanly.

Resources

• Salesforce Admins blog: What Is Multi-Agent Orchestration, and When To Build a Super Agent or a Single Agent
• Salesforce Help: Multi-Agent Orchestration (Beta)
• Salesforce+: A Blueprint for Single-Org, Multi-Agent Orchestration