Agents in productie beheren

De lancering is het begin van het werk

Een agent die zijn evaluatieset haalt, is klaar voor een pilot, niet voor een rustig bestaan. Modellen veranderen, documenten veranderen, gebruikers vinden nieuwe formuleringen en een tool waarvan je afhankelijk bent, krijgt een nieuwe versie. In productie moet je zien wat de agent doet, hem kunnen stoppen als hij misgaat en snel kunnen repareren.

Deze les zet de eerdere bouwstenen om in een beheermodel: een gateway ervoor, budgetten en limieten, observability op elke stap en runbooks voor de dag dat er iets kapotgaat. Teamorganisatie behandelen we niet. We behandelen het technische en procedurele minimum dat we van elke agent vragen die we opleveren.

Het beheerplaatje

Gebruiker of systeem
   -> Agentruntime (lus, grenzen, goedkeuringen)
      -> Gateway (toegang, budgetten, limieten, beleid, logging)
         -> Modelendpoints (aanbieder, open-weight, eigen)
      -> Tools via MCP (afgebakende identiteiten)
      -> State stores (sessies, geheugen)
   -> Traces en logs -> scorers, dashboards, alerts -> een persoon in bereikbaarheidsdienst

Bij elke pijl wordt iets vastgelegd, begrensd of gecontroleerd.

Draai het als service

Op Databricks beschrijft de Agent Bricks-documentatie een Agent Server (met DurableAgentServer) die synchrone, streaming en achtergrondruns bedient met herstel na crashes, en een Agent Runtime die agents op door Databricks gehoste compute uitrolt. Agents zijn te bevragen via een invocation-API, de Responses API of SQL. Op welk platform je ook uitrolt, stel dezelfde vragen aan de runtime:

• Herstel na een crash. Als het proces halverwege een taak sterft, hervat, herstart of verdwijnt de taak? Lange taken hebben durable execution nodig.
• Idempotentie. Een hervatte run mag een schrijfactie niet herhalen. Tools nemen een idempotentiesleutel.
• Timeouts. Elke taak en elke toolaanroep heeft er een.
• Versiebeheer. Je kunt zeggen welke prompt-, model- en toolversies elk antwoord produceerden en je kunt één stap terugdraaien.
• Omgevingen. Dev, test, acceptatie en productie zijn gescheiden, met eigen identiteiten en data. Rol uit via een pipeline vanuit gereviewde code, nooit met de hand. Prompts en toolconfiguraties zijn code en gaan door dezelfde pull requests.

De gateway

Zet een gateway tussen agents en modellen. Unity Gateway biedt volgens de documentatie permissies als Unity Catalog-privileges, rate limits op model- en MCP-services, budgetten met drempels per gebruiker en harde plafonds, servicebeleid voor guardrails, logging van verzoeken en antwoorden naar Delta-tabellen, gebruiksregistratie in systeemtabellen en verkeerssplitsing met failover.

Voor beheer geeft dit je één plek om te beantwoorden: wie gebruikte welk model, hoeveel, wanneer en met welk resultaat. Het is ook de plek waar je iets stopt. Een hard plafond op een op hol geslagen agent is een instelling, geen incident.

Observability: zie elke stap

Log genoeg om elke run te reconstrueren, en niet meer dan privacy toestaat.

Draai dezelfde scorers die je vóór de release gebruikte op een steekproef van het productieverkeer. MLflow ondersteunt scorers op productietraces. Elke fout die je vindt, wordt een case in de evaluatieset.

Let op persoonsgegevens in logs. Maskeer voor je opslaat, stel een bewaartermijn in voor traces en beperk wie ze mag lezen. Traces bevatten vaak de gevoeligste tekst van het hele systeem.

Alerts die ertoe doen

Een alert moet tot een actie leiden. Begin met een korte lijst:

• Kosten per taak of tokens per taak boven de limiet gedurende een vastgesteld venster.
• Kwaliteitsscore op gesamplede traces onder de releasebaseline.
• Escalatie- of overrulepercentage boven normaal.
• Toolfoutpercentage van één tool boven normaal.
• Beleidsblokkades die plotseling stijgen.
• Elke raak op de harde plafonds.

Geef elke alert een eigenaar en een runbooklink. Een alert zonder eigenaar is ruis.

Runbooks

Een runbook is de geschreven procedure voor een bekende storing. Schrijf ze voor de lancering, in korte, directe zinnen met één actie per regel, en test ze in een oefening. De standaardset:

Voeg een eigenaar, een escalatiecontact en een noodstop toe die een niet-engineer kan gebruiken. Test de noodstop volgens schema.

Wijzigingsbeheer

Elke wijziging volgt hetzelfde pad: pull request, evaluatiepoort, kostenpoort, schaduwrun of verkeerssplitsing, daarna volledige uitrol. Dat geldt ook voor modelwissels (les 7), promptwijzigingen en nieuwe tools. Houd per agent een kort wijzigingslogboek bij. Als de kwaliteit verschuift, zegt het logboek waar je moet kijken.

Reviewritme

• Wekelijks: lees met de agenteigenaar een steekproef van traces, de escalaties en de geblokkeerde gebeurtenissen.
• Maandelijks: bekijk kosten per taak, de dekking van de evaluatieset en de geheugenstore.
• Per kwartaal: bekijk toegang, zoals in onze delivery standards, en verwijder rechten die niemand gebruikt.

Samenvatting

Beheer een agent als elke productieservice, met de extra zorg die een probabilistisch onderdeel vraagt: een gateway voor budgetten en beleid, traces en scorers voor zicht, alerts met eigenaren, runbooks die je hebt geoefend, een noodstop en één wijzigingspad.

Daarmee zijn de acht bouwstenen compleet. In het eindproject zet je ze samen.