Multi-agentsystemen: wanneer een tweede agent nuttig is en wat het kost om ermee te werken

Een multi-agentsysteem bestaat uit meerdere AI agents die aan één opdracht werken en het werk aan elkaar overdragen. Elke agent heeft eigen instructies, eigen tools en een eigen taak. Een overkoepelend onderdeel bepaalt welke agent vervolgens aan de beurt is. Dat is het hele idee. De uitdaging zit niet in de architectuur, maar in het beheer. Meerdere agents nemen meerdere beslissingen, en toch moet u één volledig overzicht kunnen geven van wat er is gebeurd.

De meeste artikelen over dit onderwerp richten zich op engineers die deze aanpak ontwikkelen. Dit artikel is bestemd voor degene die het systeem moet beheren. We zullen een uitgewerkt voorbeeld bekijken uit de bedrijfsvoering, wanneer een tweede agent meerwaarde biedt en wanneer niet, en wat u van de runtime moet eisen voordat u het systeem met echt werk laat omgaan.

Eén agent bestaat uit een model, een set tools en een uitvoeringslus die doorgaat totdat de taak is voltooid of een limiet de uitvoering stopt. Een multi-agentsysteem bestaat uit meerdere van zulke agents, met één extra beslissing: wie krijgt het werk vervolgens toegewezen? Platforms nemen die beslissing op drie manieren. Het is belangrijk dat u weet welke aanpak u kiest.

Een vaste route. U bepaalt vooraf de volgorde: eerst deze agent, dan die, vervolgens de volgende. Het model kiest nog steeds hoe het elke stap uitvoert, maar niet welke agent aan de beurt is.

Een manager agent. Eén agent beoordeelt de opdracht en verdeelt het werk over de andere agents. De route wordt tijdens de uitvoering bepaald.

Een keten van overdrachten. Elke agent rondt zijn deel af en wijst de volgende agent aan. Er is geen centraal overzicht; de route ontstaat tijdens de uitvoering.

Het verschil zit in één eigenschap: hoeveel van de route al vastligt voordat de run begint. Een vaste route is voorspelbaar, goed te testen en misschien weinig spannend. Dat zijn drie manieren om hetzelfde voordeel te beschrijven. Een manager agent kan omgaan met situaties waarmee vooraf geen rekening is gehouden, maar het is lastiger uit te leggen waarom het systeem een bepaalde taak op een bepaalde manier heeft uitgevoerd.

Neem een financieel operationeel team dat leveranciersfacturen vergelijkt met inkooporders. De meeste facturen komen overeen en worden zonder menselijke tussenkomst geboekt. De rest komt in een wachtrij voor uitzonderingen terecht. Denk aan een onjuiste btw-code, een levering die over twee leveringsbonnen is verdeeld of een prijs die is gewijzigd nadat de bestelling was geplaatst. Een medewerker opent elke factuur, bepaalt om welke van ongeveer twaalf soorten afwijkingen het gaat en stuurt vervolgens een bericht naar de leverancier.

Verdeeld over meerdere agents ziet dat proces er als volgt uit. Een uitleesagent haalt de gegevens uit de factuur en de leveringsbon. Een controleagent vergelijkt die gegevens met de inkooporder en benoemt de afwijking. Een opstelagent schrijft een vraag aan de leverancier in de juiste taal. Het concept verschijnt in de wachtrij waarin het team al werkt, waarna een medewerker het bericht verstuurt.

Er zijn drie redenen waarom deze verdeling hier zinvol is. Ten eerste hebben de agents verschillende tools nodig. De uitleesagent moet documenten kunnen verwerken, de controleagent moet leestoegang hebben tot het ordersysteem en de opstelagent heeft geen van beide nodig. Ten tweede verschillen de gevolgen van fouten. Een verkeerd uitgelezen veld kan in de volgende stap worden ontdekt, terwijl een onjuist geformuleerde vraag rechtstreeks naar een leverancier kan gaan. Ten derde zijn er verschillende verantwoordelijken. De financieel verantwoordelijke bepaalt wat als afwijking geldt. Niemand anders zou die instructie zomaar moeten kunnen aanpassen.

Aan die verdeling hangt wel een prijskaartje. Benoem dat voordat u ervoor kiest. Drie agents betekenen drie sets instructies die u moet onderhouden, drie sets tool machtigingen die u moet controleren en een extra plek waar een taak halverwege kan vastlopen zonder dat iemand het merkt. Werken met meerdere agents brengt beheerkosten met zich mee. Het is geen gratis upgrade.

Gebruik één agent als de stappen altijd in dezelfde volgorde worden uitgevoerd en dezelfde systemen gebruiken. Eén agent met vier tools is eenvoudiger te testen, goedkoper in gebruik en veel gemakkelijker uit te leggen dan vier agents met elk één tool. Verdeel het werk pas over meerdere agents als de onderdelen echt verschillen in de tools die ze nodig hebben, de gevolgen van fouten of de persoon die verantwoordelijk is voor de instructies.

U kunt dit snel toetsen. Beschrijf wat elke agent anders zou doen wanneer de invoer ongebruikelijk is. Lukt dat niet, dan hebt u waarschijnlijk één agent die drie verschillende rollen vervult. Die extra rollen kosten u geld zonder dat ze voldoende meerwaarde bieden.

