AgentOps

Wat is AgentOps?

AgentOps is de manier van werken om AI-agents in productie draaiende te houden en te laten doen wat ze moeten doen. Het is ook een productnaam, een agentplatform op agentops.ai met een open source SDK, dus je zal het woord ook als leverancier tegenkomen. Deze uitleg gaat over de praktijk.

Het verschil met een gewone dienst draaiende houden zit in wat je precies beheert. Bij een webservice beheer je een request, en als die faalt krijg je een fout. Bij een agent beheer je een run, en een run gedraagt zich op vier punten anders.

• Het is een ketting van stappen, niet één oproep. Eén opdracht kan een tiental model- en tool-oproepen zijn, en enkel de twaalfde liep fout.

• Dezelfde input geeft niet hetzelfde pad. Twee runs van dezelfde vraag kunnen andere tools in een andere volgorde gebruiken en allebei kloppen.

• De fout is meestal een verkeerde actie, geen foutmelding. De agent mailde de verkeerde contactpersoon, of antwoordde uit het hoofd in plaats van de prijslijst na te kijken.

• De kost varieert per run, niet per deployment. Een agent die beslist om vijf keer opnieuw te proberen, kost vijf keer zoveel voor hetzelfde werk.

Daaruit volgen vier dingen die je moet kunnen: zien wat een run echt gedaan heeft, zeggen of het resultaat klopte, weten wat het kostte en op wiens rekening, en de prompt, de tools of het model wijzigen zonder kapot te maken wat al werkte. Laat dat laatste weg en de eerste drie worden een museum. Je ziet in hoge resolutie wat er misging, zonder veilige manier om er iets aan te doen.

Wat moet er in een trace staan als er iets misloopt

Een trace is de opname van één run. De test is niet hoe ze op een dashboard staat, wel of iemand er drie weken later een klantklacht mee kan beantwoorden. Zes dingen horen erin, onder één identifier, zodat ze samen bovenkomen.

• De input zoals die binnenkwam, ook het stuk dat uit een document of een mailbox kwam en niet van een mens.

• Elke tool-oproep met de argumenten en het resultaat. Weten dat de agent de factuurtool aanriep zegt niets. Weten dat hij die tool aanriep met het verkeerde leveranciersnummer zegt alles.

• De beslissingsmomenten: welke stap van het model die tool koos, en wat het model op dat moment voor zich had.

• De identiteit die handelde, en in wiens naam.

• Het aantal tokens en de kost van de run.

• De afloop, inclusief of de run afgerond is of tegen een limiet aanliep.

De tooling denkt al zo. In de OpenAI Agents SDK heeft een trace een workflow_name, een trace_id en een optionele group_id die meerdere traces uit hetzelfde gesprek aan elkaar knoopt, en het werk erbinnen wordt opgeslagen als spans voor de agentrun, elke modeloproep, elke tool-oproep en elke guardrail. Die spans bevatten de echte input en output, wat bij een zakelijke agent klantgegevens betekent. Beslis dus tijdens de bouw al wat je bijhoudt en hoe lang.

Evaluatie zodra het live staat

Een vaste testset die je voor elke deploy draait is nodig en niet genoeg. Daar zitten de gevallen in waar je zelf aan gedacht hebt. In productie zitten de andere, en die mix verschuift naarmate je klanten andere dingen vragen.

Er horen dus twee zaken naast. De eerste is een manier om echte runs te samplen en te beoordelen. Microsoft noemt dat continuous evaluation, kwaliteits- en veiligheidsscores op een deel van het productieverkeer, en LangSmith doet hetzelfde met een sampling rate tussen 0 en 1 op gefilterde traces. Samplen is het ontwerp, geen compromis: elke run beoordelen betekent bij elke run een tweede modeloproep betalen. Tien procent van je runs, echt willekeurig gekozen, zegt meer dan alle runs die toevallig goedkoop te vangen waren. De tweede is een geplande run van je vaste testset tegen productie, die een terugval oppikt voordat het live verkeer ze zichtbaar maakt.

Ook wat je meet verandert. Microsoft Foundry splitst het in twee, en die splitsing is ook bruikbaar als je nooit met Azure werkt. Systeemevaluatie kijkt naar het einde van de run: is de taak afgewerkt, heeft de agent begrepen wat de persoon wou, en is hij binnen zijn regels gebleven. Procesevaluatie kijkt naar de stappen: koos hij de juiste tools, riep hij ze op met de juiste parameters, en gebruikte hij wat er terugkwam. Een agent kan elke systeemcheck halen terwijl het proces eronder stilletjes verslechtert, en daar zie je het eerst.

Een promptwijziging is een deploy

Een system prompt aanpassen voelt aan als een document aanpassen. Het is een productiewijziging met dezelfde reikwijdte als een code-deploy, en er horen drie dingen rond.

