Building Multi-Agent Orchestration: Inter-Agent Communication and Specialized Hand-offs

Orchestrating Multi-Agent Systems in Enterprise CRM

In the evolution of enterprise generative AI, organisations are transitioning from simple, single-prompt conversational bots to complex Multi-Agent Systems (MAS). While a monolithic AI agent—configured with a vast set of system instructions and dozens of tools—initially appears attractive, it quickly degrades under enterprise scale. As the scope of an agent increases, it experiences prompt bloat, causing significant latency spikes, elevated operational token costs, and a high rate of decision hallucinations. To overcome these constraints, modern enterprise architectures decompose complex CRM workflows into networks of small, highly specialized, autonomous agents that collaborate to solve complex business goals. This modular design represents the foundation of scalable, enterprise-grade AI orchestration.

Within a Salesforce CRM context, a multi-agent system divides business functions into logical domains. For example, instead of a single customer service agent attempting to solve support queries, update billing records, qualify new leads, and draft legal contracts, the architecture establishes four specialized worker agents: the Support Worker, the Billing Worker, the Sales Worker, and the Legal Worker. Each agent operates with a highly focused prompt template, a minimal set of custom tools, and strict boundary rules. Because their scopes are narrow, these workers execute tasks with extreme precision, minimal token usage, and very low latency. However, managing this distributed network requires a highly structured orchestration framework that coordinates agent communication, schedules task execution, and manages overall session flow.

A successful multi-agent architecture relies on clear communication protocols. Agents do not communicate using unstructured chat messages; instead, they exchange structured state payloads containing execution parameters, output results, and routing metadata. Standardising these communication channels ensures that agents can pass task control back and forth seamlessly, regardless of whether a worker is hosted natively in Salesforce (using standard Flow and Apex actions) or externally in a private secure enclave. By formalising these organisational boundaries and interaction rules within the Center of Excellence (CoE), the enterprise establishes a scalable blueprint for deploying coordinated multi-agent networks across the entire CRM ecosystem.

The Dispatcher-Worker Hierarchical Orchestration Pattern

To coordinate a network of specialized workers, enterprise architectures leverage the Dispatcher-Worker Hierarchical Orchestration pattern. In this design, a single, central agent—the Dispatcher—serves as the primary point of contact for the user. The Dispatcher does not execute specialized business tasks directly; instead, its primary responsibility is intent analysis, routing, and task scheduling. It acts as an intelligent router, dynamically directing the conversation flow to appropriate worker agents based on the user's current goals.

The sequence of operations is highly structured. When the user submits a query, the Dispatcher analyses the text, identifies the core intent, retrieves the active session state, and selects the optimal worker agent. The Dispatcher then executes a secure hand-off, passing a structured payload (containing relevant context variables) to the targeted worker. The worker agent assumes execution control, invokes its specialized tools (such as executing a case search database query or invoking a billing calculation API), and generates a specialized response. Crucially, once the worker completes its task, it does not respond directly to the user; instead, it passes execution control and its output payload back to the Dispatcher. The Dispatcher reviews the worker's output, determines if additional steps are required (such as invoking a second worker), and synthesises the final response for the user. Below is an architectural representation of this execution sequence:

User ──> [Dispatcher] ──> Hand-off ──> [Billing Worker] (Executes Task)
              ▲                                   │
              │                                   ▼
            Review <─────────────────────── Return Payload

Below is a concrete Apex implementation of a central Dispatcher service that analyses user intent, routes tasks to specialized worker handlers, and coordinates the return payload within the Salesforce CRM runtime:

