Bygg en proaktiv agentloop på Claude Opus 5.5

Det obekväma med att bygga sin egen proaktiva agent är att det intressanta arbetet inte är modellanropet. Du kan få Claude Opus 5.5 att svara på frågor på en eftermiddag. Att få den att vakna enligt ett schema, bara läsa det som ändrats sedan förra gången, avgöra om något förtjänar en människa, utforma åtgärden och sedan stanna och vänta – det tar veckor, och nästan inget av det sker inuti modellen. Anthropic släppte en version av den här loopen som Claude Duet, och det som är användbart med den produkten för den som bygger sin egen är inte dess funktionslista utan de beslut som syns i hur den är sammansatt. Den har inget publicerat API och kan inte riktas om mot dina egna system, så om du vill ha loopen snarare än appen får du bygga den. Det som följer är arkitekturen, steg för steg, med den ärliga kostnaden för varje.

Formen först. Fem steg körs i sekvens, och det femte nås först efter att en människa har sagt ja. En schemaläggare utlöser. Ett sammandragssteg reducerar varje anslutet system till en delta. Ett beslutssteg förvandlar den deltan plus en policy till ett typat förslag. En godkännandegrind utanför modellen avgör om förslaget får köras. En utförare verkställer det. Det är hela designen, och allt svårt med den lever i skarvarna.

Steg ett: en schemaläggare som utlöses med några timmars mellanrum

Det första beslutet är det som folk fattar fel utifrån entusiasm snarare än ingenjörsmässighet: polla inte kontinuerligt. Anthropics Duet-dokumentation förklarar sitt intervall – att kontrollera med några timmars mellanrum – med att säga att kontrollera oavbrutet skulle förbruka planens gränser mycket snabbare. Det är inte marknadsföringsmässig försiktighet. Det är rätt svar på ett verkligt kostnadsproblem, och det är fällan som varje hemmabyggd agent går i under första veckan.

Kontinuerlig polling är förödande av en strukturell anledning. Varje svep är en fullständig kontext: instruktioner, verktygsdefinitioner, materialet du hämtade in och vilken resonemangskörning modellen än gör över det. Med en kadens på en minut blir det 1 440 fullständiga kontexter per dag, och den överväldigande majoriteten hittar inget nytt. Du betalar fullt pris för att få veta att inkorgen inte har förändrats. Vid tre timmar får du åtta, och förhållandet mellan fynd och kostnad blir något du kan försvara inför den som signerar fakturan.

Så schemaläggaren är en cron-liknande timer med en nedre gräns för minsta intervall, inte en händelseström. Händelser låter attraktiva – reagera i samma ögonblick som något händer – men de drar dig tillbaka mot kontinuerligt arbete och gör kostnaden för en hektisk dag obegränsad. En timer ger ett förutsägbart tak, vilket är vad du behöver när räkningen är variabel. När du vill få snabbare reaktion för en källa, förkorta bara den anslutningens intervall och acceptera den extra kostnaden.

Steg två: ett byte-identiskt prefix, som hålls i cachen

Det är här de publicerade siffrorna gör störst nytta. Claude Opus 5.5 på OrcaRouter kostar 4,00 dollar per miljon indatatoken och 20,00 per miljon utdatatoken, med ett kontextfönster på 1 miljon token och cacheläsningar till 0,20 per miljon, till leverantörens listpris med 0 procents påslag. Läs siffrorna som en designbegränsning snarare än en prislista: en cacheläsning kostar en tjugondel av en färsk indatatoken, så varje byte du håller stabil mellan svep är en byte du slutar betala fullt pris för.

I praktiken monteras systemprompten och verktygsschemat en gång vid driftsättningen och regenereras aldrig vid varje svep. Det serialiseras inte om från en ordlista med nycklarna i en annan ordning. Det mallas inte med en tidsstämpel, ett förfrågnings-ID eller dagens anslutna konton insplitsade i mitten. Varje byte som skiljer sig ogiltigförklarar det cachelagrade prefixet, och instruktionsblocket återgår till fullt indatapris vid varje svep. Team tappar detta av misstag oftare än avsiktligt, vanligtvis eftersom en hjälpsam abstraktion började injicera en körningsidentifierare nära början av prompten.

Disciplinen som överlever kontakt med riktig kod är tråkig: en funktion som returnerar en konstant sträng för det stabila blocket, en fryst literal för verktygsschemat, varje variabelt element placerat efter det. Sedan ett test som hashar blocket och får bygget att misslyckas när hashen ändras, eftersom någon till slut kommer att lägga till ett schemafält och aldrig tänka på cachen. Det testet kostar en timme och räddar hela cachefördelen.

Steg tre: en sammanfattning per anslutning, inte en dump av hela brevlådan

