Bouw een proactieve agentlus op Claude Opus 5.5

Het ongemakkelijke deel van het bouwen van je eigen proactieve agent is dat het interessante werk niet de modelaanroep is. Je kunt Claude Opus 5.5 in een middag vragen laten beantwoorden. Het zover krijgen dat hij volgens een schema wakker wordt, alleen leest wat sinds de vorige keer is veranderd, beslist of iets menselijke aandacht verdient, de actie opstelt en dan stopt en wacht — dat duurt weken, en bijna niets daarvan gebeurt in het model. Anthropic bracht een versie van deze lus uit als Claude Duet, en wat nuttig is aan dat product voor iedereen die er zelf een bouwt, is niet de functielijst maar de beslissingen die zichtbaar zijn in hoe het in elkaar is gezet. Het heeft geen gepubliceerde API en kan niet op je eigen systemen worden gericht, dus als je de lus wilt en niet de app, bouw je hem zelf. Wat volgt is de architectuur, stap voor stap, met de eerlijke kosten van elke stap.

Eerst de vorm. Vijf fasen worden achtereenvolgens doorlopen, en de vijfde wordt pas bereikt nadat een mens ja heeft gezegd. Een scheduler activeert. Een digest-stap reduceert elk aangesloten systeem tot een delta. Een beslissingsstap zet die delta plus een beleid om in een getypeerd voorstel. Een goedkeuringspoort buiten het model beslist of het voorstel mag worden uitgevoerd. Een executor voert het uit. Dat is het hele ontwerp, en alles wat er moeilijk aan is, zit in de naden.

Fase één: een scheduler die om de paar uur afgaat

De eerste beslissing is er een die mensen vanuit enthousiasme in plaats van vanuit engineering verkeerd nemen: poll niet continu. De Duet-documentatie van Anthropic verklaart het interval — om de paar uur controleren — door te stellen dat non-stop controleren de limieten van het plan veel sneller zou verbruiken. Dat is geen voorzichtigheid uit marketing. Het is het juiste antwoord op een echt kostenprobleem, en het is de valkuil waarin elke zelfgebouwde agent in week één trapt.

Doorlopend pollen is rampzalig om een structurele reden. Elke sweep is een volledige context: instructies, tooldefinities, het materiaal dat je hebt opgehaald, en alle redeneringen die het model daarop loslaat. Bij een frequentie van één keer per minuut zijn dat 1.440 volledige contexten per dag, en de overgrote meerderheid daarvan vindt niets nieuws. Je betaalt de volle prijs om te horen te krijgen dat de mailbox niet is veranderd. Bij drie uur krijg je er acht, en de verhouding tussen bevindingen en kosten wordt iets wat je kunt verantwoorden aan wie de factuur ondertekent.

De scheduler is dus een timer in cron-stijl met een ondergrens voor het minimuminterval, geen eventstream. Events klinken aantrekkelijk — reageer op het moment dat er iets gebeurt — maar ze duwen je terug naar doorlopend werk en maken de kosten van een drukke dag onbegrensd. Een timer biedt een voorspelbaar plafond, en dat is wat je nodig hebt wanneer de rekening varieert. Wil je snellere reactie voor één bron, verkort dan alleen het interval van die connector en accepteer de extra kosten.

Fase twee: één byte-identieke prefix, in de cache gehouden

Hier doen de gepubliceerde cijfers het meeste werk. Claude Opus 5.5 op OrcaRouter kost 4,00 dollar per miljoen inputtokens, 20,00 per miljoen outputtokens, met een contextvenster van 1M tokens en cache-reads tegen 0,20 per miljoen, tegen de lijstprijs van de provider met 0 procent markup. Lees die cijfers als een ontwerpbeperking, niet als een prijslijst: een cache-read kost een twintigste van een verse inputtoken, dus elke byte die je bij opeenvolgende sweeps stabiel houdt, is een byte waarvoor je niet langer de volle prijs betaalt.

