Wat live draait, is niet wat u hebt getest

U past een prompt aan, test hem en ziet dat hij werkt. Vervolgens slaat u hem op. Een week later gebruikt de agent nog steeds de oude versie, zonder dat er ergens een melding verschijnt. Of er is helemaal niets gewijzigd, maar op een ochtend geeft de agent ineens lege antwoorden.

Dit is een van de minder opvallende problemen bij het werken met agents. Er crasht niets en elke run lijkt normaal te verlopen. Toch kunt u geen antwoord geven op de eenvoudige vraag: welke versie draaide er?

Kijk naar wat een AI agent is: een model, instructies, tools en stappen die samen een taak uitvoeren. Zodra u één onderdeel wijzigt, hebt u in feite een ander programma. Softwareteams weten dit van code. Bij agent-workflows vergeten ze het vaak, omdat de editor meer aanvoelt als een document dan als een plek waar u nieuwe versies uitbrengt.

Softwareteams hebben dit probleem al lang geleden aangepakt met drie vaste werkwijzen. Elke wijziging heeft een bekende versie. Bij elke run staat welke versie is gebruikt. En er is een bewuste stap van testen naar live zetten. Agent-workflows hebben diezelfde drie werkwijzen nodig. De meeste problemen hieronder ontstaan doordat een of meer ervan ontbreken.

Opgeslagen is niet hetzelfde als gepubliceerd. Veel tools bewaren zowel een concept waaraan u werkt als een versie die in productie draait. Dat is een goed ontwerp, zolang het scherm het verschil duidelijk maakt. Eén team meldde dat een aangepaste planning wel was opgeslagen, maar nooit was gepubliceerd. De oude planning bleef draaien en geld kosten, totdat iemand de kosten per workflow bij elkaar optelde. Andere teams meldden een chatbot die wekenlang de oude logica bleef gebruiken en formuliervelden die er in de editor goed uitzagen, maar in productie leeg bleven. In al deze gevallen dacht de gebruiker dat de wijziging live stond. Niets wees erop dat dit niet zo was.

Gepubliceerd betekent niet automatisch dat de nieuwe versie draait. In dit geval had de gebruiker wel op publiceren gedrukt, maar draaide nog steeds de oude versie. Een team dat de software zelf host, meldde dat een publicatie pas effect had nadat de server opnieuw was opgestart. Later deed hetzelfde probleem zich opnieuw voor. Een ander team zag dat runs na een publicatie nog steeds de oude versie gebruikten, zonder dat de oorzaak werd gevonden. Als u niet kunt zien welke versie een run heeft gebruikt, kunt u niet eens vaststellen met welk van deze twee problemen u te maken hebt.

De test is geen productie. Een testvenster volgt een ander pad. Het kan een andere identiteit, een ander kanaal, andere rechten en soms zelfs een andere modelinstelling gebruiken. Eén team meldde dat een agent wel werkte voor de ontwikkelaars, maar niet meer zodra die met echte gebruikers werd gedeeld, omdat deze gebruikers andere toegangsrechten hadden. Een ander team ontdekte dat een model tijdens het testen goed werkte, maar in het live chatkanaal alleen nog een verontschuldiging gaf. Een test die niet hetzelfde verloopt als de productieomgeving, is geen volwaardige test. Het is een voorvertoning.

Niemand heeft iets gewijzigd, maar het gedrag is veranderd. Een agent is afhankelijk van onderdelen die niet onder uw beheer vallen, zoals het onderliggende model, de uitvoeringsomgeving van de leverancier of een basisimage. Eén team meldde dat een agent maandenlang goed werkte en vervolgens lege antwoorden begon te geven. Volgens hun eigen onderzoek was het onderliggende model zonder aankondiging bijgewerkt. Een ander team zag hoe een leverancier een previewfunctie onder een live agent introk. Geen enkele instelling aan hun kant kon dat herstellen. Uw versie bleef hetzelfde, maar het gedrag veranderde.

U hebt hiervoor geen groot platformproject nodig. Het gaat om werkwijzen die u waarschijnlijk al voor code gebruikt.

