De sub-agent deed het werk. Het antwoord kwam nooit terug.

Een supportteam bouwt één hoofdagent die alle e-mails van klanten leest. Gaat een e-mail over een levering, dan geeft de hoofdagent de vraag door aan een helperagent. Die kan bestellingen opzoeken.

Op maandag vraagt een klant waar zijn pakket blijft. Het antwoord luidt: "Wij kunnen uw bestelling niet vinden."

De bestelling bestaat wel. Ze staat in het systeem, inclusief trackingnummer.

Het team heeft nu drie vragen in plaats van één. Is de helper nooit gestart? Is hij gestart, maar is er iets misgegaan? Of heeft hij de bestelling gevonden, maar is het antwoord onderweg terug verloren gegaan? Elk scenario vraagt om een andere oplossing. Toch ziet het antwoord aan de klant er in alle drie de gevallen hetzelfde uit.

Eén gebruiker meldde dat een helperagent een bepaalde tool niet kon gebruiken. De hoofdagent gaf twee waarden door aan de helper, die vervolgens een webverzoek moest versturen. Er werd echter geen verzoek verstuurd. Dezelfde tool werkte wel toen deze aan de hoofdagent was gekoppeld. De foutmelding vermeldde niet welke tool het probleem veroorzaakte.

Een andere gebruiker controleerde de rungegevens van het platform en meldde dat de workflows van de helper helemaal niet waren gestart.

Een derde gebruiker meldde dat de workflow van een helper nooit werd uitgevoerd, terwijl de hoofdagent toch antwoord gaf. Dat antwoord had de hoofdagent zelf verzonnen. Volgens de gebruiker gebeurde dit zelfs nadat er een oplossing was uitgebracht.

Een team meldde dat een helper de gegevens wel had gevonden, maar vervolgens kort na elkaar twee signalen stuurde dat hij klaar was. De hoofdagent nam het eerste signaal, waarin geen bevindingen stonden, en vertelde de gebruiker dat de zoekopdracht niets had opgeleverd. Het team neemt nu elke invoer opnieuw op in de verzoektekst, omdat gegevens die op de gebruikelijke manier werden doorgegeven vaak niet aankwamen.

Een andere gebruiker meldde dat een helper zijn werk had afgerond en een geldig antwoord had opgesteld. Toch zag de persoon in de chat alleen een algemene verontschuldiging waarin stond dat de assistent geen antwoord kon geven.

Er zijn dus twee soorten fouten. Of de helper voert het werk helemaal niet uit, of het werk is gedaan maar het resultaat komt niet terug. In twee van deze meldingen gaf de hoofdagent alsnog een antwoord dat niet klopte.

Het model voert de overdracht niet zelf uit. Dat doet de harness: de runtime-laag rond het model die uw agents laat draaien. Lees meer in wie controleert de agent-harness. Zijn deze termen nieuw voor u? In wat een AI agent is vindt u een korte uitleg.

De onderstaande controles gaan dus over de harness, niet over de prompt. Ze zijn toepasbaar op elk platform, ook op EpicStaff. Onder elke controle leest u hoe EpicStaff hiermee omgaat.

Ga na hoe uw platform werk van de ene agent naar de andere doorgeeft. Dat kan via een tool die de hoofdagent aanroept, een afzonderlijke workflow of een bericht aan een andere agent. Elke route kan op een andere manier mislukken. Voordat u het probleem onderzoekt, moet u dus weten welke route u gebruikt.

In EpicStaff kan een flow een andere opgeslagen flow uitvoeren als een van zijn stappen. Ook kunt u met de ingebouwde Fan-Out-tool meerdere flows tegelijk starten.

Leg voor elke overdracht vast welke van deze twee routes wordt gebruikt. De overige vier controles zijn daarvan afhankelijk.

Een helper heeft vaak andere tools dan de hoofdagent. In de eerste melding hierboven werkte een tool wel bij de hoofdagent, maar niet bij de helper. Als u een tool alleen bij de hoofdagent test, hebt u dus nog niet getest of die bij de helper werkt.

In EpicStaff werkt elke agent uitsluitend met de tools die aan die agent zijn gekoppeld.