Ook één agent kan op bekende manieren misgaan. Met meerdere agents komen daar drie extra risico's bij. Die hebben niet zozeer met intelligentie te maken, maar met het beheer.

Bij de overdracht raakt het overzicht verloren. Elke agent legt vast wat hij zelf heeft gedaan. Maar de vraag die u moet beantwoorden, is wat er met de volledige opdracht is gebeurd. Als u de registraties van de agents die aan één zaak hebben gewerkt niet kunt samenvoegen, houdt u meerdere gedeeltelijke verslagen over en geen volledig overzicht. Juist dat kost vaak de meeste tijd bij het opsporen en oplossen van problemen.

Het aantal machtigingen loopt snel op. Eén agent met vier tools vraagt om vier beslissingen over machtigingen. Vier agents met elk vier tools vragen om zestien beslissingen. De zestiende wordt misschien om vijf uur 's middags overgenomen uit een sjabloon. Juist de ruimste machtiging in de hele set is doorslaggevend, en meestal is dat niet de machtiging die iemand daadwerkelijk heeft gecontroleerd.

Niemand bewaakt de uitvoeringslus. Twee agents kunnen werk naar elkaar blijven doorschuiven, waarbij elke agent wacht tot de andere tevreden is. Op een dashboard lijkt het alsof er voortgang wordt geboekt, terwijl de kosten bij de model provider oplopen. Er moet iets buiten de agents zelf grenzen stellen aan het aantal stappen, de looptijd en de kosten. Zodra een limiet is bereikt, moet de uitvoering stoppen.

Gebruik deze lijst bij gesprekken met elke leverancier, ook met de onze. Er zijn vier vereisten.

Eén volledig uitvoeringsverslag per run, samengesteld uit alle agents. Elke stap, elke tool-aanroep, elke invoer en elk resultaat moet gekoppeld zijn aan de run waartoe deze behoren. De runtime moet dit verslag vastleggen, niet het model zelf. Een beschrijving van het eigen werk door een model is tekst, geen bewijs. Afzonderlijke toolmachtigingen per agent. De uitleesagent heeft geen schrijftoegang tot het ordersysteem nodig. Leg vooraf vast welke tools elke agent mag aanroepen en begin met alle machtigingen uitgeschakeld. Een stopvoorwaarde die de agents niet zelf beheren. Stel limieten in voor het aantal stappen, de looptijd en de kosten. Deze limieten moeten van buiten de uitvoeringslus worden afgedwongen. Definities die u op één plek kunt controleren. De instructies, tools en kennisbronnen van elke agent moeten leesbaar zijn en versiebeheer ondersteunen. Zo kan iemand een wijziging vooraf bekijken, in plaats van pas achteraf te ontdekken dat er iets is veranderd. Vraag de leverancier om alle vier de mogelijkheden te laten zien in de versie die u daadwerkelijk zou installeren, niet alleen in een demo van de nieuwste ontwikkelversie.

Een multi-agentsysteem leest uw documenten, gebruikt uw inloggegevens en maakt herhaaldelijk verbinding met uw systemen. Daarom hoort ook de implementatie bij de technische keuze. Op welke machines draait het systeem? Welk modelendpoint wordt aangeroepen? In welke database worden de uitvoeringsgegevens opgeslagen? Als die gegevens in het systeem van een leverancier staan, hangt de beschikbaarheid van uw verslag van wat er is gebeurd af van de duur van uw contract.

EpicStaff draait op uw eigen infrastructuur. De broncode is beschikbaar onder de licentie PolyForm Perimeter 1.0.0. U kunt de code lezen, uitvoeren en aanpassen voor uw eigen gebruik. De belangrijkste beperking is dat u anderen geen product mag aanbieden dat met EpicStaff concurreert, ongeacht of dat gratis of betaald is. Het inspecteren van de code is niet beperkt. Er gelden ook andere voorwaarden, waaronder verplichtingen om bepaalde informatie te vermelden wanneer u de software doorgeeft. Raadpleeg daarvoor LICENSE.md.

Agents, tools en graphs zijn objecten die u zelf definieert. Daardoor kan iemand de configuratie van een multi-agentsysteem bekijken voordat het wordt uitgevoerd. De registraties van prompts, tool-aanroepen en modelreacties worden opgeslagen in uw eigen PostgreSQL-database. U kunt deze gegevens exporteren als JSON- of CSV-bestand.

Op rollen gebaseerde toegangscontrole (RBAC) is beschikbaar in de source-available tier, niet in de betaalde. Een agent kan een ander systeem uitsluitend bereiken via tools die uw team eraan koppelt. Dat kunnen Python-tools zijn, door uw team zelf gebouwd of kant-en-klaar meegeleverd door EpicStaff, of een MCP-server (Model Context Protocol) die uw team aansluit.

EpicStaff maakt alleen verbinding met externe providers waarvoor u sleutels configureert. Tools voeren uit wat u ze opdraagt. Als u een tool bouwt of inschakelt die toegang heeft tot internet, is dat uw keuze en uw configuratie.