Building a single AI chatbot is relatively straightforward. You give an LLM a system prompt, connect it to a search API, and let it answer user queries. But in an enterprise environment, business processes are rarely single-step operations. They are complex, cross-functional, and require multiple kinds of expertise.
For complex tasks, a single monolithic agent quickly breaks down. Its prompt becomes too long, it loses track of context, and it struggles to choose from dozens of available tools.
Enter multi-agent architectures.
A multi-agent system divides a complex workflow into smaller, specialized agents. Each agent has a focused role, a narrow set of tools, and isolated context. These agents then collaborate, handing off tasks to one another until the entire process is complete.
In Salesforce, this approach maps naturally because your data, processes, and integrations are already modular. Agents can mirror your existing business domains. Here is a practical blueprint for designing and orchestrating multi-agent systems in a Salesforce environment.
To understand how this works in practice, let us look at an automated end-to-end lead qualification and account setup workflow. The process is triggered when a new Enterprise lead submits a form on a website specifying their budget and timeline.
Instead of asking one massive agent to handle this entire sequence, we delegate it to four specialized agents:
Lead_Score__c and ICP_Tier__c back to the Lead record. If the score is higher than 80, it converts the Lead to an Account and Contact and triggers the next agent. If not, it routes the lead to a marketing nurture campaign.For a multi-agent system to work, you need an orchestrator to manage state and context. The orchestrator is responsible for taking the output of one agent, deciding who should work on the next step, and passing the relevant context.
In Salesforce-native terms, this could be Agentforce, where handoffs are managed dynamically by a reasoning engine. In external architectures, it might be a tool like n8n, LangGraph, or Flowise, which orchestrates the execution flow by calling Salesforce APIs between agent transitions.
When building these workflows, you can leverage native Salesforce features to make your multi-agent architecture more secure, modular, and maintainable.
Instead of hardcoding synchronous calls between agents, use Platform Events. When the Research Agent finishes enriching a lead, it publishes a Lead_Enriched__e event. The Scoring Agent listens for this event and executes. This loose coupling makes it easy to add or swap agents in the future without breaking the overall system.
Keep your agent configurations out of Apex code. Store system prompts, model selections (e.g., GPT-4o, Claude 3.5 Sonnet), temperature parameters, and enabled tools in Custom Metadata Types (CMDT). This allows admins and architects to tune agent behavior on the fly without running a full deployment.
<!-- Example CMDT Structure -->
<AgentConfig>
<MasterLabel>Lead Research Agent</MasterLabel>
<LLMModel>claude-3-5-sonnet</LLMModel>
<Temperature>0.2</Temperature>
<EnabledTools>WebSearch, ClearbitAPI</EnabledTools>
</AgentConfig>
Agents need to talk to third-party services. Rather than managing API keys in code or prompts, leverage Salesforce Named Credentials. This offloads token management and authentication to the Salesforce platform, ensuring your agents access external tools securely.
To let agents read and write Salesforce data, expose Apex classes as tools using the @InvocableMethod annotation. Write helper classes that enforce strict governor limits and object-level security.
public class SalesforceAgentTools {
@InvocableMethod(label='Query Account History' description='Retrieves closed-won opportunities for ICP scoring')
public static List<Opportunity> getAccountHistory(List<Id> accountIds) {
// Run secure, governor-limit-aware query
return [SELECT Id, Amount, StageName FROM Opportunity WHERE AccountId IN :accountIds AND StageName = 'Closed Won'];
}
}
Salesforce's Agentforce platform (available starting Winter '25) provides a native environment to run these multi-agent workflows. Instead of writing custom API routing code, Agentforce uses:
To build a multi-agent system in Agentforce, you configure separate agent topics and use Handoff Actions to route control between them when a topic boundary is crossed.
Before building a multi-agent system, there are three architectural decisions you must make. The following flowchart guides you through the optimal choice at each decision point:
Decide where your agents and coordination logic should live.
Determine how control and data flow between individual agents in the system.
Lead_Enriched__e) when their work is complete, and downstream agents trigger asynchronously. This pattern is ideal for long-running, back-office workflows, ensuring resilience against governor limits and API rate caps.Establish how you will track agent actions, decisions, and tool usage history.
Agent_Run__c): Persists the input, output, token count, and API payload of every tool execution to a custom record in Salesforce. This is crucial for compliance, audit trails, and debug logging in enterprise settings.The key to succeeding with multi-agent workflows in Salesforce is to start small. Do not try to automate your entire lead-to-cash process on day one.
Select a single, narrow, high-volume process—like Permitting Lookups, FAQ Routing, or Lead Enrichment. Build a dedicated agent, define its tools, and log its performance in a custom Agent_Run__c object. Once you have validated the reliability of that agent, spawn your second, introduce a handoff, and expand.
By building modularly, you align your AI architecture with Salesforce best practices, resulting in a system that is robust, explainable, and easy to maintain.
Burning tokens isn't a productivity metric, it's a cost center. Here's how the frugal AI shift translates into concrete architecture decisions on Salesforce projects.
If your architecture only lives inside the Salesforce landscape, your role is shrinking. Here is why modern architects must master enterprise patterns outside the CRM sandbox.
Hooks let you enforce behavior in Claude Code instead of hoping the model does the right thing. The mental model, three Salesforce-specific hooks, and why this matters more in Salesforce than in most stacks.