public with sharing class AgentDispatcherService {
    
    public class DispatchRequest {
        public String userQuery;
        public String sessionId;
        public Map<String, Object> currentSessionState;
    }
    
    public class DispatchResponse {
        public String activeAgent;
        public String agentOutput;
        public Map<String, Object> updatedSessionState;
    }

    /**
     * Entry point for the Dispatcher. Analyses intent and routes execution to workers.
     */
    public static DispatchResponse processUserRequest(DispatchRequest req) {
        DispatchResponse resp = new DispatchResponse();
        Map<String, Object> state = req.currentSessionState != null ? req.currentSessionState : new Map<String, Object>();
        
        // Determine intent using a lightweight model call or regex classifier
        String targetWorker = classifyIntent(req.userQuery);
        state.put('lastRouterIntent', targetWorker);
        
        if (targetWorker == 'BILLING_AGENT') {
            // Hand-off execution to Billing Worker
            resp = invokeBillingWorker(req.userQuery, state);
        } else if (targetWorker == 'SUPPORT_AGENT') {
            // Hand-off execution to Support Worker
            resp = invokeSupportWorker(req.userQuery, state);
        } else {
            // Default response from Dispatcher
            resp.activeAgent = 'DISPATCHER';
            resp.agentOutput = 'How can I assist you today? I can route you to our Billing or Support departments.';
            resp.updatedSessionState = state;
        }
        
        return resp;
    }
    
    private static String classifyIntent(String query) {
        if (String.isBlank(query)) return 'UNKNOWN';
        String lowerQuery = query.toLowerCase();
        if (lowerQuery.contains('invoice') || lowerQuery.contains('bill') || lowerQuery.contains('charge')) {
            return 'BILLING_AGENT';
        }
        if (lowerQuery.contains('error') || lowerQuery.contains('broken') || lowerQuery.contains('support')) {
            return 'SUPPORT_AGENT';
        }
        return 'UNKNOWN';
    }
    
    private static DispatchResponse invokeBillingWorker(String query, Map<String, Object> state) {
        DispatchResponse res = new DispatchResponse();
        res.activeAgent = 'BILLING_AGENT';
        
        // Execute Billing Worker specific business logic (e.g. querying Invoice records)
        List<Invoice__c> activeInvoices = [SELECT Name, Amount__c, Status__c FROM Invoice__c LIMIT 1];
        if (!activeInvoices.isEmpty()) {
            res.agentOutput = 'Your latest invoice ' + activeInvoices[0].Name + ' is ' + activeInvoices[0].Status__c + ' with an amount of £' + activeInvoices[0].Amount__c + '.';
            state.put('lastViewedInvoice', activeInvoices[0].Name);
        } else {
            res.agentOutput = 'I could not locate any active invoices on your account.';
        }
        
        res.updatedSessionState = state;
        return res;
    }
    
    private static DispatchResponse invokeSupportWorker(String query, Map<String, Object> state) {
        DispatchResponse res = new DispatchResponse();
        res.activeAgent = 'SUPPORT_AGENT';
        res.agentOutput = 'Support agent invoked. Processing case database search...';
        state.put('supportIncidentTriggered', true);
        res.updatedSessionState = state;
        return res;
    }
}

Orchestrating Secure Contextual Transfers and Session Persistence

A primary failure point in distributed multi-agent networks is context loss during inter-agent hand-offs. When control is transferred from the Dispatcher to the Support Worker, and subsequently to the Billing Worker, the target agent must receive the precise background information required to perform its task. If the agent receives a blank state, it will be forced to ask the user repetitive questions, resulting in poor customer experience. Conversely, if the system simply passes the entire chat history and every intermediate variable to every agent, the worker's prompt window becomes cluttered, leading to attention fragmentation and severe security risks.

To resolve this challenge, architects must implement Context-Preserving State Objects (a centralized State Store). Under this pattern, session state is managed independently of the individual agents. A persistent state object—represented in Salesforce by custom objects like Agent_Session__c and Agent_Session_Context__c—acts as a secure, structured repository for variables (such as Account ID, verified Contact, active Case number, and user sentiment). When an agent hand-off is initiated, the orchestrator serializes only the relevant subset of these variables and injects them as structured parameters into the target worker's system instructions. This ensures that the worker receives high-fidelity context without inheriting unnecessary conversation noise.

Data security and role-based access controls must also be strictly enforced during contextual transfers. A worker agent must only be provided with context variables that are appropriate for its security clearance. For example, while the Billing Worker requires access to payment tokens or financial histories, the standard Support Worker must be cryptographically blocked from accessing these fields to maintain PCI compliance. The orchestrator enforces this boundary by stripping restricted attributes from the state payload before hand-off, ensuring that sensitive data remains isolated within authorized boundaries. By implementing these secure session persistence layers, organisations can support highly complex, multi-agent workflows while maintaining strict corporate compliance.

Designing Specialized Task Hand-off Protocols and Loop Detection

In a coordinated multi-agent system, the hand-off protocol determines how control is transferred between agents. Enterprise systems leverage explicit hand-off mechanisms, utilizing structured API signals. Instead of allowing an LLM to generate conversational text to announce a transfer, the model is configured to invoke a specific tool, such as a hand-off function, returning a standardised payload (e.g. {"signal": "HANDOFF_TO_BILLING", "parameters": {"accountId": "0018a00001Z9abc"}}). This structured payload is programmatically captured by the orchestrator, which instantly halts execution of the current agent, updates the session state database, and routes the transaction to the targeted worker. This ensures that the transfer is instantaneous, clean, and completely reliable.

