Multi-Agent Orchestration in Agentforce — The Right Way to Scale

One customer. Multiple specialist agents working together behind the scenes. Here's how Multi-Agent Orchestration works in Agentforce and how to build it the right way.

▶ Watch on YouTube — Full Build and Demo

Multi-Agent Orchestration in Agentforce — Full Build and Demo | The Right Way to Scale Agentforce | SF Bolt

As your Agentforce implementations grow, a single agent handling everything stops being practical. Different workflows need different capabilities — and trying to put it all into one agent creates bloated, fragile prompts and hard-to-maintain logic. Multi-Agent Orchestration is how you scale Agentforce the right way: multiple specialist agents working together as a team, with a single point of contact for the customer.

What Is Multi-Agent Orchestration?

According to the official Salesforce Summer '26 release announcement, Agentforce's Multi-Agent Orchestration enables agents to work together as a unified team to solve complex, end-to-end workflows. It provides customers a single point of contact, with shared context across all channels, so that the customer never has to repeat themselves or work to find the right agent for their question.

The key idea is specialisation. Instead of one large agent trying to handle billing, scheduling, product queries, and escalations, you build purpose-built agents for each domain and orchestrate them from a central point.

The Two Handoff Patterns

Based on the official Agent Script Tools reference, there are two distinct patterns for agent-to-agent handoffs in Agent Script:

Pattern	Syntax	Behaviour
Declarative Transition	@utils.transition to: subagent_name	One-way. The current subagent hands off and does not resume. Context is passed to the new subagent.
Direct Topic Reference	@topic.subagent_name	Delegates to the named subagent and returns to the original caller when done. Behaves like a function call.

Choosing between the two depends entirely on whether the orchestrating agent needs to continue after the specialist is done. A billing handoff after a resolved query is one-way. A verification step that must return a result before the flow continues is a direct reference.

Deterministic vs. LLM-Driven Orchestration

The same logic that applies to reasoning instructions applies to orchestration. According to the official Tools reference and the official Reasoning Instructions reference, you have full control over whether the orchestration decision is made by deterministic logic or handed to the LLM:

Agent Script — orchestrator subagent

subagent: customer_orchestrator

variables:
  intent:       mutable string
  order_total:  mutable number = 0
  is_escalated: mutable boolean = False

reasoning:
  instructions:
    # Deterministic: always route billing issues with high order value
    - @variables.intent == "billing" and @variables.order_total > 1000 ->
      @utils.transition to: senior_billing_agent

    # Deterministic: always escalate flagged cases
    - @variables.is_escalated == True ->
      @utils.transition to: human_escalation_agent

    # LLM-driven: let the LLM choose the right specialist
    | Based on the customer's request, route them to the appropriate
      specialist. Do not repeat information they have already provided.

  actions:
    - name: route_to_billing
      description: Route customer to billing specialist for payment issues
      action: @topic.billing_agent

    - name: route_to_scheduling
      description: Route customer to scheduling agent for appointments
      action: @topic.scheduling_agent

    - name: route_to_product
      description: Route customer to product specialist for product questions
      action: @topic.product_agent

💡 Shared context without repetitionVariables defined at the orchestrator level are accessible to all subagents. This is how the customer never has to repeat themselves — the subagent receives the context the orchestrator already captured. For example, if the orchestrator collected customer_name and account_id, those variables are already available when the billing specialist takes over.

Real-World Example: Service Resolution Flow

Here's a practical multi-agent architecture for a service use case, using Agent Script transitions as described in the official Tools reference:

Agent Script — specialist subagent with return

subagent: identity_verification

variables:
  verified: mutable boolean = False
  customer_id: linked string

reasoning:
  instructions:
    # Call verification action deterministically
    - @actions.send_verification_code with (
        email: @variables.customer_email
      )
      set: customer_id = result.id

    # Guide LLM to confirm code with customer
    | Ask the customer to enter the verification code sent to their email.
      Confirm the code matches. If incorrect, offer to resend.
      Once verified, set @variables.verified to True.

    # Return to orchestrator once done — @topic reference returns to caller
    - @variables.verified == True ->
      | Verification complete. Continuing with your request.

Agent Fabric: Orchestrating Beyond Agentforce

For enterprise scenarios that require orchestrating agents beyond the Agentforce platform, Salesforce has introduced Agent Fabric and MuleSoft Agent Broker. According to the official Agent Fabric announcement, Agent Script for Agent Broker brings the same guided determinism that powers Agentforce to Agent Broker — letting you define fixed handoff rules while LLMs handle the reasoning in between. This allows multi-agent workflows across third-party agents that don't interact through Agentforce directly.

⚠️ The "Orchestrate Other Agents" documentation is BetaThe official documentation for orchestrating external agents from within Agentforce is listed as Beta in Summer '26. The Agent Script-based orchestration within Agentforce (using @topic references and @utils.transition to) is the stable, documented approach covered in this post.

Why This Matters for Scale

According to the official Summer '26 release announcement, Agentforce's Multi-Agent Orchestration is Salesforce's answer to the complexity of enterprise-grade agentic workflows. The design principle is clear: scale agents, not complexity. Instead of one monolithic agent that degrades as instructions grow, you compose a network of focused, reliable agents and let deterministic orchestration hold them together.

Key Takeaways

🚀 Multi-Agent Orchestration — Quick Reference

• One-way handoff: @utils.transition to: subagent_name — no return to caller
• Returnable delegation: @topic.subagent_name — returns to orchestrator when done
• Variables defined in the orchestrator are accessible across all subagents — no context repetition
• Combine deterministic transitions (rules-based routing) with LLM-driven tools (intent-based routing) in the same orchestrator
• Keep each specialist subagent focused on one domain — billing, scheduling, verification, escalation
• For cross-platform orchestration (third-party agents), Agent Fabric and MuleSoft Agent Broker extend the pattern
• "Orchestrate Other Agents" is Beta in Summer '26 — the @topic pattern is the stable GA path

📄 Sources: Agent Script Reference: Tools — Agentforce Developer Guide  |  Agent Script Reference: Reasoning Instructions  |  Summer '26 Release Announcement — Salesforce News  |  Agent Fabric Announcement — Salesforce News

Watch on YouTube - Full Build And Demo

 If you have any question please leave a comment below.

If you would like to add something to this post please leave a comment below.

Share this blog with your friends if you find it helpful somehow !