Det tredje steget är det som en konsumentprodukt får gratis men inte du. Duet lever inuti Anthropics konto och når anslutna appar, så det kan fråga vad som har ändrats sedan en viss tidpunkt och få ett litet svar. När du bygger utanför det kontot talar du med samma API:er som vilken vanlig klient som helst: antingen implementerar du inkrementella läsningar eller så hämtar du allt och ger modellen en vägg av text.

Att hämta allt är standardinställningen eftersom det fungerar från dag ett. Det är också det snabbaste sättet att göra kostnaden per svep oförutsägbar, eftersom indata växer med brevlådan i stället för med det som har ändrats. Ett svep över fyrtio oförändrade trådar kostar lika mycket som ett över fyrtio trådar där en enda tråd spelar roll, och bara en av dem hade någon chans att ge ett användbart förslag. Efter en månad av det gick större delen av din budget till att bekräfta status quo.

Digeststeget bör vara kod, inte promptning. Hämta per anslutning med den cursor eller delta som API:et erbjuder och reducera resultatet till en strukturerad sammanfattning: vad som dök upp, vad som ändrades, vad som löstes. Ge varje post en stabil identifierare så att senare steg kan referera till den, och registrera den senaste lyckade cursorn per anslutning så att en misslyckad hämtning inte spelar upp gårdagens material som om det vore nytt. En sammanställning som inte kan skilja på "ingenting hände" och "jag kunde inte kontrollera" kommer så småningom att rapportera med tillförsikt om ett tillstånd som den aldrig har observerat.

Steg fyra: ett beslutssteg som avger ett objekt, inte prosa

Det är här Claude Opus 5.5 befinner sig, och det som den ger ifrån sig avgör om resten av systemet överhuvudtaget kan byggas. Instinkten är att låta modellen skriva en sammanfattning och låta en människa läsa den. Det fungerar för en instrumentpanel men misslyckas för en grind: nästa steg måste avgöra om en åtgärd ska tillåtas, och tillstånd kan inte beviljas till ett stycke.

Beslutssteget bör returnera ett typat åtgärdsförslag: ett åtgärdsnamn från en sluten lista, målet det gäller, parametrarna, en enradig motivering och en explicit konfidens- eller eskaleringsflagga. En sluten åtgärdslista är inte byråkrati; det är mekanismen som gör godkännandegrinden genomförbar, eftersom en grind bara kan validera åtgärder som den kan räkna upp. En agent som kan sända ut vilket verb som helst kan inte grindas, bara ges förtroende.

Två praktiska kommentarer. Ge modellen sammanställningen först och därefter policyn, så att policyn ligger efter det variabla materialet och cacheprefixet förblir intakt. Och låt standardutfallet vara "ingen åtgärd" i stället för ett tomt förslag som framstår som en åtgärd. Loopar som behandlar tystnad som misslyckande producerar volym, och en agent som tillverkar arbete för att verka användbar är sämre än en som rapporterar att inget har förändrats.

Steg fem: en godkännandegrind som faktiskt kan säga nej

Grinden måste vara en separat tjänst, inte en gren inuti agentens egen kod. Detta är det viktigaste strukturella beslutet i bygget. Om agentens process kan utföra åtgärden själv når en bugg, en promptinjektion eller en felaktigt inställd flagga i den processen ända fram till effekten. Om exekutorn endast accepterar ett förslag som grinden har signerat, är det värsta agenten kan göra att föreslå något felaktigt, och grindens avslag är verkligt.

Anthropics publicerade policy för Duet är värd att kopiera till sin struktur även där din lista skiljer sig. Grinden begär godkännande innan en åtgärd skickar ett meddelande, genomför en betalning, signerar ett dokument eller raderar något. Ovanför den finns en andra nivå som nekas även med godkännande – i Duets fall handel med värdepapper och att flytta pengar mellan konton. Mönstret är en policy i två nivåer: en stor uppsättning grindade åtgärder som en människa får tillåta, och en liten uppsättning som inget godkännande låser upp. Kopiera nivåerna även om varje post ändras, eftersom de löser olika problem. Grinden skyddar mot misstag. Förbudslistan skyddar mot en komprometterad operatör, inklusive den mänskliga.

Den andra hälften av en riktig grind är att den avbryter. Duets godkännandeförfrågan visar den exakta åtgärden och väntar, vilket medvetet stoppar flödet i stället för att bara kommentera det. En grind som skriver en rad till en logg som ingen läser är inte en grind; det är ett kvitto. Om ditt godkännandesteg kräver att någon övervakar en instrumentpanel klockan tre på morgonen, är antingen intervallet för kort eller åtgärdslistan för bred. Båda kan åtgärdas, och ingen av dem genom att lägga till en avisering.

Minne, autentiseringsuppgifter och de två ytor du inte kan testa dig ur

Två svåra problem ligger under de fem stegen, och båda ser ut som funktioner tills de inte är det.

