De AI agent is klaar. Niemand kan zeggen wat hij deed.

De run is afgelopen, het scherm is groen geworden, en het werk is niet gedaan. Als iemand vraagt welke tool de agent aanriep, wat hij verstuurde en waar hij stopte, hebben veel teams geen antwoord. Is de term nieuw voor u, lees dan eerst wat een AI agent is.

Een status is één woord dat voor veel stappen staat. "Klaar" vertelt u dat het systeem dat de run uitvoert, het einde heeft bereikt. Het vertelt u niet dat de boeking is opgeslagen, dat de e-mail naar de juiste persoon ging, of dat de agent de tool aanriep die hij zei aan te roepen.

Het patroon herhaalt zich bij verschillende tools en teams. Een agent meldt dat hij een record heeft opgeslagen, maar hij heeft de aanroep nooit gedaan; hij schreef alleen een zin die klinkt alsof hij dat deed. Het scherm toont een run als geslaagd, terwijl de database dezelfde run als gecrasht markeert. Een run blijft na de eerste stap hangen, zonder foutmelding en zonder time-out, en het opgeslagen verslag is leeg, dus het kan niet zeggen waar de run stopte. Een mislukt verzoek laat helemaal geen run achter, zelfs geen mislukte. En als iemand een oudere run nodig heeft, is het verslag al verwijderd.

Niets hiervan is uitzonderlijk. Het is wat er gebeurt als de status als het verslag wordt behandeld. Een status is een samenvatting. Een verslag is het bewijs erachter.

Er is nog een valkuil. Als u de agent vraagt wat hij deed, geeft hij antwoord, en vlot ook. Dat antwoord is tekst die het model heeft gemaakt, geen logboek van wat het systeem deed. Het kan kloppen. Het is geen bewijs.

Een bruikbaar runverslag beantwoordt de vragen die mensen na een run stellen, zonder dat iemand de code hoeft te openen. In de praktijk betekent dat zes dingen.

1. Elke stap, in volgorde. Wat er werd uitgevoerd, wanneer het begon en wanneer het eindigde.
2. Elke tool call, met invoer en uitvoer. Wat de agent naar de tool stuurde, en wat er terugkwam. "Geslaagd" op zich is geen uitvoer.
3. Waar de run stopte. De laatste stap die begon en de laatste stap die eindigde. Bij een run die blijft hangen, is het gat daartussen het hele antwoord.
4. Eén status. Het scherm en het opgeslagen verslag zeggen hetzelfde. Als ze elkaar kunnen tegenspreken, moet u weten welke klopt.
5. Koppelingen tussen runs. Als de ene flow een andere aanroept, verwijst de onderliggende run naar de bovenliggende run, zodat u één taak door al zijn onderdelen kunt volgen.
6. Genoeg tijd. Verslagen worden lang genoeg bewaard om terug te kijken wanneer de vraag komt, en dat is vaak weken later en zelden wanneer het u uitkomt.

Het verslag moet worden geschreven door het systeem dat het werk uitvoert, niet verteld door het model daarbinnen.

Een run die zichtbaar mislukt, is het makkelijke geval. Iemand ziet de rode markering en kijkt. Het moeilijke geval is een run die klaar was, groen toonde en het verkeerde deed: hij stuurde een bericht twee keer, schreef een verkeerde waarde in een klantrecord, koos de verkeerde vertakking of bevestigde een stap die nooit had plaatsgevonden.

Dan worden de vragen concreet. Wat zag de agent? Wat besloot hij? Wat stuurde hij, naar welk systeem en wanneer? Deed hij dit één keer, of bij elke run sinds dinsdag?

Zonder verslag reconstrueert het team het verhaal vanaf de andere kant. Het zoekt in de doelsystemen naar sporen, vergelijkt tijdstempels en vraagt het de agent, wat terugleidt naar tekst die geen bewijs is. Teams die dit hebben meegemaakt, houden hun eigen verslagen bij: een rij die aan het einde van elke taak wordt geschreven, een spreadsheet met run-ID's, een bewakingsproces dat dingen herstart als een run te lang stilstaat. Dat werkt. Het is ook een teken dat het team nu een tweede systeem onderhoudt om een verslag te vervangen dat de tool niet bijhield.

De echte kosten van een verkeerde run zitten zelden in de fout zelf. Ze zitten in de dagen die nodig zijn om het eens te worden over wat er gebeurde, voordat iemand het kan herstellen.

Een runverslag heeft minstens drie lezers, en elk van hen stelt andere vragen aan dezelfde gegevens.

De beheerder leest het nu. Een run is traag of zit vast, en de beheerder moet weten welke stap en waarom, nu er nog tijd is om in te grijpen.

De teamleider leest het deze week. Werkt het proces? Welke stap mislukt het vaakst? Roept de agent tools aan die hij niet nodig zou moeten hebben?

Een beoordelaar leest het later, soms veel later. Een klant dient een klacht in, er start een intern onderzoek, of een toezichthouder vraagt wat het systeem op een bepaalde dag deed. Deze lezer heeft de flow niet gebouwd en heeft hem misschien nooit zien draaien. Het verslag moet begrijpelijk zijn zonder dat de maker erbij is. Dezelfde lezer stelt misschien ook de vraag wie controleert de agent-harness.

Als alleen de ontwikkelaar die de flow bouwde het verslag kan lezen, heeft de organisatie er geen.

Dit zijn vragen voor elke leverancier, ook voor ons. Stel ze over de versie die u zou installeren, en vraag om het antwoord te zien bij een echte run.

1. Kan ik elke stap van een run volgen terwijl die loopt, en niet pas nadat die is afgelopen?
2. Kan ik bij elke tool call zien wat er werd verstuurd en wat er terugkwam?
3. Als een run blijft hangen, toont het verslag dan de laatste stap die begon?
4. Kunnen het scherm en het opgeslagen verslag ooit een verschillende status tonen? Zo ja, welke klopt?
5. Kan ik een volledige run exporteren, met elke tool call, in een formaat dat mijn eigen tools kunnen lezen?
6. Hoe lang worden runverslagen bewaard, en wie beslist dat?
7. Wordt het verslag geschreven door de uitvoeringsomgeving, of beschreven door het model?

Hoe EpicStaff deze vragen beantwoordt.

Elke stap, terwijl die loopt. EpicStaff-flows bestaan uit afzonderlijke stappen (nodes). Terwijl een run loopt, kunt u zien dat elke node start, wat die ontving en wat die teruggaf, en of er een fout optrad.

Tool calls en export. De sessie-export (JSON) bevat de tool calls die de agent deed: welke tool, wat ernaartoe werd gestuurd en wat er terugkwam. Invoer en uitvoer van tools die langer zijn dan 2.000 tekens, worden op die lengte afgekapt; ze worden nooit samengevat.

Een run die blijft hangen. EpicStaff slaat de start van elke stap op zodra die plaatsvindt, dus een run die blijft hangen, toont nog steeds de laatste stap die begon.

Scherm en verslag. Het live scherm kan kort achterlopen; het opgeslagen runverslag is de bron van waarheid.

Hoe lang verslagen bewaard blijven. Runverslagen blijven in uw eigen database staan tot iemand met verwijderrechten ze verwijdert; de standaardrelease verwijdert ze niet volgens een schema.

Wie het verslag schrijft. Het runverslag wordt door EpicStaff geschreven terwijl elke stap en tool call plaatsvindt, en niet achteraf door het model samengevat.

EpicStaff draait op uw eigen infrastructuur, dus het runverslag staat in uw eigen database.