De Agent Trap: Een productie-gereedheids checklist (met gatekeeping niveaus)

Gepubliceerd: 15 januari 2026

We zijn er allemaal wel eens geweest. Je besteedt een middag aan het in elkaar zetten van een AI-agent. Je koppelt een paar tools, schrijft een slimme system prompt, en—magie. Het haalt correct een Jira-ticket op, vat het samen en stelt een Slack-bericht op. Het voelt als de toekomst.

Dan ga je live.

Twee dagen later hallucineert de agent een beleidsovertreding, loopt in een oneindige lus totdat het $50 aan tokens heeft verbrand, of crasht omdat de LLM json teruggaf in plaats van JSON.

De kloof tussen een Twitter-demo en een betrouwbare service is enorm. Het is gevuld met edge cases, rate limits, kwaadaardige inputs en verwarde gebruikers. Dit artikel stelt een praktisch pad voor om die kloof te overbruggen: een volwassenheidsmodel voor je agent en een harde checklist om je releases te sturen.

"Productie-gereed" herdefiniëren

In traditionele software betekent "productie-gereed" vaak dat de code tests doorstaat en de server draait. Voor probabilistische software (AI) moet de definitie verschuiven.

"Productie-gereed" voor een agent gaat niet over hoe slim het is. Het gaat over hoe saai het is.

  • Determinisme: Kun je de chaos begrenzen?
  • Insluiting: Als (niet wanneer) het faalt, is de blast radius dan beperkt?
  • Uitlegbaarheid: Kun je over zes maanden nog traceren waarom het die specifieke beslissing nam?
  • Economie: Zal een piek in verkeer je API-budget failliet maken?

De Gatekeeping Niveaus: Een Volwassenheidsmodel

Probeer niet in één sprong van localhost naar wereldwijde schaal te gaan. Gebruik deze niveaus om risico en gereedheid aan je stakeholders te communiceren.

Niveau 0 — Het Prototype (Het Lab)

Het Doel: Bewijs dat het idee niet verschrikkelijk is.

Dit is je interne hackathon-project. De code is rommelig, de prompts zijn broos, en dat is oké.

  • Capaciteiten: Het doet één specifieke taak (inputs en outputs zijn gedefinieerd).
  • Testen: Je hebt een handmatige lijst van "rare dingen die ik heb geprobeerd die het braken."
  • Publiek: Alleen interne ontwikkelaars. Geen klantdata.

Niveau 1 — Gecontroleerde Pilot (De Zijwieltjes)

Het Doel: Reality checks zonder het risico.

Dit is waar de meeste teams falen. Ze slaan dit over en gaan live. Niveau 1 introduceert Shadow Mode of strikte Human-in-the-Loop (HITL).

  • Shadow Mode: De agent draait op de achtergrond op echt verkeer. Het verwerkt data en logt wat het zou hebben gedaan, maar onderneemt geen actie. Dit bouwt je evaluatiedataset op zonder gebruikers boos te maken.
  • HITL: Als het moet handelen, beoordeelt een mens het concept. Elke keer.
  • Veiligheid: Je hebt een strikte "allowlist" van tools. Geen generieke "browse the web" capaciteiten tenzij absoluut noodzakelijk.

Niveau 2 — Beperkte Productie (De Soft Launch)

Het Doel: Betrouwbaarheid als een Service.

Nu heb je echte gebruikers, maar je hebt vangrails.

  • Betrouwbaarheid: Je hebt gedefinieerde SLO's (bijv. 95% van de antwoorden gegenereerd in <5s).
  • Veerkracht: Je hebt "slimme retries." Als de LLM slechte JSON uitvoert, crash je niet gewoon—je voert de fout terug naar de LLM en vraagt het om zichzelf te corrigeren.
  • Evaluatie: Je hebt een "Golden Set" van testcases die in CI draaien. Als een prompt-wijziging de nauwkeurigheid met 2% verlaagt, faalt de build.
  • Publiek: Beta-gebruikers, niet-kritieke workflows, of een klein % van het verkeer.

Niveau 3 — Geschaalde Productie (Het Platform)

Het Doel: Schalen zonder schaalincidenten.

Dit is enterprise-grade.

  • Operaties: Je hebt on-call runbooks voor wanneer de agent ontspoort.
  • Verdediging: Je bent actief bezig met red-teaming van je eigen prompts om injection kwetsbaarheden te vinden.
  • Economie: Je handelt provider rate limits gracieus af (queues, backoff, load shedding).

De Gereedheids Checklist

Als je naar Niveau 2 (Productie) gaat, zijn deze items niet optioneel.