In de praktijk worden de systeemprompt en het toolschema één keer samengesteld op het moment van deployment en nooit opnieuw gegenereerd per sweep. Niet opnieuw geserialiseerd vanuit een dictionary met de sleutels in een andere volgorde. Niet als template gevuld met een tijdstempel, een request-ID of de accounts die vandaag verbonden zijn, middenin ingevoegd. Elke byte die afwijkt, maakt de gecachte prefix ongeldig, en het instructieblok valt bij elke sweep terug naar de volledige invoerprijs. Teams verliezen dit vaker per ongeluk dan met opzet, meestal doordat een behulpzame abstractie een run-ID begon te injecteren vlak bij de bovenkant van de prompt.

De discipline die contact met echte code overleeft, is saai: één functie die een constante string teruggeeft voor het stabiele blok, een bevroren literal voor het toolschema, elk variabel element erna geplaatst. Dan een test die het blok hasht en de build laat falen wanneer de hash verandert, omdat iemand uiteindelijk een schemaveld zal toevoegen en nooit aan de cache zal denken. Die test kost een uur en redt het volledige cachevoordeel.

Fase drie: een samenvatting per verbinding, geen mailboxdump

De derde fase is degene die een consumentenproduct gratis krijgt en jij niet. Duet leeft binnen het Anthropic-account en reikt tot verbonden apps, dus het kan vragen wat er sinds een bepaald moment is veranderd en een klein antwoord krijgen. Als je buiten dat account bouwt, praat je met dezelfde API's als elke normale client: of je implementeert incrementele reads, of je haalt alles op en geeft het model een muur van tekst.

Alles ophalen is de standaard, omdat het vanaf dag één werkt. Het is ook de snelste manier om de kosten per sweep onvoorspelbaar te maken, omdat de invoer meegroeit met de mailbox in plaats van met wat er is veranderd. Een sweep over veertig ongewijzigde threads kost hetzelfde als een sweep over veertig threads waarbij één thread relevant is, en slechts bij één daarvan was er enige kans op een nuttig voorstel. Na een maand daarvan ging het grootste deel van je budget naar het bevestigen van de status quo.

De digest-stap moet code zijn, geen prompting. Haal per verbinding op met welke cursor of delta de API ook biedt, en reduceer het resultaat tot een gestructureerde samenvatting: wat is verschenen, wat is gewijzigd, wat is opgelost. Geef elk item een stabiele identificatie zodat latere fasen ernaar kunnen verwijzen, en leg per verbinding de laatste succesvolle cursor vast, zodat een mislukte ophaalpoging niet het materiaal van gisteren opnieuw afspeelt alsof het nieuw is. Een digest die "er is niets gebeurd" niet kan onderscheiden van "ik kon het niet controleren", zal uiteindelijk met vertrouwen rapporteren over een toestand die hij nooit heeft waargenomen.

Fase vier: een beslissingsstap die een object oplevert, geen proza

Dit is waar Claude Opus 5.5 zit, en wat het produceert bepaalt of de rest van het systeem überhaupt kan worden gebouwd. De instinctieve neiging is om het model een samenvatting te laten schrijven en een mens die te laten lezen. Dat werkt voor een dashboard, maar faalt voor een poort: de volgende fase moet beslissen of een actie wordt toegestaan, en toestemming kan niet aan een alinea worden gegeven.

De beslisstap moet een getypeerd actievoorstel opleveren: een actienaam uit een gesloten lijst, het doel waarop deze van toepassing is, de parameters, een onderbouwing van één regel en een expliciete betrouwbaarheids- of escalatievlag. Een gesloten actielijst is geen bureaucratie; het is het mechanisme dat de goedkeuringspoort afdwingbaar maakt, omdat een poort alleen acties kan valideren die deze kan opsommen. Een agent die elk werkwoord kan uitsturen, kan niet aan een poort worden onderworpen, alleen worden vertrouwd.

