Een productie-agent stel je buiten gebruik door elke route af te sluiten waarlangs hij werk kan starten, kan inloggen of geld kan kosten, en daarna per route te bewijzen dat ze dicht is door het te proberen. Een productie-agent is een AI-agent (software die een doel meekrijgt, zelf de stappen kiest en tools gebruikt) die echt werk doet op live systemen: mail versturen, gegevens wijzigen, betaalde diensten aanroepen. Op stop drukken bij de lopende run is nog geen buitengebruikstelling. De volgende geplande run, een bewaarde sleutel of een maandabonnement kan hem aan het werk houden en de kosten laten doorlopen.
De volgorde: bevries nieuwe invoer, handel geaccepteerd werk af, leid aanroepers om, trek toegang in, stop de kosten, bewaar het dossier en test daarna elke oude route. Verderop staat de checklist op één scherm.
Waarom is “we hebben hem uitgezet” niet genoeg?
Neem een hypothetische agent die bij een bedrijf met tien medewerkers betalingsherinneringen verstuurt. Het boekhoudpakket verstuurt de herinneringen voortaan zelf, dus de agent is overbodig. Iemand stopt de lopende taak en zet in de teamchat: “de herinneringsagent staat uit”. Drie dingen lopen gewoon door.
- De planning. Maandag om 9.00 uur start de planner (de dienst die taken op vaste tijden in gang zet) een nieuwe run, en een klant krijgt een dubbele herinnering.
- Een gekopieerde sleutel. De API-sleutel van de agent (een wachtwoord voor software) staat ook in een spreadsheet van de financiële afdeling, die het model onder de naam van de agent blijft aanroepen.
- Het abonnement. De aanbieder blijft een maandabonnement factureren dat voor de agent is afgesloten, want stoppen met gebruiken zegt geen abonnement op.
Niets hiervan is bijzonder. Het zijn allemaal routes waar de stopknop nooit bij kwam.
Houd de drie klussen uit elkaar
| Klus | Wat het vaststelt | Wat het openlaat |
|---|---|---|
| Een run stoppen | Deze uitvoering is afgelopen | Een andere trigger kan een nieuwe run starten |
| Een eigenaar aanwijzen | Iemand is aanspreekbaar op de agent | Sleutels en planningen kunnen actief blijven en kosten kunnen doorlopen |
| De agent buiten gebruik stellen | Werk, toegang en kosten zijn afgesloten en getest | Het dossier en de laatste factuur hebben nog een eigenaar nodig |
Geef elke klus een eigen status in één ticket. Een eigenaar die een gestopte run aftekent, trekt daarmee geen sleutel in. Deze pagina gaat over de geplande, definitieve stopzetting; een ontsporende agent midden in een run stilleggen is een ander verhaal.
Begin bij het charter van de agent, het geschreven contract dat zegt wat hij doet en wat hij niet mag. De invoer en het bevoegdheidsplafond laten zien waar de agent bij mocht. De inventarisatie hieronder laat zien waar hij werkelijk bij kan.
Stap 1: breng in kaart wat nog kan starten, inloggen of factureren
Stel de lijst op vanuit de systemen zelf. In een register kan een gekopieerde sleutel ontbreken, of een aanroeper die bij een ander team hoort. Controleer vier groepen.
- Triggers (alles wat een run start): geplande taken op het platform, cronjobs (tijdgestuurde taken op een server), processen die taken uit een wachtrij oppakken, webhooks (een webadres dat een ander systeem aanroept om werk te starten) en inboxregels.
- Toegangsgegevens (alles waarmee hij kan inloggen of handelen): API-sleutels, OAuth-machtigingen (toestemming die iemand een app geeft om namens die persoon te handelen) met hun refresh-tokens, serviceaccounts (accounts van software, niet van mensen), cloudrollen en sleutels in de instellingenbestanden die AI-apps aan tools koppelen.
- Aanroepers (alles wat hem werk stuurt): andere agents, notebooks, spreadsheets, workflows van klanten en taken die mislukte aanroepen automatisch herhalen.
- Kosten: accounts bij modelaanbieders, abonnementen, vooruitbetaalde rekencapaciteit, zoekindexen en andere diensten die voor de agent zijn afgenomen.
Noteer per onderdeel de eigenaar, het ID, de geplande actie en het bewijs waarmee je het afsluit. Spoor elke sleutel na in de geheimenkluis, de deployment-instellingen, notebooks en lokale bestanden. Schrijf ID’s op, nooit de geheime waarden zelf.
Markeer gedeelde sleutels. Een sleutel uit één bestand verwijderen laat elke andere kopie gewoon werken. Intrekken schakelt elke kopie tegelijk uit, ook de kopieën waar live systemen nog op draaien; het playbook van TrueFoundry zegt het onomwonden: de kopieën zijn dezelfde sleutel. Zet die systemen dus eerst over op vervangende toegang, controleer of ze werken en trek de sleutel pas daarna in. Houd de vervangende sleutel buiten de instellingen van de agent die stopt.
Stap 2: bouw de agent in een vaste volgorde af
Het playbook van TrueFoundry, geschreven door Boyu Wang (8 augustus 2026), noemt zes stappen: inventory, redirect, revoke, retain, tombstone en verify. De volgorde hieronder volgt die reeks, splitst “redirect” op in drie concrete stappen en voegt het stoppen van kosten toe als aparte stap.
- Bevries nieuwe invoer. Schakel de triggers uit die nieuw werk aannemen en noteer het tijdstip. Houd alleen de toegang aan die nodig is om al geaccepteerd werk af te ronden.
- Handel geaccepteerd werk af. Maak een lijst van lopende taken, taken in de wachtrij en geplande herhalingen. Rond elke taak af, draag haar over of annuleer haar, en noteer wie een overdracht overneemt. Kijk in de wachtrij zelf, niet alleen op het dashboard.
- Leid aanroepers om. Verwijs elke aanroeper naar een geteste vervanger, of laat hem een duidelijke melding “buiten gebruik” terugkrijgen. Verwijder herhalingen die nog op de oude agent mikken. Laat de eigenaar van elke aanroeper het nieuwe gedrag bevestigen.
- Trek toegang in. Trek de eigen sleutels en machtigingen van de agent in, ook refresh-tokens die nieuwe toegang kunnen ophalen. Controleer daarna wat er gebeurt met toegangstokens die al zijn uitgegeven. Volgens de OAuth-standaard voor intrekken, RFC 7009, hoort een server die dat ondersteunt bij een ingetrokken refresh-token ook de toegangstokens van dezelfde machtiging ongeldig te maken (in de standaard staat SHOULD, geen MUST). Het addertje onder het gras zit in “hoort” en “die dat ondersteunt”: ga ervan uit dat een uitgegeven token kan blijven werken tot het verloopt, tenzij je aanbieder iets anders zegt. Verwijder roltoewijzingen en noteer per sleutel het ID, de actie en het tijdstip.
- Stop de kosten. Blokkeer verder gebruik en zeg de eigen abonnementen, licenties en reserveringen van de agent op. Controleer wat elke budgetinstelling echt doet, want veel budgetten waarschuwen alleen. Volgens de eigen documentatie van Google Cloud begrenst een budget dat alleen waarschuwingen stuurt het gebruik of de uitgaven niet automatisch. Haal bij gedeelde diensten alleen het aandeel van de agent weg, zonder iets af te sluiten wat live systemen nog nodig hebben.
- Bewaar het dossier. Bewaar het ticket en de logboeken, traces en prompts die je beleid voorschrijft of toestaat. Leg vast waar het archief staat, wie erin mag, welke bewaartermijn geldt en, als het beleid dat vraagt, wanneer het wordt verwijderd. Markeer daarna de registerregel als buiten gebruik, met eigenaar, datum en reden. Die regel, de tombstone, helpt voorkomen dat iemand de agent per ongeluk opnieuw inzet. Hij schakelt geen enkele sleutel uit.
Draait een leverancier een deel van de agent, zet dan ook diens actie en bevestiging in het ticket. Sluit je alleen je eigen kant af, dan kan het gehoste account, de planning of het abonnement aan zijn kant blijven doorlopen.
Stap 3: controleer door het te proberen
Roep de oude webhook en het oude startpunt aan zonder ze weer in te schakelen. Doe een verzoek met het oude toegangstoken. Probeer het oude refresh-token. Roep het oude endpoint aan vanaf een client die vroeger wel binnenkwam. Gebruik onschuldige verzoeken die je kunt terugvinden, voor het geval een blokkade toch niet werkt.
Kijk naar het effect, niet alleen naar het antwoord. Er mag niets starten, geen enkele oude sleutel mag nog toegang geven en het refresh-token mag geen bruikbaar token meer opleveren. Komt een aanroeper nu bij een vervanger uit, controleer dan welk systeem het verzoek echt heeft afgehandeld.
Lees daarna de logboeken vanaf het tijdstip van de invoerstop, zoals de verify-stap van TrueFoundry dat doet. Succesvol verkeer op naam van de agent hoort nul te zijn, en pogingen met ingetrokken sleutels horen alleen als mislukte authenticatie te verschijnen. Elk geslaagd verzoek betekent dat het intrekken onvolledig is of dat er nog een andere sleutel werkt.
Controleer gebruik en facturen apart. De laatste factuur kan nog werk van vóór de stop bevatten. Koppel elke resterende kostenpost aan de bijbehorende factuurperiode en verklaar elke reservering of elk abonnement dat nog doorloopt. Leg per poging vast: het tijdstip, het verwachte resultaat, het waargenomen resultaat en de bijbehorende logregel.
De checklist voor buitengebruikstelling
| Route | Afsluiten door | Bewijs dat ze dicht is |
|---|---|---|
| Planningen en tijdgestuurde taken | Uitschakelen, daarna verwijderen | Het volgende geplande tijdstip gaat voorbij zonder run in het logboek |
| Webhooks en wachtrijen | Het adres of het verwerkende proces verwijderen | Een onschuldige testaanroep start niets |
| Aanroepers | Naar de vervanger of naar een duidelijke melding “buiten gebruik” verwijzen | De eigenaar van elke aanroeper bevestigt het nieuwe gedrag |
| Sleutels en machtigingen | Gedeelde gebruikers eerst overzetten, dan intrekken | De oude sleutel en het oude refresh-token worden geweigerd |
| Accounts en rollen | Het serviceaccount uitschakelen, de rollen weghalen | Inloggen mislukt en er is geen roltoewijzing meer |
| Kosten | Abonnementen, licenties en reserveringen opzeggen | Elke regel op de laatste factuur hoort bij een factuurperiode |
| Dossier | Archiveren volgens beleid, registerregel op “buiten gebruik” | De archieflocatie en de verwijderdatum staan op papier |
Sluit het ticket op basis van bewijs
Gebruik één ticket, met het register-ID van de agent, de persoon die de buitengebruikstelling goedkeurde, het tijdstip van de invoerstop en per regel hierboven een verwijzing naar het bewijs. Geef elk open punt een eigenaar en een volgende controle; een opzegging die pas aan het eind van een factuurperiode ingaat, heeft een vervolgdatum nodig, en een ingediend verzoek sluit op zich niets af. Sluit het ticket pas als elke oude route is geprobeerd en dicht bleek, en elke resterende kostenpost is verklaard.
Waar past buitengebruikstelling in ROSTER?
ROSTER is het framework uit Het agent-droomteam (nu verkrijgbaar) om AI-agents in te zetten als benoemde specialisten. Het legt per agent zes besluiten vast (de naam komt van de Engelse beginletters):
- Rollen: één taak per agent, met een charter dat zegt waar de rol wel en niet over gaat.
- Doelstellingen: een resultaat dat je kunt beoordelen.
- Vaardigheden en tools: alleen de toegang die de taak vraagt.
- Triggers: de gebeurtenis die de agent start.
- Evaluatie: een vaste scorecard, elke week ingevuld.
- Rotatie: verbeter de rol, voeg haar samen of stel haar buiten gebruik zodra het bewijs daarom vraagt.
Je hebt het boek niet nodig om ermee te werken. Rotatie beslist óf een rol stopt; deze pagina gaat over het hoe. De regel uit het boek: één week onder de ondergrens van de scorecard is aanleiding voor een diagnose, twee weken op rij of vier van de laatste zes vragen om een besluit om te verbeteren, samen te voegen of buiten gebruik te stellen. Het boek voegt een controle toe die veel werk scheelt: heeft de aanbieder het model eronder gewijzigd of uitgefaseerd, behandel dat dan als een gedwongen migratie (zet de rol over op een nieuw model en test opnieuw) en niet als buitengebruikstelling. Stopt een rol wel, dan gaat het charter volgens het boek naar een archief, met een alinea over het waarom, en verdwijnt de rol van de triggerkaart.
Pas dat toe op de herinneringsagent. Het rotatiebesluit luidt: “buiten gebruik: het boekhoudpakket doet dit werk nu zelf”. Bij Triggers staat de maandagplanning die weg moet. Bij Vaardigheden en tools staat de sleutel die je intrekt. De outputregel in het charter vertelt wie zijn werk ontving. Een goed charter is je eerste inventarisatie, en daarom staat het op de ROSTER-frameworkpagina vooraan.
Leg de volgende einddatum vast zodra je de agent maakt
In zijn essay voor de Forbes Technology Council betoogt Akhilesh Sharma dat elke applicatie, agent, automatisering en integratie bij het aanmaken een houdbaarheidsdatum moet krijgen (in het Engels een time-to-live), een benoemde eigenaar met het mandaat om te verlengen, te beperken of buiten gebruik te stellen, en een gefaseerde buitengebruikstelling.
Neem die besluiten zodra je het charter van de volgende agent schrijft. Wijs de eigenaar voor verlenging aan, leg een evaluatiedatum vast en noteer welke toegangsgegevens, aanroepers en factuuraccounts een buitengebruikstelling zal raken. De exitregel uit agentstrategie is hetzelfde idee op portfolioniveau. En draait een agent op rechten die een medewerker ooit heeft aangemaakt, zet hem dan op de offboardingchecklist van die persoon: wie het account van een medewerker sluit, kan een serviceaccount gewoon actief laten.
Probeer dit vandaag: een proefrun van 15 minuten
Kies één agent die nog draait, ook als hij goed werkt.
- Schrijf zijn triggers, toegangsgegevens (alleen ID’s), aanroepers en kosten op, elk op één regel.
- Zet achter elke regel wie de eigenaar is en hoe je hem zou afsluiten.
- Een regel zonder eigenaar is het eerste wat je oplost. Een regel die je niet kunt invullen, is een route die je op de dag van buitengebruikstelling zou missen.
Bewaar het blad. Op de dag dat de agent stopt, is het je ticket.
Citeer deze pagina:Hoe je een productie-agent buiten gebruik stelt (stoppen is niet genoeg).Len P. van der Hof. https://lenvanderhof.com/nl/blog/productie-agent-buiten-gebruik-stellen/ ·