Een tool van de hoofdagent is daarom pas beschikbaar voor de helper als u deze ook aan de helper koppelt. Leg de toollijsten van beide agents naast elkaar. Geef elke helper de tools die nodig zijn voor zijn deel van het werk, en niet meer dan dat.

Er zijn drie mogelijke uitkomsten. De volledige run stopt. De hoofdagent krijgt een melding van de fout en gaat verder. Of niemand krijgt de fout te zien. Vooral die laatste situatie is gevaarlijk, omdat de hoofdagent dan alsnog een zelfverzekerd antwoord kan formuleren.

Ga niet uit van wat uw platform vermoedelijk doet. Test het. Laat de helper bewust falen, bijvoorbeeld door een niet-bestaand bestelnummer te gebruiken of een zoekopdracht uit te voeren die te lang duurt. Controleer daarna wat de hoofdagent zegt.

In EpicStaff geldt dat de run stopt als een subflow-stap mislukt. De fout wordt vastgelegd en de run gaat niet verder zonder het resultaat.

Dit geldt voor de route met een subflow. Gebruikt u de Fan-Out-tool voor een overdracht, voer dan dezelfde test uit en controleer hoe de hoofdagent omgaat met een mislukte flow.

EpicStaff kan een afzonderlijke stap of subflow niet hervatten of opnieuw proberen. Een mislukte run moet vanaf het begin opnieuw worden gestart. Zorg er daarom voor dat een tweede run niet nogmaals dezelfde e-mail verstuurt of dezelfde betaling uitvoert.

Als een overdracht misgaat, hebt u informatie over beide kanten nodig. Wat heeft de hoofdagent verstuurd? Wat heeft de helper ontvangen? Wat heeft de helper gedaan en wat heeft hij teruggestuurd? Een registratie van alleen de hoofdagent toont u wel het antwoord, maar niet de oorzaak van het probleem.

In EpicStaff worden de invoer en uitvoer van elke stap vastgelegd in de run, ook voor stappen binnen een subflow.

Begin bij de invoer die de subflow heeft ontvangen. Vergelijk die met wat de hoofdflow wilde versturen. In de melding van het team hierboven gingen waarden verloren tussen de twee kanten. Door de invoer te vergelijken, kunt u ontdekken welke waarde ontbreekt.

Een helper kan stoppen omdat hij een limiet bereikt, bijvoorbeeld een tijdslimiet, een tokenbudget of een maximumaantal stappen of tool-aanroepen. Toch kan hij een antwoord terugsturen, alleen is dat antwoord mogelijk korter of bevat het minder informatie. Het kan er nog steeds uitzien als een geldig resultaat.

In EpicStaff toont het runverslag welke limiet is bereikt en waarom de agent is gestopt.

Lijkt het antwoord van een helper onvolledig, bekijk dan eerst het runverslag voordat u de instructies aanpast. Een bereikte limiet en een gebrekkige instructie vragen om verschillende oplossingen.

Hieronder staat de overdracht voor leveringsvragen uit het supportteam aan het begin van dit artikel, samengevat in één korte notitie. Houd voor elke overdracht zo’n notitie bij. Vul deze in voordat de overdracht live gaat, niet pas nadat het eerste verkeerde antwoord is gegeven.

• Overdracht: vragen over leveringen, van de e-mailagent naar de tool voor het opzoeken van bestellingen.
• Route: een subflow-stap die de opgeslagen flow "Bestelling opzoeken" uitvoert.
• Tools van de helper: de database met bestellingen, alleen-lezen. Verder niets.
• Doorgegeven waarden: het bestelnummer en het e-mailadres van de klant.
• Als de helper faalt: de run stopt. Het team controleert elk uur de gestopte runs en beantwoordt de betreffende e-mails handmatig.
• Waar u het kunt controleren: het runverslag, bij de stappen binnen "Bestelling opzoeken".
• Bij een limiet: controleer waarom de agent is gestopt voordat iemand op een kort antwoord vertrouwt.
• Getest met: één bestaande bestelling, één niet-bestaand bestelnummer en één zoekopdracht die te lang duurt.

Blijft een regel in de notitie leeg, dan is dat de overdracht die u als eerste moet testen.