Een AI-agent playground bouwen vóór de productiefase
Een coding agent voerde ooit een cleanup-script uit op wat hij dacht dat een staging-database was. Het was in werkelijkheid de productieomgeving. De agent verwijderde vier maanden aan klantbestellingen omdat hij precies deed wat hem werd verteld, maar dan met de verkeerde inloggegevens.
Dit falen is geen reden om agents te vermijden. Het is een reden om een playground te bouwen.
Je zou een nieuwe engineer op zijn eerste dag geen toegang geven tot de productie-database. Je geeft ze een staging-omgeving, read-only toegang en gesuperviseerde taken. Agents hebben dezelfde onboarding nodig. Ze kunnen duizend acties per minuut uitvoeren, dus de kosten van het overslaan van een playground zijn duizend keer hoger.
Een echte playground moet drie dingen doen:
- De agent zijn volledige beslissingslus (decision loop) laten doorlopen.
- Voorkomen dat alle neveneffecten (side effects) de echte systemen bereiken.
- Alles registreren voor inspectie.
Test niet alleen de prompt. Het testen van een prompt is een vraag stellen en een antwoord lezen. Het gedrag van een agent is een reeks tool calls. De echte fouten treden op in het midden van een lus wanneer een tool onverwachte gegevens teruggeeft.
Je hoeft het model niet te sandboxen. Je moet de executor sandboxen.
Plaats een scheidingspunt waar tool calls worden omgezet in acties. Gebruik een playground executor die mocks gebruikt in plaats van een live executor. De agent loop zou het verschil niet moeten merken. Als je agent rechtstreeks een database client aanroept, heb je geen scheidingspunt en geen veiligheid.
Test drie specifieke gebieden:
- Gedrag: Kiest de agent het juiste gereedschap in de juiste volgorde?
- Tool calls: Zijn de argumenten correct en binnen veilige grenzen?
- Foutmodi (failure modes): Wat gebeurt er als een API een timeout geeft of onzin teruggeeft?
Een mock die altijd slaagt, leert de agent niets. Je playground moet het mogelijk maken om fouten te injecteren, zoals netwerk-timeouts of ongeldige gegevens. Zo zie je of een agent op een verstandige manier opnieuw probeert of dat hij begint te hallucineren.
Als je agent code uitvoert, heb je sterke isolatie nodig. Gebruik microVM's voor onbetrouwbare code. Begin niet met eenvoudige containers alleen omdat ze makkelijk zijn. Een eenvoudige setup kan leiden tot een enorm beveiligingsincident.
Houd er rekening mee dat agents niet-deterministisch zijn. Een test die één keer slaagt, betekent niet dat de agent betrouwbaar is. Je moet dezelfde taak meerdere keren uitvoeren. Als een agent 7 van de 10 keer slaagt, zal hij falen voor ongeveer 30% van je echte gebruikers. Consistentie is je belangrijkste metriek.
Bescherm je tot slot tegen kwaadaardige (adversarial) tool-outputs. Een agent behandelt tool-gegevens als instructies. Een kwaadwillende gebruiker zou een database kunnen infecteren met een prompt injection om de agent te sturen. Test je agent door hem vijandige payloads te voeren in de playground.
Bouw een groeipad, geen lanceerknop:
- Begin met mocks en volledige sandboxing.
- Test op consistentie over vele runs.
- Test tegen adversarial inputs.
- Ga over naar een dry-run modus met data die lijkt op productie-data.
- Pas daarna verleen je beperkte, gecontroleerde en gemonitorde toegang.
Geef je agent een plek waar hij goedkoop fouten kan maken. Dan kan hij het goed doen waar het er echt toe doet.
Source: https://dev.to/nazar_boyko/building-an-ai-agent-playground-before-giving-it-production-access-4glh
Optional learning community: https://t.me/GyaanSetuAi