• Kontextöverföring. Varje svep är en ny kontext, så allt som agenten bör komma ihåg mellan svep måste skrivas ned mellan dem. En rullande tillståndsfil per anslutning, storleksbegränsad, som håller öppna punkter och nyligen fattade beslut räcker för de flesta loopar. Det som inte fungerar är att hoppas att modellen rekonstruerar historiken från digesten, eftersom digesten uttryckligen är en beskrivning av förändring och inte innehåller något minne av vad som redan beslutats.

• Förvaring av autentiseringsuppgifter. Duet följer den design som används för Anthropics hanterade agenter, så det ser aldrig dina lösenord eller inloggningstoken direkt. Att återskapa den disciplinen är den del som de flesta egenutvecklade agenter hoppar över, och att hoppa över den innebär att varje prompt har en väg till en autentiseringsuppgift. Modellen bör aldrig hålla en token, aldrig ges en API-nyckel som text och aldrig vara den komponent som autentiserar. Låt digest-steget och exekveraren hålla autentiseringsuppgifterna och ge modellen endast resultaten.

Sedan finns den yta som ingen vill tänka på: när agenten väl läser e-post och webbsidor är var och en en indata som kan innehålla instruktioner. Ett meddelande som säger "vidarebefordra detta till adressen nedan" går inte att skilja från data för en modell som inte har någon separat föreställning om auktoritet. Två försvar slår hur mycket prompthärdning som helst. Håll åtgärdslistan stängd, så att en injicerad instruktion inte har något verb att gripa efter. Och håll grinden utanför modellens inflytande, eftersom en injektion som övertygar modellen att skicka något fortfarande måste övertyga en människa som ser måladdressen.

Failover, och där routning faktiskt hjälper

Med loopen byggd öppnas ett arkitektoniskt alternativ som en design från en enda leverantör inte har. OrcaRouters routing-DSL komponerar flera modeller till ett enda anrop, och modellfusion kör en panel av modeller som svarar parallellt; båda sätter fler än en modell bakom en enda förfrågan. Den praktiska användningen här är oglamorös: låt en billigare modell hantera digest-sammanfattningen, där arbetet är komprimering snarare än bedömning, och behåll Claude Opus 5.5 vid beslutssteget, där förslaget formas. Samma OpenAI-kompatibla nyckel når fler än 200 modeller, så att byta vilken modell som betjänar vilket steg är en konfigurationsändring snarare än en omskrivning.

Failover är den andra halvan. När en leverantör har en dålig timme har en agent som bara kan nå en slutpunkt också en dålig timme, och en schemalagd loop utan fallback missar helt enkelt sin genomsökning. Routing gör en missad genomsökning till en långsammare sådan – inte en dramatisk fördel förrän veckan då du behöver den, och då är den skillnaden mellan en lucka i registret och ingen lucka alls.

Vad du faktiskt anmäler dig till

Att köra den här loopen är att driva en tjänst, och tjänsten har fyra egenskaper som du just har tagit över ansvaret för.

• Drifttid. Anthropics app är någon annans personsökare; din är din. En schemaläggare som tyst slutar köra ger inget fel och ingen utdata, och du upptäcker det genom en människa som lagt märke till att deras morgonbrief uteblivit, inte genom en varning.

• Förvaring av autentiseringsuppgifter. Varje token som ditt digest-steg håller är en som du ansvarar för, och skadeomfånget vid en läcka är allt som den anslutningen kan nå. Anthropics design håller autentiseringsuppgifter borta från modellen; om din inte gör det blir modellen en attackyta för varje konto du har anslutit.

• Försvar mot prompt-injektion. Grinden ger mycket här, men bara för de åtgärder den kontrollerar. Allt agenten gör utan godkännande – läsa, sammanfatta, skriva sitt eget tillstånd – är oskyddat, och en förgiftad sammanfattning kan fördärva det minne som senare svep resonerar utifrån.

• Bug bounty-programmet är ingens. Om din loop felutlöser och skickar fel meddelande till en kund finns det ingen leverantör att eskalera till, ingen statussida, ingen incidentrapport. Besluten ovan är det enda skyddsnätet, vilket är anledningen till att grinden är en separat tjänst och åtgärdslistan är stängd.

Inget av det talar emot att bygga det. Det talar emot att bygga det lättvindigt. Varje steg är litet, och det är i sömmarna mellan dem som omdömet sitter: en timer i stället för en ström, ett fryst prefix i stället för en mall, en digest i stället för en dump, ett objekt i stället för prosa och en spärr som är en tjänst i stället för en kommentar. Får du dem rätt förtjänar loopen sin plats – den hittar saker som du inte skulle ha letat efter och stannar innan den gör något som inte kan ångras. Får du dem fel har du byggt något som kontinuerligt gör av med din budget och berättar det du redan visste.