Salesforce’s Summer ’26 release made multi-agent orchestration a headline feature. Agentforce can now coordinate a team of specialised agents across Slack, Teams and the service desk, with shared context that follows a conversation from one agent to the next. The technology is genuinely interesting. The harder question, the one most enterprise buyers are not yet asking, is what happens at the seams between agents, and who owns the workflow when something goes wrong.
The Connectivity Report Salesforce published earlier this year put the gap into focus. Organisations already average twelve agents in production, and that number is forecast to climb sixty-seven percent by 2027. Roughly half of those agents currently operate in silos, disconnected from anything else. Multi-agent orchestration is the proposed cure for that silo problem. It also introduces a new problem, which is the one worth talking about today.
What is Salesforce Agentforce multi-agent orchestration?
Agentforce multi-agent orchestration is the capability, generally available with the Summer ’26 release, to deploy a team of specialised AI agents that coordinate through a primary orchestrator agent. The orchestrator interprets the user’s request, routes work to specialist agents that own a domain or data source, and holds the shared context so the user does not need to repeat themself. Atlas Reasoning Engine 3.0 sits underneath the orchestration, and the agents communicate through Model Context Protocol (MCP) and Agent2Agent (A2A) standards. The practical effect is that a customer service conversation might involve a triage agent, a billing agent and an entitlements agent, but the customer sees one conversation.
That description sounds tidy on a marketing slide. In practice, the architecture introduces dependencies that are unfamiliar to most CRM administrators. The orchestrator becomes a single point of judgement. The specialist agents become a fleet to govern. The shared context becomes a piece of infrastructure that has to be observable, debuggable and reliable. None of those things show up in the Trailhead diagrams, and none of them are optional once the workflow goes to production.
Why does adding more agents make the workflow harder, not easier?
The intuition that more agents equal more capacity is partly correct. Each specialist agent can in principle handle the work that one human would have batch-processed in a queue. The intuition that more agents equal a smoother process is wrong. Every handoff between agents is a seam, and every seam is a place where context can be lost, intent can be misread, or a downstream system can drift out of sync with what the orchestrator believes is true.
In single-agent Agentforce deployments, the agent owns the entire interaction. If the agent is wrong, the place to look is obvious. In a multi-agent deployment, a failed customer outcome could mean the orchestrator routed to the wrong specialist, the specialist made the right decision on stale data, or the handoff back to the orchestrator lost a key piece of context. Three agents in a workflow do not produce three times the debugging surface. They produce something closer to nine.
This is not a reason to avoid multi-agent designs. It is a reason to design them with a clear theory of where the seams sit, what each seam needs to carry, and which human or system is accountable when a seam tears.
How does CRM technical debt distort agent behaviour?
CRM technical debt is the accumulated weight of fields, rules, automations and integrations that an organisation has built up over years and no longer fully understands. In a human-driven CRM, technical debt is annoying but containable. Users learn to work around the obsolete required field, the routing rule that fires on the wrong condition, the duplicate that everyone knows is the canonical record. Agents do not work around. They read the rules and execute them at scale.
When multi-agent orchestration meets a CRM with significant technical debt, the result is predictable and uncomfortable. The lead-routing agent inherits the assignment rule written for a sales team that no longer exists. The entitlements agent honours an entitlement that was supposed to be retired last year. The forecasting agent picks up a custom field that was repurposed three times. None of these are bugs in Agentforce. They are bugs in the foundation that Agentforce now executes faithfully, hundreds of times an hour, with full audit logs that show every faithful execution.
A pre-orchestration data and process audit is not an optional first step. It is the cheapest piece of insurance available, and most buyers are skipping it because the licence purchase has already been signed.
Who is accountable when five agents fail across three systems?
This is the governance question that the Summer ’26 marketing does not answer cleanly. Salesforce ships Agentforce Command Centre, which gives administrators live dashboards, action-level logs and performance metrics for every agent in the fleet. That is genuine visibility, and it is necessary. It is not the same as accountability.
Accountability in a multi-agent context has three components. First, there must be an owner for each specialist agent, the person or team responsible for the data, the prompts and the actions that agent takes. Second, there must be an owner for the orchestration layer itself, the person responsible for how work is routed and how shared context is carried between specialists. Third, there must be a clear escalation path that includes a human in the loop on workflows where the consequence of failure is material. Most enterprise change-control frameworks assume a single accountable owner per process. Multi-agent orchestration breaks that assumption, and the operating model needs to be rewritten to match.
This is not a technical problem. It is an organisational design problem with technical consequences. The teams that have moved fastest on Agentforce have also been the most likely to find themselves with no clear answer when a regulator, an auditor or an unhappy customer asks who decided what.
How should an organisation prepare its data and integration layer for multi-agent orchestration?
The Connectivity Report is unambiguous on this point. Ninety-six percent of IT leaders surveyed told Salesforce that AI agent success depends on integration across systems, and that API-driven architectures are the way to prevent fragmented infrastructure from stalling the rollout. The interpretation that matters for buyers is sharper than the report’s headline. Multi-agent orchestration only works if the underlying data layer behaves like a single source of truth, even when it is composed of many systems.
Practically, that means three things. A semantic layer that gives agents a consistent vocabulary for the customer, the product, the contract and the entitlement, regardless of which system stores the underlying record. MCP-compliant connectors for every system the agents need to read from or write into, so that the orchestration does not depend on bespoke API contracts that go stale at the next upgrade. And a clear ownership model for the data itself, so that when an agent reads a stale value, somebody specific can be told and the value can be corrected at source.
This is the unglamorous work. It is also the work that decides whether your multi-agent pilot survives first contact with production traffic.
What does a credible Agentforce multi-agent pilot look like in 2026?
A credible pilot in 2026 is narrow, instrumented, and honest about what it does not know. Scope a single cross-functional workflow with no more than three specialist agents and one orchestrator. Pick a workflow where the time-to-resolution matters and the cost of a wrong answer is recoverable. Customer service triage, internal IT request routing, and renewals quoting tend to satisfy both conditions. Greenfield revenue forecasting and external pricing decisions tend not to.
Instrument the pilot with Atlas Reasoning logs, Command Centre dashboards, and at least one human reviewer who is empowered to interrupt the workflow. Measure two metrics that teams often skip. The first is time-to-resolution including any human handoffs, which tells you whether the pilot is actually faster than the status quo. The second is the rate at which an agent escalates back to a human because it cannot resolve the request with confidence, which tells you whether the pilot is being honest about its own limits. A pilot with a zero escalation rate is not a successful pilot. It is an uninstrumented pilot.
Expand only after both metrics have been stable for at least a full quarter. The temptation to add a fourth and fifth specialist agent is strong, especially after a board demo goes well. Resist it until the seam behaviour of the first three is fully understood, including how the orchestrator behaves when one specialist returns a low-confidence answer and another returns a high-confidence answer that contradicts it.
The Sirocco perspective
We do not think multi-agent orchestration will collapse the way RPA did a decade ago. The platform genuinely works, the underlying language models are good enough for production workflows, and the Connectivity Report figures are consistent with what we see in our clients’ environments. Our concern is that the spend pattern is unbalanced. Buyers are committing six and seven figure budgets to Agentforce licensing and implementation, then declining to invest five figures in the data quality, integration governance and accountability model that determine whether the orchestration actually produces a return.
Our advice to clients in active Agentforce evaluations is consistent. Do the unglamorous foundational work first. Define the seams in your workflows before you let agents stitch across them. Make the accountability model explicit before the first specialist agent enters production. Multi-agent orchestration rewards organisations that have already invested in clarity, and it punishes organisations that have not. The platform amplifies whatever discipline, or whatever debt, sits underneath it.
If you are evaluating Agentforce multi-agent orchestration this year, or your existing rollout is producing results that are harder to debug than you expected, we would be glad to walk through the diagnostic with you. Schedule a consultation and we will share the seam-mapping framework we use with clients in the first session.
Get in Touch
If you are scoping a multi-agent Agentforce rollout, or already living with an orchestration that is proving harder to govern than the marketing suggested, tell us where it hurts and we will map the seams and the accountability gaps with you.
