According to a publication by Salesforce's Agentforce team, multi-agent orchestration is now generally available, against the backdrop of performance limits that emerge when a single agent attempts to manage too broad a range of capabilities. The publication explains that most Agentforce deployments begin similarly: a single agent takes on one job, such as order lookups and answering status questions. When it performs that job well, additional capabilities are layered on over time, such as returns, product recommendations, and loyalty management. However, when an agent's capabilities grow beyond a certain threshold, its reasoning process begins to break down and results deteriorate.
According to the article, multi-agent orchestration is defined as the coordinated collaboration of two or more specialized AI agents to complete tasks that no single agent could handle well alone. While not every deployment needs multiple agents, this is the pattern many teams turn to when their first agent begins to experience strain. The team detailed three signs indicating that a single agent is no longer sufficient, along with four architectural paths from the company's new Architect's Guide to Agentforce Interoperability.
Sign 1: The agent is trying to do too much at once
According to the publication, as subagents and actions are added to handle more use cases, two processes begin to occur:
First, the agent's context window fills up with instructions, outputs, and conversation history. As a result, the reasoning engine starts ignoring core rules, mixing up different topics, or applying incorrect logic to the wrong request. This phenomenon is defined as intent collision, and it is experienced as performance regression: behavior that was reliable the previous month becomes inconsistent in the current month, with no single change explaining it. The article compares this to having 30 or more tabs open in a browser, where finding the needed tab takes longer and wrong tabs are opened along the way.
Second, the description block used by the reasoning engine to route requests keeps expanding. As it grows, the router hesitates more or misroutes requests—such as a billing question landing in returns, or a technical request ending up in sales. In this state, the description is performing work that should be handled at the architectural design level, and description-tuning cannot resolve the underlying root cause. The proposed solution is splitting an overloaded agent into multiple specialized agents: a superagent that routes to scoped connected subagents, providing each agent with a smaller instruction set, cleaner context, and a clearer routing signal.
Sign 2: Data lives in places the agent cannot reach
According to the article, a single Agentforce agent operates within a specific Salesforce org. If a workflow depends on data, permissions, or systems located elsewhere, a single agent hits a boundary it cannot bypass through prompt design. Addressing this problem requires an architectural change tailored to the direction work needs to move:
- Accessing external tools: When Agentforce needs to reach an external system or tool such as Jira, Box, or a database, an MCP Client component allows it to use that capability as a tool while remaining the central orchestrator.
- Handing off tasks to an external agent: When Agentforce needs to hand off a task to an external agent, such as a Google or AWS agent that owns part of the reasoning process, an Outbound A2A mechanism allows delegating authority to a third-party agent.
- Invocation from an external system: When an external system such as a custom portal or Microsoft Copilot needs to trigger execution inside Salesforce, Inbound A2A mechanisms or deploying Agentforce as an MCP Server allow external platforms to leverage Agentforce capabilities without rebuilding them.
Sign 3: Different teams need to manage different parts of the agent
When a single agent is handed over for company-wide use, different departments require independent modifications: Legal seeks to update policy logic, Finance needs to alter approval rules, and Marketing wants to tune recommendation flows. In such a scenario, every update turns into a negotiation over a shared instruction block, teams cannot operate independently, and innovation bottlenecks at whoever owns the single agent's configuration. Multi-agent orchestration allows each department to build and test its own agent independently without disrupting the existing customer-facing experience, subsequently connecting it to the superagent on that department's own schedule.
Four architectural paths and readiness questions
The company's guide details seven interoperability scenarios, highlighting four common paths for transitioning from a single agent:
- Staying with a single agent: A valid and likely the most efficient architecture when the workflow lives entirely within a Salesforce org, uses a single data model, maintains a limited number of subagents, and delivers quality results.
- Internal multi-agent orchestration: Suitable when the problem spans multiple lines of business (such as billing, support, and refunds) while data, permissions, and users all reside within a Salesforce instance, or when a single agent grows past seven subagents and its results begin to deteriorate.
- Third-party multi-agent orchestration (A2A): Suitable when Agentforce needs to collaborate with an external agent that manages part of the reasoning or workflow.
- MCP connection to external tools: Suitable when Agentforce remains the governing entity but needs to access an external tool, API, or workflow.
Before transitioning to a new architecture, the publication recommends evaluating several questions:
- Number of connected subagents: Company internal testing found that intent collision and result deterioration most commonly occur when more than seven subagents are connected to a single agent.
- Use of different models and settings: In a multi-agent architecture, each agent can have its own routing settings and creativity level (via temperature), using complex models for high-value tasks or cheaper, faster models for low-priority tasks.
- Control by business units (lines of business).
- Data model consistency: When customer IDs, product SKUs, or case records do not match precisely across systems, the output of one agent becomes guesswork for the other.