Een versie. Elke prompt, tool-beschrijving en modelkeuze krijgt er een, samen bewaard. In LangSmith wordt elke bewaarde wijziging een commit met een eigen hash, en een tag kan naar een andere commit verplaatst worden, zodat je verandert welke versie in productie draait zonder je code aan te raken. In Foundry ligt een agentversie vast zodra ze bewaard is, en spreek je ze aan als agent_name:version.

Een gefaseerde uitrol. Stuur eerst een deel van het verkeer naar de nieuwe versie. Foundry laat je daarvoor requests op een specifieke agentversie richten. In een klein systeem betekent gefaseerd gewoon dat één team het een week gebruikt.

Een rollback die iemand al eens gedaan heeft. Niet de theorie dat de oude prompt ergens in Git staat. De oude versie binnen tien minuten opnieuw live, door iemand anders dan wie ze geschreven heeft.

Een agent die stilletjes slechter wordt na een modelupdate

Een offerte-agent leest een binnenkomende mail, zoekt prijzen op met een tool en schrijft een antwoord klaar dat een verkoper nog moet versturen. Na vier maanden schuift de modeldeployment eronder naar een nieuwe standaardversie, ofwel omdat iemand ze geüpgraded heeft, ofwel omdat de deployment ingesteld stond om de standaard vanzelf te volgen.

Er gaat niets stuk. Elke run geeft antwoord, de latency blijft gelijk, er gaat geen enkel alarm af. Maar het nieuwere model antwoordt sneller vanuit wat het al in de mailconversatie las, dus bij vage aanvragen slaat het de prijsopzoeking over en schrijft het een plausibel getal neer. Stel dat je gesamplede runs gaan van negentien op twintig die de prijstool aanroepen naar dertien op twintig. Zeven offertes op twintig worden nu zonder opzoeking geschreven, en niemand komt het te weten tot een klant je houdt aan een prijs die nooit in het systeem stond.

Procesevaluatie op gesamplede runs ziet het aantal tool-oproepen binnen een dag zakken, terwijl de antwoorden nog altijd goed lezen. De geplande run van de vaste testset faalt op elk geval dat een opzoeking nodig heeft, de ochtend na de omschakeling. De modelversie op elke trace legt de terugval naast de wijziging, wat een week discussiëren omzet in een zoekopdracht van vijf minuten. En de rollback brengt je terug: Azure verwittigt klanten minstens twee weken voor een nieuwe versie de standaard wordt, en houdt de vorige hoofdversie beschikbaar tot ze uit dienst gaat, dus er is iets om op vast te zetten terwijl je de prompt herwerkt.

AgentOps versus MLOps

De twee worden behandeld als dezelfde job met een nieuwer woord. Ze verschillen in waarop je monitort.

MLOps kijkt naar de input en de score. Het model is van jou, getraind op data die jij in handen hebt, en het gaat achteruit naarmate de wereld van die data wegdrijft. Dus volg je verdelingen op: schuift de input, zakt de accuraatheid op gelabelde uitkomsten, is het tijd om te hertrainen. Model drift is waar je op jaagt en hertrainen is de knop die je indrukt.

AgentOps kijkt naar gedrag en acties. Het model is van iemand anders en je kan het niet hertrainen. Wat verandert is het pad dat een run neemt, naar welke tools hij grijpt, of hij binnen zijn instructies bleef en wat dat kostte. De achteruitgang komt van buiten, en je knoppen zijn de prompt, de set tools, de modelversie en de rechten.

Plat gezegd: MLOps vraagt of de voorspellingen nog kloppen, AgentOps vraagt of de acties nog kloppen.

Wie volgt de agent op als hij draait

Er moet iemand bij naam aangeduid worden. Geen team, een persoon, met een vervanger. Een agent zonder eigenaar is een agent die niemand uitzet, want uitzetten is een beslissing en een beslissing heeft een naam nodig.

Leg vast wat down betekent voor je het nodig hebt. Bij een agent is de interessante toestand dat hij antwoordt en slecht antwoordt, dus schrijf de drempel op: onder deze score op gesamplede runs, of boven zoveel escalaties per dag, geldt de agent als down en wordt hij gepauzeerd. Microsoft hanteert dezelfde vorm in zijn dashboardrichtlijnen en behandelt een slaagpercentage onder vijfennegentig procent als iets om te onderzoeken. Luide fouten zijn binnen het uur opgelost, want er staat iemand te roepen. De dure draaiden zes weken door terwijl alles er gezond uitzag, en daarom bestaat dat samplen.

Ben je een kleinere onderneming, laat de platformvraag dan even liggen. Je hebt geen AgentOps-product nodig om aan AgentOps te doen. Je hebt een run-geschiedenis nodig die iemand wekelijks echt bekijkt, een manier om de agent stil te leggen die ook werkt als de bouwer met verlof is, en een eigenaar met naam. We zien veel meer schade van een agent waar niemand naar keek dan van een agent met een simpele toolset.