Multi-agent orchestratie op Salesforce: wat overdrachten tussen agents in productie laat werken

Het korte antwoord: multi-agent orchestratie op Salesforce betekent dat een orchestrator-agent het gesprek voert en elke taak doorgeeft aan een specialistische agent met een strak afgebakend domein. Wat het betrouwbaar maakt in productie is geen grotere prompt op de orchestrator, maar een strak overdrachtscontract tussen agents: wat er meegaat, wat er terugkomt, en wie mag handelen. Salesforce maakte Agentforce multi-agent orchestratie algemeen beschikbaar op 15 juni 2026, en het Agent2Agent-protocol (A2A) trekt hetzelfde patroon door naar agents die niet op Salesforce draaien.

Wat is multi-agent orchestratie op Salesforce?

Het is een routeringsarchitectuur. Eén primaire agent is het enige aanspreekpunt van de gebruiker en bewaart de sessiecontext. Daarachter staan specialistische agents, elk met een afgebakend domein en een eigen set acties: Apex, Flow, prompt templates, externe API's.

De routering is geen beslisboom. De Atlas Reasoning Engine leest van elke geregistreerde agent de beschrijving, de instructies en de beschikbare acties, en kiest tijdens runtime de beste match. Dat heeft een gevolg dat teams onderschatten: een agentbeschrijving is routeringslogica, geen documentatie. Vage beschrijvingen leveren vage routering op.

Waarom houdt één grote prompt op te werken?

Bijna elk team probeert eerst de variant met één agent. Die demonstreert prima en zakt in productie in, om redenen die structureel zijn en niet weg te patchen:

• Verwatering van instructies. Regels die in de ene workflow gelden lekken naar de andere, en het model middelt ze uit.
• Wildgroei aan tools. Voorbij ruwweg een dozijn acties daalt de selectienauwkeurigheid en gaat het verkeerde tool af.
• Geen blast radius. Eén agent met restitutierechten heeft die rechten in elk gesprek dat hij ooit voert.
• Niet-testbare wijzigingen. Een nieuwe alinea over retouren kan stilletjes het gedrag rond garantie veranderen, en er valt niets te unit testen.

Een specialist met één taak en vijf acties heeft die problemen niet. De complexiteit verdwijnt niet, maar verhuist naar de naden tussen agents. Daar hoort ze thuis, want een naad kun je specificeren.

Hoe ziet een orchestrator met specialisten er in productie uit?

1. Een orchestrator die intentie bepaalt, context vasthoudt en escaleert. Hij heeft zelf geen enkele businessactie.
2. Eén specialist per afgebakend domein, bijvoorbeeld rechtencontrole, veldplanning of factuurcorrecties, elk met een eigen set acties en eigen testgevallen.
3. Een gestructureerde contextpayload die tussen hen wordt doorgegeven, geen vrije tekst.
4. Een menselijke goedkeuringsstap op alles wat onomkeerbaar of financieel is.
5. Tracing op elke overdracht, zodat een slechte uitkomst toe te wijzen is aan één agent en niet aan "de AI".

Schaal is de reden dat dit telt. In ons ASSA ABLOY-programma (FocusCura en Phoniro) beslaat het operationele oppervlak 11.000 verbonden apparaten die tot 2,5 miljoen events per week produceren in drie markten, en daalden de wekelijkse cases van 3.000 naar 350 zonder extra supportmedewerkers. Zo'n operationele belasting past niemand in één prompt.

Wat maakt een overdracht tussen agents betrouwbaar?

Dit is het deel dat leveranciersmateriaal overslaat, en precies daar breken productiesystemen. Behandel elke overdracht als een interface, niet als een gesprek.

• Getypeerd erin, getypeerd eruit. Kun je de overdracht niet opschrijven als een functiesignatuur, dan verzint de orchestrator er zelf een, en morgen een andere.
• Geef identifiers door, geen proza. Een CaseId en een AssetId overleven een overdracht. Een geparafraseerde samenvatting niet.
• Geef de specialist een manier om te weigeren. "Ik kan niet verder, het recht is verlopen" is een routeerbaar antwoord. Stille improvisatie niet.
• Maak acties idempotent. Orchestrators doen retries. Een retry mag nooit een tweede restitutie uitvoeren.
• Versioneer de beschrijvingen. Routering hangt ervan af, dus een beschrijving aanpassen is een productiewijziging en hoort in review.

De naad is het product. Agents zijn het makkelijke deel; het contract ertussen is het echte engineeringwerk.

Waar passen A2A en MCP nu echt?

A2A regelt delegatie over platformen heen. Een agent publiceert een agent card die beschrijft wat hij kan; een client-agent vindt die, delegeert een taak en krijgt berichten en artefacten terug. Zo bereikt een Agentforce-orchestrator een specialist die ergens anders draait.

MCP is de andere as. Het geeft één agent toegang tot tools en data. Wij bouwen MCP-servers zodat één agent kan handelen in de systemen die een bedrijf al draait, in plaats van elke actie via een CRM-scherm te dwingen.

Vuistregel: A2A is agent naar agent, MCP is agent naar systeem. De verkeerde kiezen is de architectuurfout die we het vaakst zien.

Hoe rol je dit uit zonder de naden te breken?

1. Begin met drie agents op één workflow waar de data al schoon is. Agents bovenop rommelige data vermenigvuldigen de rommel.
2. Meet voordat je opschaalt. Kun je vandaag niet één overdracht traceren, dan debug je volgend kwartaal geen tien agents.
3. Geef elke specialist een eigenaar met naam en toenaam.
4. Test routering adversarieel, met dubbelzinnige verzoeken en meerdere intenties, niet met het gelukkige pad.
5. Houd per specialist een noodstop, zodat één slechte agent niet de hele workflow platlegt.

FAQ

Is multi-agent orchestratie vandaag beschikbaar in productie op Salesforce?

Ja. Salesforce maakte Agentforce multi-agent orchestratie algemeen beschikbaar op 15 juni 2026, met A2A-ondersteuning voor agents buiten het platform.

Met hoeveel specialistische agents beginnen we?

Drie, op één workflow. Bewijs eerst de overdrachten en de tracing, voeg daarna domein voor domein toe.

Maakt een groter model orchestratie overbodig?

Nee. Een sterker model verbetert het redeneren binnen een agent. Het levert geen afgebakende rechten, geen tests per domein en geen toewijsbare fout op. Die komen uit de architectuur.

Wat gaat er in productie het vaakst mis?

Overdrachten. Context die tussen agents verdwijnt, misroutering door een vage agentbeschrijving, en retries die een actie herhalen die nooit idempotent was.

Moeten we agents op andere platformen opnieuw bouwen?

Nee. Met A2A kan een Agentforce-orchestrator delegeren aan agents van derden, zodat een specialist buiten Salesforce meedraait in dezelfde workflow.

Tekunda bouwt multi-agent systemen op Salesforce en daarbuiten, inclusief agent-naar-agent orchestratie die in productie draait. Ga je van één agent naar een team, ontwerp dan eerst de naden.