Geef elke wijziging een versie. Alles wat u opslaat en kunt uitvoeren, moet een herkenbare versie en een korte toelichting hebben. Als iets in productie kan belanden, moet het een naam hebben waarnaar u kunt verwijzen. Leg vast waarvan u afhankelijk bent. Noteer de modelversie in plaats van alleen 'de nieuwste'. Weet welke uitvoeringsomgeving en welk image u gebruikt. Een wijziging bij de leverancier moet een bewuste keuze zijn, geen verrassing. Leg bij elke run de gebruikte versie vast. Sla bij elke run op welke workflowversie, welk model en welke instellingen zijn gebruikt. Zo kunt u de wijziging die u hebt aangebracht koppelen aan het resultaat. Zonder die informatie kunt u een onverwacht resultaat van volgende dinsdag niet herleiden. Het hoort thuis in wat een bruikbaar runverslag bevat. Maak de overgang naar live bewust en zichtbaar. Getest en live zijn twee verschillende toestanden. De overgang daartussen moet een duidelijke handeling zijn van een bekende persoon, met een tijdstempel. Het scherm moet laten zien welke versie live staat en waarschuwen als opgeslagen wijzigingen nog niet live zijn. Een publicatie moet effect hebben op het moment dat het systeem meldt dat deze is doorgevoerd, niet pas na een herstart. Test via hetzelfde pad als in productie. Gebruik dezelfde soort identiteit, hetzelfde kanaal, hetzelfde model en dezelfde rechten als voor echte gebruikers. Kan dat niet, leg dan vast wat er verschilt. Zo weet u waar u als eerste moet zoeken wanneer er iets misgaat. Bewaar de workflow als bestand. Als u een workflow kunt exporteren, kunt u die in Git bewaren, versies regel voor regel vergelijken, wijzigingen beoordelen voordat ze live gaan en zo nodig terugdraaien. Een workflow die alleen in een database bestaat, is moeilijker te beoordelen en te herstellen. Een klein team kan beginnen met alleen punt 3 en 4. Samen maken die het verschil tussen 'de agent doet iets vreemds' en 'de versie die we dinsdag live hebben gezet, doet iets vreemds'.

Er zit wel een spanningsveld. Versiebeheer kost in het begin extra tijd. Ontwikkelaars willen een prompt aanpassen en meteen het resultaat zien. Een verplichte releasestap kan aanvoelen als papierwerk voor iets wat 'maar een prompt' is. Maar de kosten van het overslaan van die stap komen later, in de vorm van onzekerheid. Niemand kan dan zeggen welke versie van de agent de klant heeft geantwoord. Die onzekerheid kost meer tijd dan een releasestap.

'Laat zien welke versie nu live staat en welke versie de runs van gisteren hebben gebruikt.' Een goed antwoord bestaat uit een scherm, niet uit een belofte. U ziet welke versie live staat en bij elke eerdere run welke versie is gebruikt. 'Ik wijzig de prompt en sla hem op. Staat de wijziging dan live?' Een goed antwoord is een duidelijk ja of nee op het scherm, met een zichtbare waarschuwing als opgeslagen wijzigingen nog niet live zijn. 'Wat gebeurt er met mijn live agent als de leverancier het model bijwerkt?' Een goed antwoord vermeldt welke modelversie is vastgezet en maakt duidelijk dat een wijziging pas gevolgen heeft voor de live agent als u daarvoor kiest.

U kunt benoemde versies van een flow opslaan en een eerdere versie herstellen. Alleen opslaan maakt geen nieuwe versie aan. Sla daarom een benoemde versie op voordat u een wijziging aanbrengt die u mogelijk wilt terugdraaien.

Elke run bewaart een kopie van de flow zoals die op dat moment werd uitgevoerd. Deze kopie is niet gekoppeld aan een benoemde versie. EpicStaff heeft geen test- of stagingomgeving en geen afzonderlijke stap waarmee u een flow naar live promoveert.

Wilt u een testversie gebruiken, houd dan een aparte testflow aan. Sla ook een benoemde versie van de live flow op voordat u deze wijzigt, zodat u die versie kunt herstellen als dat nodig is.

U kunt een flow exporteren naar een JSON-bestand en later weer importeren. Geheime waarden worden daarbij niet opgenomen. Zo kunt u de flow samen met uw code bewaren.

Vraag voor de derde demovraag aan uw modelleverancier of u een specifieke modelversie kunt vastzetten.