Multi-Agent Orchestration Is a Delegation Problem, Not a Routing Feature
1. Open on the mechanic, not the release
Multi-Agent Orchestration went generally available on June 15, 2026. Atlas Reasoning Engine 3.0 routes tasks by reading each specialist agent's description rather than following fixed decision trees. That single fact is the whole security story in miniature. Every routing decision in the system runs on natural language that someone in your org wrote, and that someone in your org can edit, likely without anyone else reviewing the change.
Most of what has been published about Multi-Agent Orchestration treats it as a build problem: how to structure a primary agent, how many specialists to stand up, how to sequence a rollout. That is worth knowing. It is not the architecture question. The architecture question is what happens to a decision, a piece of context, or a malicious instruction once it crosses from one agent to another, and who is accountable for the boundary it crossed.
This post is not a walkthrough of how to build a multi-agent system. Salesforce's own documentation and a growing stack of partner guides already cover that ground well. It is an attempt to import what security researchers have already established about multi-agent delegation, agent-to-agent protocols, and shared context, and land it specifically on how Agentforce implements those patterns. Where the platform gives you a governance answer, I will say so. Where it does not, I will say that too, rather than filling the gap with confidence I don't have.
2. What Salesforce actually shipped
Strip away the launch framing and Multi-Agent Orchestration is four mechanics working together.
Description-driven routing. A primary agent serves as the single point of contact and routes each request to the best-fit specialist, so the customer never switches between bots or repeats themselves. The routing decision is not made by a rules engine you configure explicitly. It is made by Atlas reading the metadata you wrote for each specialist and inferring fit.
Shared context across the handoff. The point of the feature, and the mechanic that makes it useful, is that conversation state does not reset when the primary agent delegates. A customer who explains their issue once does not explain it again to the next agent in the chain.
Delegation beyond the platform. Through Agent2Agent (A2A) support, a primary agent can securely connect and delegate tasks to third-party agents, extending coordination beyond Salesforce itself. This is not a hypothetical extension point. It is part of what shipped, though not all of it: the orchestrator core, specialist delegation, Atlas 3.0 routing, and context handoff are GA, while the surrounding ecosystem, including advanced A2A configurations, follows in later releases. Worth keeping in mind when you scope how far to push A2A in production today versus what is still catching up.
Oversight through Observability. Agentforce Observability is positioned as the answer to the coordination this introduces, letting teams monitor performance, trace agent interactions, and enforce security policies across the system. I will come back to what that trace actually contains, and where it stops, later in this post.
Four mechanics, each one a legitimate capability improvement. Each one is also, without any additional configuration on your part, a new place where a decision gets made that a human did not directly make.
3. Three properties that turn benefits into surfaces
Each of the four mechanics above is a real improvement. Each one also does something that the multi-agent security literature has already described as a risk, published well before Salesforce shipped GA. None of what follows is speculative. It is documented research landing on documented product mechanics.
3a. Description-driven routing is a selection surface
Naming and impersonation are established failure modes in agent-to-agent systems. Independent security research on MCP and A2A has found that AI agents rely heavily on names and descriptions to decide which server or peer agent to use, which creates a real vulnerability around naming collisions and impersonation. Palo Alto's analysis of A2A goes further, flagging the risk of malicious content embedded directly in agent metadata compromising downstream agents when input validation on that metadata is weak.
Atlas routes on exactly this kind of metadata. A specialist agent's description is not documentation. It is a live input to a routing decision made at runtime, with no fixed decision tree behind it.
The Salesforce-specific question is who can touch that input, and what happens when they do. The answer is more permissive than most architects would guess. Building and editing an agent, including its description, requires only the Manage AI Agents permission, and because the newer Agentforce Builder sits outside of Setup, an organization can grant that ability to users without giving them any admin-level access at all. That is a deliberate design choice to lower the barrier to building agents. It also means the text that governs delegation across your org can be edited by someone who has never touched a profile, a permission set, or a sandbox refresh.
This is not a story about ungoverned metadata, because the tooling to govern it exists and it improved recently. Spring '26 introduced a metadata structure where agent configuration is authored as a human-readable script file, which lets teams compare readable diffs in pull requests instead of scattered XML, and most CI/CD pipelines only need to track that one bundle type in source control. Everything you would want for a proper review process is available. It is simply not the default path, and the default path is the one Salesforce built to be frictionless.
The deployment decision follows directly: if an org is going to run specialist agents at any scale, agent descriptions belong in the same review pipeline as Apex, using the tooling that already exists for exactly that purpose. The gap is not a missing capability. It is an org that never turned it on.
3b. Shared context is a propagation path by design
The entire value proposition of shared context is that a conversation does not reset when it moves from the primary agent to a specialist. Salesforce is explicit that this continuity is the point: the shared context carries forward with every agent in the chain so that progress is never lost at a handoff.
That mechanism is also, without any modification, a transitive injection channel. The multi-agent security literature has a name for this pattern: transitive prompt injection, where a harmful input introduced at one point spreads through the rest of an interconnected agent workflow. A broader analysis of multi-tool systems describes the same dynamic in infrastructure terms, noting that a single malicious input rarely stays isolated, and instead tends to pollute the shared execution state in a way that propagates across the rest of the chain.
Translate that into an Agentforce scenario. A specialist agent reads an inbound email, a case comment, or a Momentum-captured call transcript, all sources of content your org does not control. If that content contains an instruction and the specialist passes its output into shared context, the primary agent, and every other specialist it subsequently delegates to, inherits it. The lethal trifecta does not need to assemble inside a single agent anymore. It can assemble across two agents that never directly share code, only a context window.
The deployment decision here is about isolation, not detection. Any agent that ingests untrusted external content and any agent that holds a write, export, or send action should not sit in the same delegation chain unless the context passed between them is deliberately filtered rather than passed through whole.
3c. A2A moves work outside the Trust Layer's scope
Everything the Einstein Trust Layer guarantees, masking, grounding, and the promise that prompts and outputs are not retained or learned by the model, is architected around inference that Salesforce itself hosts and mediates. That is a reasonable scope for a trust layer to have when every agent in the system is one Salesforce runs.
A2A breaks that assumption by design, not by accident. The protocol's own security model is built around delegation to an agent whose internals you cannot see: one agent discovers and hands off a subtask to another based on metadata in an Agent Card, and the two collaborate without sharing internal memory or tools. That opacity is a feature of A2A. It is also exactly the property that makes it unclear what a Trust Layer guarantee is supposed to mean once a task crosses that boundary. Separate research on protocol-level threats has already catalogued cross-agent prompt injection as one of the attack vectors specific to the A2A layer, distinct from the injection risks that exist within a single agent.
I want to be precise about what I know here versus what I don't. I have not found a published Salesforce statement that says whether Trust Layer protections extend across an A2A hop, what an external agent receives when your primary agent delegates to it, or whether that hop is even visible in the same terms as an internal one. That may be a documentation gap rather than an architectural one. Either way, it is the single most important question to get answered in writing before A2A touches anything regulated.
Until it is answered, the conservative default for PHI or other regulated data is straightforward: no A2A delegation out of an agent that has access to that data, full stop, regardless of how convenient the third-party specialist looks.
4. What Observability does and does not give you
Give Salesforce credit here before pushing further. Observability is not a thin dashboard bolted onto the side of Multi-Agent Orchestration. The Session Tracing Data Model logs every interaction, including user inputs, agent responses, reasoning steps, LLM calls, and guardrail checks, and stores all of it in Data 360. Separately, Agent Platform Tracing captures every action execution as an OpenTelemetry trace tree, giving a queryable record of every LLM call, flow execution, and Apex invocation in the chain, and the two data models share a trace ID so you can join conversational flow to backend execution in a single query.
That is a genuinely detailed record. For everything that happens inside Salesforce, from the moment a request hits the primary agent to the moment a specialist's Apex action returns, you have the makings of a real incident reconstruction: what was said, which subagent was selected and why, what it did, and how long each step took.
The question worth asking is not whether that trace is detailed enough. It is where the trace stops. Section 3c raised the open question of what a Trust Layer guarantee means once a task crosses an A2A boundary to an agent Salesforce does not run. The same question applies to the trace. Does Agent Platform Tracing follow a delegated task across that hop, or does the tree simply end at the point of handoff, with whatever the external agent does next invisible to the org that initiated it? I have not found documentation that answers this directly, and I would treat the absence of an answer as the default assumption until an architect confirms otherwise in their own org: verify, in a sandbox, whether an A2A delegation produces a visible child span or a dead end.
If it is a dead end, that is not necessarily a defect. It may simply be an honest boundary, since Salesforce cannot instrument code it does not run. But an honest boundary still needs to be treated as one. An incident that crosses into a third-party agent and back is not something your Observability dashboard will show you in full, and knowing that in advance changes how much you should trust A2A with anything you would need to explain to an auditor later.
5. Deployment decisions
The point of walking through the mechanics is to end up with something an architect can act on, not just a longer list of concerns. Eight decisions, each one tied directly back to a specific mechanic from the sections above.
6. Close
The job changed more than the feature list suggests. Delegation used to be something an architect designed explicitly, in code, with a call signature that said exactly what was being handed to what. Multi-Agent Orchestration turns that same decision into something a reasoning engine performs at runtime, based on prose that may have been written by someone with no admin access, reviewed by no one, and never source-controlled.
None of that makes the feature unsafe to use. It makes the review discipline portable. The controls that used to live in code review now need to live wherever the routing decision actually gets made, which for most orgs today is a text box in a builder outside of Setup. That is a smaller change to describe than it is to operationalize, which is exactly why it is worth doing before the next specialist agent goes live rather than after an incident makes the question urgent.
If you are running Multi-Agent Orchestration or planning to, the fastest way to find out where you stand is not to read further about it. It is to open a sandbox, write two agent descriptions that overlap on purpose, and watch what Atlas does with them.
Sources credited
Palo Alto Networks (A2A protocol risks, Agent Card context poisoning), Solo.io (naming and impersonation attacks across MCP and A2A), the MAESTRO threat-modeling authors Narajala, Habler, Huang, and Kulkarni (A2A security analysis), the multi-tool orchestration security survey on state pollution and cascading propagation, the LLM-agent protocol threat survey on transitive and cross-agent prompt injection, Salesforce Developers Blog (Agentforce metadata lifecycle, Agent Platform Tracing), and Salesforce's own Session Tracing Data Model and Einstein Trust Layer documentation.