However, introducing dynamic, autonomous routing introduces a severe operational hazard: the risk of infinite execution loops. Consider a scenario where the Dispatcher routes a query to the Support Worker. The Support Worker determines that the query requires a billing check and hands control to the Billing Worker. The Billing Worker, encountering a case-related field, immediately hands control back to the Support Worker. Without safeguards, these two agents will route the transaction back and forth infinitely, rapidly consuming API token quotas, exhausting compute budgets, and locking system threads. To prevent this catastrophic failure, the orchestrator must enforce strict loop detection rules.

The loop detection engine operates by maintaining a detailed "hop history" in the session's metadata. Every time execution control is transferred, the orchestrator appends the source agent, target agent, and timestamp to a path array and increments a counter. Before executing any hand-off, the orchestrator validates these logs against two boundary rules: first, the total hop count must not exceed a predefined maximum depth (e.g. max 5 hops per user query); second, the path array is scanned to detect recurring cyclic patterns. If either rule is violated, the hand-off is blocked, a routing exception is thrown, and execution control is immediately reverted to the Dispatcher with an error alert. Below is a structured Apex class illustrating this loop detection and hop tracking logic:

public with sharing class AgentLoopDetector {
    
    public class HandoffException extends Exception {}
    
    private static final Integer MAX_ALLOWED_HOPS = 5;

    /**
     * Validates and logs an inter-agent hand-off.
     * Throws an exception if an infinite execution loop or maximum hop count is exceeded.
     */
    public static void validateAndLogHandoff(String sessionId, String sourceAgent, String targetAgent) {
        // Retrieve current hop history log for the session
        Agent_Session__c session = [
            SELECT Id, Hop_Count__c, Handoff_Path__c 
            FROM Agent_Session__c 
            WHERE Session_Id__c = :sessionId 
            LIMIT 1
        ];
        
        Integer currentHops = session.Hop_Count__c != null ? session.Hop_Count__c.intValue() : 0;
        String pathLog = session.Handoff_Path__c != null ? session.Handoff_Path__c : '';
        
        // Check maximum hop constraint
        if (currentHops >= MAX_ALLOWED_HOPS) {
            throw new HandoffException('Handoff aborted: Maximum hop count of ' + MAX_ALLOWED_HOPS + ' exceeded for session ' + sessionId);
        }
        
        // Construct the new hop log string and check for cyclic loops
        String newHop = sourceAgent + '->' + targetAgent;
        if (pathLog.contains(newHop + ';')) {
            throw new HandoffException('Handoff aborted: Cyclic execution loop detected for session ' + sessionId + ' (' + newHop + ' already executed)');
        }
        
        // Update session tracking variables in the database
        session.Hop_Count__c = currentHops + 1;
        session.Handoff_Path__c = pathLog + newHop + ';';
        update session;
    }
    
    /**
     * Resets the hop tracker variables at the start of a new user query execution.
     */
    public static void resetTracker(String sessionId) {
        List<Agent_Session__c> sessions = [
            SELECT Id, Hop_Count__c, Handoff_Path__c 
            FROM Agent_Session__c 
            WHERE Session_Id__c = :sessionId 
            LIMIT 1
        ];
        if (!sessions.isEmpty()) {
            sessions[0].Hop_Count__c = 0;
            sessions[0].Handoff_Path__c = '';
            update sessions[0];
        }
    }
}

Multi-Agent System Telemetry, Verification, and Scale Testing

Deploying a multi-agent system requires specialized telemetry and verification pipelines. Unlike monolithic systems where we only trace a single model call, MAS requires tracing the complete execution path across the entire agent graph. Telemetry tools must log not only the user input and final output, but also the intermediate routing steps, the variables passed in each hand-off, the tools executed by each worker, and the hop history logs. This detailed tracing is critical for identifying bottlenecks (e.g. which agent has the longest execution time) and debugging routing errors (e.g. why an intent classifier routed a query to the wrong agent).

Before releasing a multi-agent system to production, organisations must conduct rigorous scale testing. MAS architectures are highly susceptible to concurrency issues: when hundreds of users query the system simultaneously, the cascading worker invocations and external API calls can quickly exhaust connection pools and violate model rate limits. Scale testing involves using load-generation tools to simulate peak user volumes, monitoring system latency, CPU utilization, database locks, and token consumption rates. Architects must analyse these metrics to establish queueing rules, implement rate limiting on the AI Gateway, and configure appropriate fallback enclaves (e.g. routing requests to a secondary model if the primary model rate limit is hit).

Below is a comparative analysis designed to guide enterprise architects in selecting the optimal multi-agent orchestration framework based on their specific Salesforce integration and operational requirements: