Choosing the best Multi-Agent Architecture in Salesforce

Introduction: Start Smaller Than You Think

The first time I configured the Atlas Reasoning Engine within Salesforce, I fell into a common trap. I tried to build a “god agent.” I threw every Flow, Apex class, and knowledge article into a single Topic, assuming the LLM would figure it out. It didn’t. The agent hallucinated, looped endlessly, or simply refused to act because the context was too excessive.

This is the reality of agentic AI. It behaves less like a chatbot and more like an operational system. When we treat agentic it like a distributed system, where distinct agents handle distinct domains, it scales wonderfully.

Most tasks do not need multiple agents. A single agent with well-defined Actions is easier to ship. Complex multi-agent systems earn their place only when real constraints like context limits or organizational silos appear.

When Single-Agent Systems Break Down

In the Agentforce ecosystem, a single agent typically refers to an agent operating within a single Topic or a specific scope of work like Order Management or IT Support. These systems can break down because capabilities can sprawl faster than the reasoning engine can absorb.

Two constraints consistently surface:

1. Context Pressure: If you give an agent 50 different Actions (Flows, Apex calls) to choose from, you dilute its ability to pick the right one. The Atlas Reasoning Engine needs focused intent to function reliably.
2. Distributed Ownership: If the Sales Ops team owns the Lead Qualification Flow and the Support team owns the Ticket Resolution Flow, packing them into one monolithic instruction set creates a governance nightmare.

These are organizational limits. When you hit them, you need a new architecture.

Why Multi-Agent Systems Can Outperform at Scale

In Agentforce, multi-agent architecture is realized through Topics. You might have one top-level Service Agent that routes between a Returns Topic, a Billing Topic, and a Technical Triage Topic.

This structure works because it enforces parallel reasoning through isolated context windows. When the agent switches to the Billing Topic, it unloads the instructions for Technical Triage. By doing so, it no longer knows how to debug a router, which means it cannot accidentally hallucinate a router debug step while processing a refund.

Clear separation of responsibility leads to less cognitive overload per agent.

A Practical View of Multi-Agent Architectures

Most real systems fall into four patterns. Each solves a different coordination problem. In Agentforce these patterns are implemented by how you configure Topics and the Router.

Subagents: Centralized Orchestration

This is the standard Agentforce model. You have one supervisor (the Router) that listens to the user and delegates execution to a specialized Topic (the Subagent).

• How it works: The Router is stateless. It only classifies intent. Once it detects “I need to return this” it hands off control to the Returns Topic, which has its own specific instructions and Actions.
• Best for: Multiple distinct domains (e.g., Sales vs. Service) within one interface.
• Tradeoff: Requires careful tuning of Topic Descriptions to prevent routing conflicts.

Skills: Progressive Disclosure

Instead of creating a new agent for every small task, you give a single Topic multiple Skills or Actions.

• How it works: A Customer Service Topic might have actions for Get_Order_Status, Cancel_Order, and Update_Address. The agent loads these capabilities on demand based on the user’s request.
• Best for: Rapid iteration with shared ownership.
• Tradeoff: If a Topic accumulates too many Skills, accuracy drops.

Handoffs: State-Driven Transitions

Agentforce equivalent: Explicit instruction-based topic switching.

Sometimes, an agent must change roles mid-conversation. This is a state-driven transition.

• How it works: A Lead Gen Topic captures prospect data. Once the lead is Qualified, the instructions explicitly state, “If lead score > 50, switch to the Booking Topic.” The Atlas engine carries the context into the new Topic.
• Best for: Intake, qualification, and resolution flows.
• Tradeoff: Stateful systems are harder to debug because you must track when the switch happened and what data was preserved.

Routers: Parallel Dispatch and Synthesis

This pattern is often invisible in Agentforce because the platform handles it. The engine evaluates the user’s utterance against all available Topics simultaneously to find the best match.

• Best for: Knowledge-heavy queries where the user might ask about anything from Pricing to API Documentation.
• Tradeoff: If Topic scopes overlap (e.g., Billing vs. Payments), the Router will thrash or ask clarifying questions repeatedly.

Figure 1: Comparison of Agent Patterns in Agentforce

Matching Architecture to Real Constraints

Before choosing a pattern, answer four questions. Your answers will dictate your Agentforce configuration.

1. How many distinct domains are involved? If it’s just IT Support, use one Topic with multiple Actions (Skills). If it’s IT Support and HR Benefits, use two Topics (Subagents).
2. Does work happen in parallel or sequence? If the user needs to jump between checking PTO and resetting a password randomly, you need a Router pattern. If they must diagnose before ordering a part, use a Handoff.
3. Does state need to persist across turns? If yes, ensure your data model (Data Cloud or CRM records) is updated immediately by Actions so the next agent can read the fresh state.
4. Who owns and maintains each capability? Conway’s Law applies here. If two different teams manage the logic, split them into two Topics.

Architecture is a response to constraints, not a preference.

Observability and Escalation Are Part of the Architecture

As agents multiply, visibility matters more than cleverness. In Agentforce this is handled via the Reasoning Trace in the Agent Builder.

At minimum, you should be able to:

• Trace which agent acted and why: Did the Router pick the Sales Topic because of a keyword, or did it default there? The Reasoning Trace shows the Thought process step-by-step.
• Inspect intermediate decisions: If the agent ran a Flow but didn’t return the result to the user, you need to see the Flow’s output variables in the trace.
• Escalate when confidence drops: Your architecture must include a fail-safe Topic or instruction. If the Atlas engine loops more than 3 times, it should seamlessly hand off to a human agent or a default search.

Agents that defer appropriately build more trust than agents that guess.

Performance Isn’t Just Latency

Architecture choices shape cost and stability.

• Cost per request: Every time your agent thinks, it consumes tokens. A single monolithic agent with 50 instructions consumes more tokens per turn than a modular agent that only loads 5 instructions.
• Token usage over time: Specialized Topics keep the context window small, reducing costs.
• Predictability: It is easier to write regression tests for a Returns Topic than for a General Purpose Bot.

Parallel systems win on complex queries, stateful systems win on repeat interactions. There is no free lunch.

Getting Started Without Overcommitting

Start with a single agent (Topic). Add tools (Actions) before adding new agents. Introduce multiple agents (Topics) only when constraints force the issue.

Most teams add agents too early. They build a Sales Agent and a Service Agent before they even have a working Lookup Contact action.

Conclusion: Multi-Agent Design Is a Discipline

Multi-agent systems succeed through discipline. Architecture should mirror real work as it exists today. If a single agent can do the job reliably, that is the correct solution. Complexity carries a real cost, and it should be introduced only when it clearly buys clarity or reliability.