Designing Intelligent Enterprise Agents: A Capability-Aligned Multi-Agent Architecture
Dit artikel stelt de Capability-Aligned Enterprise Agent Design (CEAD)-architectuur voor, die strenge agentontwerpprincipes prioriteert boven governance-gerichte modellen om aanzienlijk hogere veilige succespercentages te bereiken in enterprise multi-agent-systemen in vergelijking met alternatieve benaderingen.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je de CEO bent van een enorm bedrijf. Je hebt gehoord dat kunstmatige intelligentie (KI)-agenten de toekomst zijn – digitale werknemers die kunnen denken, plannen en dingen voor elkaar krijgen. Maar je bent bezorgd. Als je er te veel van inhuurt, of de verkeerde, kunnen ze ruzie met elkaar maken, fouten maken of per ongeluk de database van je bedrijf wissen.
Dit paper, geschreven door John deVadoss, is een blauwdruk voor het inhuren en beheren van deze "KI-werknemers" zonder chaos te veroorzaken. Het betoogt dat je niet zomaar een governance-beleid kunt plakken op een slecht ontwerp en kunt verwachten dat het werkt. Je moet eerst het werk correct ontwerpen.
Hieronder wordt het paper in eenvoudige termen uitgelegd, met behulp van alledaagse analogieën.
1. Het probleem: de "microservice"-fout
Jaren geleden probeerden bedrijven hun software op te splitsen in tiny, onafhankelijke stukjes die "microservices" werden genoemd. Ze dachten: "Als we 100 tiny services hebben, kunnen we super flexibel zijn!" Maar het ging mis. Ze eindigden met een verwarde wirwar van 100 services die niet goed met elkaar communiceerden, duur waren om te draaien en constant crashten. Dit wordt "gedistribueerde complexiteit" genoemd.
Nu doen bedrijven exact hetzelfde met KI-agenten. Ze creëren honderden tiny "micro-agenten" (zoals een "sales-bot", een "hr-bot", een "finance-bot") alleen maar omdat het cool klinkt.
- De waarschuwing uit het paper: Als je 50 agenten creëert zonder een duidelijk plan, bouw je geen team; je bouwt een chaotische menigte. Ze zullen overlappen, ruzie maken en fouten maken.
2. De oplossing: CEAD (de "capaciteits-gealigneerde" aanpak)
De auteur stelt een nieuwe manier voor om deze systemen te bouwen, genaamd CEAD. Denk eraan als het bouwen van een professioneel sportteam in plaats van een willekeurige pick-upwedstrijd.
- De oude manier (Governance-first): "Laten we 20 agenten inhuren en vervolgens een 50 pagina's tellend regelboek schrijven dat hen vertelt wat ze niet mogen doen."
- Resultaat: De agenten zijn nog steeds verward, het regelboek is te traag om hen te stoppen, en ze falen.
- De CEAD-methode (Design-first): "Laten we kijken naar de daadwerkelijke taken die moeten worden uitgevoerd. Wie is verantwoordelijk voor die taak? Welke tools hebben ze nodig? Wat zijn de risico's?" Vervolgens huren we de specifieke agenten in die nodig zijn voor die taken, en de regels passen zich vanzelf rond hen aan.
3. De belangrijkste tool: het "Agent Capability Contract" (ACC)
In de oude tijden, toen je een mens inhuurde, gaf je hen een functieomschrijving. In de oude software-tijden had je een "Service Contract" (een lijst van wat een softwareprogramma kon doen).
Het paper stelt dat elke KI-agent een Agent Capability Contract (ACC) nodig heeft. Dit is geen saai juridisch document; het is de "identiteitskaart en functieomschrijving" van de agent in één. Het stelt duidelijk:
- Wat is je baan? (Bijvoorbeeld: "Facturen verwerken", niet "Alles doen".)
- Wat mag je beslissen? (Bijvoorbeeld: "Je mag facturen onder de 500 dollar goedkeuren, maar je moet een mens vragen voor alles boven de 500 dollar".)
- Welke tools mag je aanraken? (Bijvoorbeeld: "Je mag de database lezen, maar je mag hem niet wissen".)
- Wat gebeurt er als je vastloopt? (Bijvoorbeeld: "Als je het niet zeker weet, stop dan en vraag een mens".)
De analogie: Stel je een bouwplaats voor.
- Zonder ACC: Je geeft een hamer aan een willekeurige persoon en zegt: "Bouw een huis, maar volg de regels." Ze kunnen hun duim raken, of het dak op de grond bouwen.
- Met ACC: Je hebt een voorman (de Supervisor) die een specifieke werknemer een specifieke taak geeft: "Jij bent de 'Stellwerker'. Je hebt een hamer en een zaag. Je mag muren tot 10 voet bouwen. Als je een balk moet zagen, vraag de Hoofd Timmerman. Als je een kras in de fundering ziet, stop dan en bel de Ingenieur."
4. Het experiment: wie won?
De auteur testte vijf verschillende manieren om 10.000 verschillende bedrijfstaken te organiseren (zoals het verwerken van loonlijsten, het controleren van juridische contracten of het beheren van IT-tickets).
- De Lone Wolf: Één grote KI die alles probeert te doen. (Faalde vaak omdat het verward raakte).
- De Zwerm: 32 tiny agenten die wild rondrennen zonder duidelijke regels. (Ramp. Veel fouten, hoge kosten).
- De SOA-stijl: Agenten verbonden als oude software-services. (Beter, maar miste nog steeds het "denkende" deel van KI).
- Het "Governance-first"-rooster: Een groot team van agenten met een enorm regelboek en strenge auditors, maar zonder duidelijk taakontwerp. (Ze volgden de regels, maar ze waren traag, duur en maakten nog steeds fouten omdat de structuur slecht was).
- Het CEAD-team: Een klein, goed ontworpen team met duidelijke contracten, een supervisor en specifieke tools.
De resultaten:
Het CEAD-team won met overmacht.
- Ze slaagden veilig in 70,6% van de gevallen.
- Het "Governance-first"-team haalde slechts 50,8%.
- De "Zwerm" haalde slechts 23,1%.
De les: Je kunt een slecht teamontwerp niet repareren met een beter regelboek. Je moet eerst het team correct ontwerpen. De regels (governance) zijn er om het goede ontwerp te ondersteunen, niet om het te creëren.
5. De gouden regels voor bedrijfsleiders
Als je KI-agenten in je bedrijf wilt gebruiken, geeft het paper deze eenvoudige tips:
- Huur geen agenten in voor "rollen" (zoals "Marketing Bot"). Huur ze in voor capaciteiten (zoals "De persoon die factuurgoedkeuringen afhandelt").
- Begin klein. Bouw geen zwerm van 50 agenten. Begin met één "Supervisor"-agent en voeg specialisten alleen toe als ze een totaal andere baan hebben of andere tools nodig hebben.
- Behandel geheugen als een kluis. KI-agenten onthouden dingen. Je moet ontwerpen wie dat geheugen mag lezen en wie het mag wissen, net zoals je dat zou doen met een bankkluis.
- Mensen moeten in de loop zitten. Bij risicovolle beslissingen (zoals geld uitgeven of iemand ontslaan) moet de agent stoppen en een mens vragen. Dit is geen bug; het is een feature.
- Vuur je agenten. Als een agent zijn werk niet doet, of als twee agenten hetzelfde doen, maak dan af van hen. Laat ze niet ophopen.
Samenvatting
Het paper zegt: Ontwerp is Koning.
Gooi niet zomaar KI op je problemen en hoop dat de regels je redden. Ontwerp eerst de "banen", geef de agenten duidelijke contracten, houd het team klein en laat de regels dat goede ontwerp beschermen. Als je dat doet, zullen je KI-agenten veilig, efficiënt en daadwerkelijk nuttig zijn. Als je dat niet doet, heb je gewoon een zeer dure, zeer verwarde digitale menigte.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.