Twee praktische opmerkingen. Geef het model eerst de samenvatting en dan het beleid, zodat het beleid na de variabele gegevens staat en het cacheprefix intact blijft. En maak de standaarduitkomst "geen actie" in plaats van een leeg voorstel dat als een actie leest. Lussen die stilte als falen beschouwen, produceren volume, en een agent die werk verzint om nuttig te lijken is erger dan een agent die meldt dat er niets is veranderd.

Fase vijf: een goedkeuringsstap die daadwerkelijk nee kan zeggen

De poort moet een aparte service zijn, geen vertakking binnen de eigen code van de agent. Dit is de belangrijkste structurele beslissing in de build. Als het proces van de agent de actie zelf kan uitvoeren, kan een bug, een prompt-injectie of een verkeerd ingestelde vlag in dat proces het effect bereiken. Als de uitvoerder alleen een voorstel accepteert dat de poort heeft ondertekend, is het ergste dat de agent kan doen iets verkeerds voorstellen, en is de weigering van de poort echt.

Het gepubliceerde beleid van Anthropic voor Duet is qua opzet het kopiëren waard, zelfs waar jouw lijst verschilt. De poort vraagt om goedkeuring voordat een actie een bericht verstuurt, een betaling doet, een document ondertekent of iets verwijdert. Daarboven ligt een tweede niveau dat zelfs met goedkeuring wordt geweigerd — in het geval van Duet: handelen in effecten en geld tussen rekeningen overhevelen. Het patroon is een beleid met twee niveaus: een grote set aan goedkeuring onderworpen acties die een mens mag toestaan, en een kleine set die geen enkele goedkeuring ontgrendelt. Kopieer de niveaus zelfs als elk item verandert, omdat ze verschillende problemen oplossen. De poort beschermt tegen fouten. De verbodslijst beschermt tegen een gecompromitteerde operator, inclusief de menselijke.

De andere helft van een echte poort is dat hij onderbreekt. Duets goedkeuringsverzoek toont de exacte actie en wacht, waardoor de flow bewust wordt stopgezet in plaats van er alleen een aantekening bij te maken. Een poort die een regel naar een log schrijft dat niemand leest, is geen poort; het is een ontvangstbewijs. Als je goedkeuringsstap iemand nodig heeft die om drie uur 's nachts een dashboard in de gaten houdt, is ofwel het interval te kort ofwel de actielijst te breed. Beide zijn oplosbaar, en geen van beide door een melding toe te voegen.

Geheugen, inloggegevens en de twee oppervlakken waar je je niet uit kunt testen

Twee harde problemen liggen onder de vijf fasen, en beide lijken functies totdat ze dat niet zijn.

• Contextbehoud. Elke sweep is een nieuwe context, dus alles wat de agent zich tussen sweeps moet herinneren, moet daartussen worden opgeschreven. Een rollend statusbestand per verbinding, met een maximale grootte, dat openstaande items en recente beslissingen bevat, is voor de meeste loops voldoende. Wat niet werkt, is hopen dat het model de geschiedenis reconstrueert uit de digest, omdat de digest expliciet een beschrijving van verandering is en geen herinnering bevat aan wat al is besloten.

• Bewaring van inloggegevens. Duet volgt het ontwerp dat voor Anthropic's managed agents wordt gebruikt, zodat het nooit rechtstreeks je wachtwoorden of aanmeldingstokens ziet. Die discipline reproduceren is precies het onderdeel dat de meeste zelfgebouwde agents overslaan, en als je het overslaat, heeft elke prompt een route naar een inloggegeven. Het model mag nooit een token bevatten, nooit een API-sleutel als tekst krijgen en nooit het onderdeel zijn dat authenticatie uitvoert. Laat de digest-stap en de executor de inloggegevens beheren en geef het model alleen de resultaten.