1. Scope & Succes

  • [P0] Begrensde Taak: De agent heeft één enkel, één-zins-doel. Vermijd het bouwen van "god-bots."
  • [P0] Contract: Inputs en outputs zijn strikt getypeerd (met schema's zoals Pydantic of Zod).
  • [P0] Het "Ik Weet Het Niet" Pad: De agent is expliciet geïnstrueerd over hoe taken te weigeren die het niet kan doen, in plaats van een poging te hallucineren.

2. Tooling & Side Effects

  • [P0] Geen Open Toegang: Elke tool beschikbaar voor de agent staat op een allowlist. Geen exec() of generieke HTTP-verzoeken.
  • [P0] Eerst Valideren: De tool-inputs van de agent worden gevalideerd tegen een schema voordat de tool wordt uitgevoerd.
  • [P0] Idempotentie: Als de agent een "Create Ticket" stap opnieuw probeert, krijg je niet 5 dubbele tickets.
  • [P1] Circuit Breakers: Als een tool 10 keer in een minuut faalt, stopt de agent met proberen het aan te roepen.

3. Data & Privacy

  • [P0] Data Mapping: Je weet precies welke data het contextvenster binnenkomt.
  • [P0] Sanering: PII en Secrets worden geredigeerd voordat ze de LLM provider's API raken.
  • [P0] Least Privilege: De agent gebruikt API-sleutels met de absolute minimale vereiste scope (bijv. Read-Only toegang tot de database).

4. Veiligheid & Verdediging

  • [P0] Injection Verdediging: Gebruikersinput is duidelijk afgebakend in de prompt (bijv. gewikkeld in XML-tags) zodat het model weet wat instructie is vs. wat data is.
  • [P0] Secret Veiligheid: De agent heeft geen toegang tot secrets of omgevingsvariabelen, zelfs niet indirect.
  • [P1] Escalatiepad: Wanneer de agent een verzoek weigert vanwege veiligheidsbeleid, krijgt de gebruiker dan een nuttige foutmelding of een stille failure?

5. Evaluatie & Versiebeheer

  • [P0] De Golden Set: Je hebt een dataset van inputs (happy paths, edge cases, en vijandige aanvallen) met bekend-goede outputs.
  • [P0] CI/CD Integratie: Je draait de Golden Set tegen elke prompt- of modelwijziging.
  • [P0] Versiebeheer: Je behandelt prompts als code. Je weet precies welke versie van een prompt een specifieke output in je logs genereerde.

6. Human-in-the-Loop (HITL)

  • [P0] Zichtbaarheid: Als een mens moet ingrijpen, toont de UI hen de volledige context—wat de gebruiker vroeg, en wat de agent probeerde te doen.
  • [P0] Override Autoriteit: De mens kan de voorgestelde actie van de agent bewerken of volledig verwerpen.
  • [P1] Feedback Loops: Wanneer een mens de agent corrigeert, wordt die data vastgelegd om toekomstige evaluatiesets te verbeteren.

7. Observeerbaarheid

  • [P0] Tracing: Je hebt end-to-end traces (met tools zoals LangSmith, Arize, of Honeycomb) die het gebruikersverzoek -> modelgedachte -> tool call -> resultaat linken.
  • [P1] Kostenbewaking: Je volgt tokengebruik per feature/tenant en hebt alerts voor kostenpieken.
  • [P1] Quotumbeheer: Je handelt provider rate limits af voordat ze je app crashen.

De "Go / No-Go" Beslissing

Voordat je op deploy drukt, kijk naar je team en vraag:

  • 🟢 GO: We hebben een Golden Set die slaagt. We hebben de agent gedwongen schema's te gebruiken. Als het faalt, hebben we traces om te zien waarom.
  • 🟡 ALLEEN PILOT: Het werkt goed, maar we hebben nog geen geautomatiseerde tests. We zullen dit alleen verzenden met strikte Human-in-the-Loop goedkeuring voor elke actie.
  • 🔴 NO GO: De agent heeft schrijftoegang tot de database, maar we hebben niet getest wat er gebeurt als de LLM SQL hallucineert. (Niet verzenden.)

Slotgedachten

De belangrijkste stap in deze hele lijst is Evaluatie (Sectie 5).

De meeste teams slaan het bouwen van een test harness over omdat het saai is. Ze geven de voorkeur aan het tweaken van prompts om te zien of "het beter aanvoelt." Val niet in deze val. Je kunt geen betrouwbaarheid engineeren als je het niet kunt meten. Bouw de harness, bouw dan de agent.