Agentforce multi-agent orchestration: designing agent teams that survive the handoff

A customer opens a chat to change a flight, and halfway through the conversation asks whether the fare difference is refundable to their loyalty account. In a single-agent world, that second question either lives inside the same agent — one more topic bolted onto an already crowded router — or it falls off a cliff. In a multi-agent world, a booking agent hands the conversation to a loyalty agent, which answers, and hands it back. When the handoff is clean, the customer never notices the seam. When it isn’t, the loyalty agent asks for a booking reference the customer already gave thirty seconds ago, and the illusion of a single competent assistant collapses.

That handoff is the whole game now. With the Summer ‘26 release, Salesforce moved multi-agent orchestration from beta to general availability — the ability to put one primary agent in front of a team of specialist agents and have it route each request to the right one. It’s the marquee Agentforce capability of the year, and it changes the unit of design from “an agent” to “a team of agents and the seams between them.” This post is about those seams: what orchestration actually does, where it leaks context and credits, and how to build a team that behaves like one assistant instead of a switchboard.

What multi-agent orchestration actually is

The pattern is an orchestrator and a set of specialists. You designate one agent as the primary — Salesforce’s docs call it the single, intelligent entry point for all user interactions — and connect other agents to it as subagents that it can delegate to. The primary analyzes each incoming message, decides which specialist is best equipped to handle it, routes the task, and stitches the specialist’s answer back into one continuous conversation. The user talks to one agent; behind the glass, a team is doing the work.

Two things make this more than a marketing diagram. First, the routing is not a decision tree you hand-wire. The Atlas reasoning engine does it, and it decides by reading each connected agent’s description, instructions, and available actions and picking the best match for the request. Second, the orchestrator carries context across the handoff: information the primary already captured travels with the delegation, which is the mechanism that lets a specialist pick up mid-conversation without making the customer repeat themselves.

If you’ve read our piece on how Atlas classifies topics inside a single agent, the shape here will feel familiar — because it is the same machinery, moved up a level. Inside one agent, Atlas routes an utterance to a topic. Across a team, it routes a request to an agent. The router is the same kind of probabilistic matcher either way, which means the same failure modes apply, and the same discipline fixes them.

The terminology trap: two very different “subagents”

Before anything else, untangle a word that Salesforce has quietly overloaded, because it will cost you an afternoon otherwise. In April 2026 the platform renamed agent topics to subagents, with no change in functionality. So a “subagent,” in the context of a single agent, is what you used to call a topic: a job that one agent can do, with its own instructions and actions.

Then multi-agent orchestration arrived and introduced a second meaning: when you connect a whole separate agent to an orchestrator, that connected agent is also called a subagent.

These are not the same object, and conflating them produces genuinely bad architecture decisions:

• A topic-style subagent is a capability inside one agent. It shares that agent’s model configuration, its guardrails, its session, and its context window. It’s cheap to add and cheap to reason about.
• A connected-agent subagent is a separate agent — its own topics, its own actions, potentially its own model, its own guardrails, and critically, its own context boundary. Every request that crosses into it crosses a seam.

The practical rule: reach for a connected agent only when the specialist genuinely needs to be a separate thing — a different owning team, a different data or security scope, a different lifecycle, or reuse across multiple orchestrators. If the only reason to split is “this agent is getting big,” you probably want another topic, not another agent. Splitting for size trades a manageable problem (a long topic list) for a harder one (a distributed system with handoffs).

Every handoff between agents is a seam, and every seam is a place where context can be lost, intent can be misread, or state can drift. Adding agents adds seams. Only add one when the seam buys you something.

The routing surface is a description — write it like one

Here is the single most important operational fact about multi-agent orchestration: the agent description is now a routing instruction, not documentation. When the orchestrator decides where a request goes, the connected agent’s description is the primary signal it reads. Vague or overlapping descriptions produce a coin flip, and the coin flip is your customer’s experience.

This is exactly the lesson from topic classification, one level up. A description like “This agent uses the LoyaltyAPI to manage points” is written for a human reading documentation. It tells the router nothing about when a user’s request belongs here. Rewrite it as a routing rule in the customer’s own vocabulary:

Booking Agent
  Description: Handles flight changes, rebooking, seat selection, and
  baggage additions for an existing reservation. Route here when the
  customer wants to modify a trip they have already booked. Do NOT
  route here for loyalty points, refunds to a loyalty account, or
  new bookings.

Loyalty Agent
  Description: Answers questions about loyalty tier, points balance,
  points earning and redemption, and crediting fare differences to a
  loyalty account. Route here for anything about miles, points, or
  tier status. Do NOT route here to change or cancel a reservation.

