Voordat ik een agent ontwerp, schrijf ik de beslissingen op die het systeem moet nemen. “Verwerk binnenkomende verzoeken” is een doel, maar het vertelt me niet of de volgende stap voorspelbaar is, of ontbrekende informatie kan worden hersteld, of welke autoriteit het systeem nodig heeft.
Die details bepalen de architectuur. Een vaste workflow volgt een expliciete volgorde of set van takken. Een agent kan zijn volgende actie kiezen op basis van observaties. Beiden kunnen een taalmodel gebruiken; het nuttige onderscheid is wie het pad door het werk controleert.
Scheiding van onzekerheid en gewone bedrijfsregels
Overweeg een verzoek om een afleveradres bij te werken. Het lezen van een slecht geschreven bericht kan taalbegrip vereisen. Controleren of de bestelling toebehoort aan de klant is een gewone toegangsbeslissing. Bepalen of de verzending al is gestart is een huidige-status opzoeking. Het toepassen van de wijziging is een bedrijfsoperatie.
Er is weinig waarde in het vragen aan een model om alle vier de stappen te improviseren. Ik zou het laten identificeren van de aanvraag en een voorgesteld adres extraheren, en vervolgens expliciete regels gebruiken voor eigendom, geschiktheid en de daadwerkelijke update. Als het adres onvolledig is, kan de workflow een gerichte verduidelijkingsvraag stellen.
Een andere taak, zoals het onderzoeken van tegenstrijdige beschrijvingen uit verschillende bronnen, kan een minder voorspelbare volgorde vereisen. Een agent zou kunnen beslissen welke bron als volgende te inspecteren, mits de onderzoeksomvang en de criteria voor voltooiing duidelijk zijn.
Teken de beslissingsgrens voor de gereedschapslijst
Ik begin met drie vragen: wat kan het systeem observeren, wat kan het beslissen, en wat kan het veranderen? Deze vragen onthullen nuttigere grenzen dan een lange lijst van beschikbare integraties. Een systeem dat elk accountrecord kan lezen, heeft misschien nog steeds toestemming om slechts één veld op één geverifieerd account te wijzigen.
Voor elke voorgestelde autonome stap vraag ik welke nieuwe informatie de volgende actie zou kunnen veranderen. Als het antwoord altijd hetzelfde is, is een vaste stap meestal gemakkelijker te inspecteren. Als het antwoord afhankelijk is van bewijs dat niet van tevoren kan worden voorspeld, kan een beperkte keuze voor de agent nuttig zijn.
De engineeringwerk dat ik doe via Wizutech geeft me een praktische reden om dit onderscheid te maken: operationele software moet vage menselijke verzoeken verbinden met precies systeemgedrag. De architectuur moet die overgang begrijpelijk maken.
Geef de flexibele sectie een kleine interface
Een nuttig hybride ontwerp heeft een expliciete ingangseis, een begrensde agenttaak en een gecontroleerd resultaat. Voor een onderzoekstaak kan het resultaat kandidaatrecords, ondersteunende bronnen en onopgeloste vragen bevatten. Het zou geen onbeperkte paragraaf moeten zijn die de volgende stap opnieuw moet interpreteren.
Die grens maakt vervanging ook gemakkelijker. Een model kan veranderen terwijl de omringende applicatie nog steeds dezelfde resultaatstructuur verwacht. Het belangrijke contract is de betekenis van de output, inclusief hoe een onvolledig resultaat eruitziet.
Mijn begeleidende aantekening over toolcontracten voor ambiguë verzoeken ontwikkelt die interface in meer detail. Een kleinere beslissingsruimte is alleen nuttig als de tools daarin duidelijke semantiek hebben.
Vergelijk de volledige taak
Ik zou een workflow en een agent vergelijken op representatieve verzoeken, inclusief de gevallen die verduidelijking vereisen of niet kunnen worden voltooid. De nuttige maatstaven omvatten geaccepteerde uitkomsten, onjuiste acties, inspanning van de operator en totale uitvoeringskosten. Alleen het tellen van modelaanroepen zegt weinig over de vraag of het systeem het probleem heeft opgelost.
Fouten moeten worden gegroepeerd op basis van hun oorzaak. Een ontbrekende bedrijfsregel heeft een regel nodig. Een onduidelijke aanvraag heeft verduidelijking nodig. Een oprecht open onderzoek kan profiteren van adaptieve planning. Het uitbreiden van autonomie is een slechte vervanging voor het identificeren van welk probleem zich heeft voorgedaan.
Voordat ik het ontwerp uitbreid, controleer ik of delegeren aan meerdere agenten onafhankelijke leveringen zou opleveren. Een begrensde agent binnen een voorspelbare workflow kan een sterk uitgangspunt zijn: voldoende flexibiliteit om onzekerheid te onderzoeken, terwijl de omringende applicatie nog steeds verantwoordelijk is voor de grenzen en uitkomsten van de taak.
Bijgewerkt op 30 september 2026.