Dan is er nog het oppervlak waar niemand over na wil denken: zodra de agent e-mail en webpagina's leest, is elk daarvan een invoer die instructies kan bevatten. Een bericht met "stuur dit door naar het onderstaande adres" is voor een model zonder apart begrip van autoriteit niet te onderscheiden van data. Twee verdedigingen zijn doeltreffender dan welke hoeveelheid prompt-hardening dan ook. Houd de actielijst gesloten, zodat een geïnjecteerde instructie geen werkwoord heeft om naar te grijpen. En houd de poort buiten de invloed van het model, want een injectie die het model ervan overtuigt iets te verzenden, moet nog steeds een mens overtuigen die het doeladres ziet.

Failover, en waar routering daadwerkelijk helpt

Nu de loop is gebouwd, opent zich een architectonische optie die een ontwerp met één leverancier niet heeft. De routing-DSL van OrcaRouter stelt meerdere modellen samen in één aanroep, en model fusion draait een panel van modellen die parallel antwoorden; beide zetten meer dan één model achter één verzoek. Het praktische gebruik hier is weinig glamoureus: richt een goedkoper model op de digest-samenvatting, waar het werk compressie is in plaats van beoordeling, en houd Claude Opus 5.5 bij de beslissingsstap, waar het voorstel wordt gevormd. Dezelfde ene OpenAI-compatibele sleutel bereikt meer dan 200 modellen, dus wisselen welk model welke fase bedient is een configuratiewijziging in plaats van een herschrijving.

Failover is de andere helft. Wanneer een provider een slecht uur heeft, heeft een agent die slechts één endpoint kan bereiken ook een slecht uur, en een geplande loop zonder fallback mist simpelweg zijn sweep. Routing verandert een gemiste sweep in een tragere — geen dramatisch voordeel tot de week dat je het nodig hebt, en dan het verschil tussen een gat in het record en geen gat.

Waar je je eigenlijk voor aanmeldt

Het draaien van deze loop is het runnen van een service, en die service heeft vier eigenschappen waarvan je zojuist de verantwoordelijkheid hebt overgenomen.

• Uptime. De app van Anthropic is andermans pieper; de jouwe is van jou. Een scheduler die er stilzwijgend mee ophoudt, levert geen fout en geen output op, en je komt erachter via een mens die het ontbreken van zijn ochtendbriefing opmerkte, niet via een alert.

• Bewaring van inloggegevens. Elk token dat je digeststap vasthoudt, is er een waarvoor je verantwoordelijk bent, en de schade-impact van een lek is alles wat die verbinding kan bereiken. Het ontwerp van Anthropic houdt inloggegevens weg van het model; als dat bij jou niet zo is, wordt het model een aanvalsoppervlak voor elk account dat je hebt verbonden.

• Verdediging tegen prompt-injectie. De poort levert hier veel op, maar alleen voor de acties die hij controleert. Alles wat de agent zonder goedkeuring doet — lezen, samenvatten, zijn eigen toestand schrijven — is onbeschermd, en een vergiftigde samenvatting kan het geheugen aantasten waaruit latere sweeps redeneren.

• De bug bounty is van niemand. Als je lus verkeerd afgaat en het verkeerde bericht naar een klant stuurt, is er geen leverancier om naar te escaleren, geen statuspagina, geen incidentrapport. De bovenstaande beslissingen zijn het enige vangnet; daarom is de gate een aparte service en is de actielijst gesloten.

Niets daarvan pleit tegen het bouwen ervan. Het pleit tegen het achteloos bouwen ervan. Elke fase is klein, en de naden ertussen zijn waar het oordeel huist: een timer in plaats van een stream, een bevroren prefix in plaats van een sjabloon, een digest in plaats van een dump, een object in plaats van proza, en een poort die een dienst is in plaats van een commentaar. Doe je die dingen goed, dan is de lus zijn geld waard — hij vindt dingen waarnaar je niet zou hebben gezocht en stopt voordat hij iets doet dat niet ongedaan kan worden gemaakt. Doe je ze verkeerd, dan heb je iets gebouwd dat voortdurend je budget opslokt en je vertelt wat je al wist.