Notice the exclusions. In a single agent, disjoint topic descriptions keep the router from flip-flopping; across a team, disjoint agent descriptions do the same job. State the boundary in both directions — what belongs here, and what explicitly does not — because the negative space is what stops one specialist from confidently answering a question that was meant for another. When an orchestrated team misroutes, the description overlap is the first place to look, every time.

Keep the roster small for the same reason it matters inside one agent: routing reliability degrades as candidates multiply and their descriptions start to blur. Salesforce’s own agentic architecture guidance is blunt about it — start at the minimal orchestration level that achieves the goal, validate under real load, then add. Every additional agent, handoff, or dependency is a new surface that can misbehave.

Deterministic routing when “usually” isn’t good enough

Description-driven routing is probabilistic. For most conversational traffic that’s correct — interpreting a fuzzy request is exactly what the model is good at. But some routing decisions are policy, not judgment: a verified-identity gate before a specialist can touch account data, a compliance step that must run before a refund agent engages. “The router usually sends verified customers to the refund specialist” is not a sentence you want to defend in an audit.

For those cases, express the routing in Agent Script rather than leaving it to the classifier. Agent Script is Salesforce’s hybrid-reasoning DSL: lines beginning with a pipe (|) are prompt text the model sees, and logic introduced with an arrow (->) executes deterministically before the model reasons at all. That split lets you hard-wire the transitions that must never vary while leaving the ambiguous ones to Atlas:

subagent identity_gate:
   description: Verifies the customer's identity before any account action.
   reasoning.instructions: ->
      | Ask the customer to verify their identity if they have not already.
      if @variables.is_verified == True:
         @utils.transition to @subagent.refund_specialist

The if here is not a hint to the model — the runtime evaluates it, and the transition to the refund specialist fires only when identity is actually verified. Not usually. Every time. Two flow-control details matter for orchestration. A @utils.transition to is one-way: control doesn’t return, and the next customer message re-enters at the agent router. A direct @subagent.<name> reference, by contrast, delegates and returns to the caller when the specialist finishes — which is exactly the hand-off-and-come-back shape most orchestration wants. Choosing between them is choosing whether the seam is a dead end or a round trip. Deterministic intra-agent routing and probabilistic cross-agent orchestration are different tools; a well-built team uses scripted transitions for the steps that must be guaranteed and description-based routing for everything genuinely ambiguous.

The allocation question is the same one Agent Script always poses: if this routing decision went wrong one time in two hundred, would anyone outside the team care? If yes, script it. If no, let the description do its job.

Talking to agents you didn’t build: A2A and AgentExchange

Not every specialist your orchestrator needs lives in your Salesforce org. A fraud-scoring agent, a logistics partner’s agent, an internally built agent on another platform — Summer ‘26 lets a Salesforce orchestrator delegate to those too, over the open Agent2Agent (A2A) protocol. A2A is a client-server standard: your orchestrator is the client, the remote agent is the server, and they exchange structured, stateful messages. Alongside it, Salesforce supports the Model Context Protocol for tool access — we’ve covered what MCP standardizes and where its risks live separately.

The piece worth understanding is the agent card — a machine-readable metadata document that advertises what a remote agent can do before any work begins, so the orchestrator knows whether to route to it and how to call it. Conceptually it’s the A2A equivalent of the description field, in JSON:

{
  "name": "Fraud Scoring Agent",
  "description": "Scores a transaction for fraud risk and returns a 0-100 risk score with contributing factors.",
  "url": "https://agents.example.com/fraud/a2a",
  "capabilities": { "streaming": true },
  "skills": [
    {
      "id": "score_transaction",
      "name": "Score transaction",
      "description": "Given a transaction ID and amount, return a fraud risk score."
    }
  ]
}

Discovery of prebuilt agents and skills increasingly runs through AgentExchange, Salesforce’s agentic marketplace, which lists agents and skills that connect over native MCP and A2A support. This is genuinely useful and genuinely risky in equal measure. The moment your orchestrator can delegate to an agent you didn’t build, you’ve extended your trust boundary to code you don’t control — and everything we’ve written about least privilege for agents that consume untrusted input applies with more force, because a remote subagent’s output flows straight back into your orchestrator’s reasoning. Scope what an external agent can be handed, and never route data to it that it doesn’t strictly need to do its one job.

A status note, because this area moves fast: Salesforce positions multi-agent orchestration as generally available in Summer ‘26 for Salesforce-to-Salesforce agent teams, while cross-platform A2A connections are the newer, less-settled edge — parts of the external-connection experience still carry beta labels depending on the builder path. Check current release notes before you commit an external-orchestration pattern to production.

The cost math nobody puts on the slide

Multi-agent orchestration has a pricing shape that a single agent doesn’t, and it’s easy to miss until the invoice arrives. Agentforce meters usage two ways, which we break down fully in our pricing guide: a flat $2 per conversation, or Flex Credits, where a pack of 100,000 credits lists at $500 (half a cent each) and a standard action consumes 20 credits — $0.10 — with voice actions at 30.

Here’s the part orchestration changes. On the Flex meter, you pay for the work that actually runs, wherever it runs. A multi-agent chain that routes to a specialist, has that specialist re-ground against its own knowledge, then routes back, executes more reasoning steps and more actions than a single agent answering the same question in place. More seams, more actions, more credits. And a misroute is pure waste: if the orchestrator sends a request to the wrong specialist and that agent fires two actions before anyone realizes, you’ve burned 40 credits producing an answer you throw away. Sloppy descriptions don’t just hurt the customer experience — they show up on the bill.

The conversation meter smooths this over — one interaction, one charge, regardless of how many specialists touched it — which can make multi-agent designs look cheaper there. But conversations are flat whether the agent answers a trivial question or orchestrates a five-agent workflow, so the crossover math still governs which meter wins. The one thing you should not do is assume orchestration is free because it’s “one conversation.” Turn on Digital Wallet’s per-action visibility before go-live, and watch what routing actually costs under real traffic. If your metering treats each specialist’s grounding as its own operation, a chatty team can quietly multiply your Data 360 grounding spend too — verify against the current rate sheet rather than assuming.

Testing a team is not testing an agent

A single agent has one router to test. A team has a router plus every specialist plus every seam between them, and the seams are where the interesting failures live. Your testing stack needs to grow a new layer:

• Routing assertions. Feed the orchestrator adversarial utterances designed to sit on the boundary between two specialists — the flight-change-that-mentions-points, the refund-that-sounds-like-a-complaint — and assert which agent handles each. This is the multi-agent equivalent of topic-classification testing, and it catches description overlap before customers do.
• Handoff continuity. Verify that context captured by the orchestrator actually reaches the specialist. The test that matters: give the primary a booking reference, trigger a handoff, and confirm the specialist never asks for it again. A dropped variable across the seam is invisible in single-turn tests and glaring in a full conversation.
• Round-trip coherence. After a specialist answers and control returns, does the primary resume the original thread, or has it forgotten why the conversation started? Salesforce’s own architecture guidance names losing the primary objective during a tangent as the classic multi-agent failure — test for it explicitly.

Full-conversation simulation with synthetic personas, which Testing Center now supports, is the tool for this. Single-turn utterance batches can’t exercise a handoff; a handoff only exists across turns.

What to actually do this quarter

Multi-agent orchestration is real, it’s GA, and it’s the right architecture for a genuine class of problems — distinct specialists, owned by distinct teams, reused across channels. It is also an easy way to turn one tractable agent into a distributed system you can’t reason about. The teams that get value from it treat the roster as small and deliberate, write every agent description as a routing rule with explicit exclusions, script the routing decisions that are policy rather than judgment, and test the seams as first-class surfaces rather than assuming context flows for free.

Start from a single well-built agent with clean topics. Split into a team only when a specialist earns its own boundary — and when it does, remember that you haven’t just added an agent. You’ve added a seam, and the seam is now part of your product.

Understanding the basics

What is multi-agent orchestration in Agentforce?

Multi-agent orchestration lets you designate one primary Agentforce agent as an orchestrator that routes each request to the best-fit specialist agent connected to it, presenting the user with a single continuous conversation. The Atlas reasoning engine performs the routing by reading each connected agent’s description, instructions, and available actions. It reached general availability in the Summer ‘26 release, graduating from a Spring ‘26 beta.

How does the orchestrator decide which agent handles a request?

It matches the request against each connected agent’s description — so the description functions as a routing instruction, not documentation. Descriptions must be written in the customer’s vocabulary, state what belongs to the agent and what explicitly does not, and stay mutually exclusive across the team. Overlapping descriptions are the leading cause of misrouted conversations and wasted action credits.

When should you use multiple agents instead of one agent with many topics?

Use a connected agent only when the specialist needs a genuine boundary of its own: a different owning team, a different data or security scope, a different lifecycle, or reuse across multiple orchestrators. If the only motivation is that a single agent’s topic list is getting long, add another topic (subagent) instead. Splitting for size trades a manageable problem for a distributed one with handoffs that can drop context.

---

Designing an agent team — or untangling one that keeps misrouting and dropping context across handoffs? Talk to us. Orchestration architecture that behaves like a single assistant is what we do.