Jeg satser selskapet mitt på proaktive agenter
Explore with AI
Agenter kan gjøre nesten alt du ber dem om, og det er problemet: du må fortsatt be.
Jeg hører stadig folk kalle agenter «digitale kolleger». Den innrammingen er feil. En kollega som sitter i stillhet til du gir dem en perfekt avgrenset oppgave, fullfører den, og så går tilbake til å vente, er ikke en kollega. Hver agent du noen gang har brukt, fungerer nøyaktig slik. Modellene ble smartere, harnessene ble bedre, kjøringene ble lengre, men grensesnittet endret seg aldri: du kommer med arbeidet, agenten kommer med arbeidskraften.
Og de fleste har ikke lagt merke til det, fordi promptfeltet i stillhet har blitt det KI er i hodene våre.
Hvert grensesnitt er fortsatt et promptfelt
Inndatafeltet er slik hele denne epoken startet. ChatGPT satte ett på toppen av en modell og ble det raskest voksende produktet i historien, og vi kopierte det alle sammen. Hvert KI-produkt siden har vært en variasjon over den samme interaksjonen: mennesket skriver, maskinen svarer, maskinen venter.
Claude Code var den neste evolusjonen. Agenten flyttet inn i terminalen din, tok tak i filene dine, shellen din og git-historikken din, og begynte å gjøre ekte arbeid i stedet for å snakke om det. Det endret hva agenter kunne gjøre, men ikke hvordan de starter: du skriver, den jobber, den stopper, og den venter på at du skal skrive igjen.
Så flyttet agentene til skyen. Codex, Devin, Claude Code på nettet. De kjører i timer i stedet for minutter, starter underagenter for å parallellisere arbeidet, og dør ikke når du lukker laptopen. Du gir en av dem en oppgave før lunsj og kommer tilbake til en pull request.
Prompten sluttet til og med å være noe du bare gjør med tastaturet. Bakgrunnsagenter kan startes av et varsel eller en webhook, og de fleste agentplattformer tilbyr nå automatiseringer: når denne hendelsen utløses, eller denne cronen tikker, kjør en agent med disse instruksjonene.
- When
- a Sentry alert fires
- Do
- investigate, open an incident if it's real
- Then
- post the findings to #incidents
Men hva er en automatisering? Det er en prompt du skrev på forhånd. Du forutså feilmodusen, valgte hendelsen og skrev ned hva som skulle gjøres med den. Triggeren starter agenten, men vurderingen inne i den er din, frosset på oppsettstidspunktet. En automatisering fanger nøyaktig det du forutså, og ingenting annet.
Du er planleggeren
Skrell bort verktøyene, og arbeidsdelingen har ikke flyttet seg på tre år. Agenten gjør arbeidet. Å avgjøre hva arbeidet er, forblir din jobb.
Du leser dashbordene, du hører på brukerne, du finner ut hva som betyr noe, og du komprimerer alt du har lært til en prompt, enten direkte ved tastaturet eller på forhånd i en trigger. Agenten utfører glimrende, men hver bit vurdering i systemet kommer fra deg.
Den neste evolusjonen: agenter som finner arbeidet
Jeg satser på at den neste evolusjonen er agenter som selv finner ut hva som må gjøres. Ingen prompt, ingen trigger å konfigurere, ingen instruksjoner skrevet på forhånd. Du kobler til stacken din, og agenten finner arbeidet selv: den følger med på de samme signalene du følger med på, legger merke til hva som er galt, avgjør om det betyr noe, og begynner å jobbe med det autonomt.
Dette er lett å si, og brutalt vanskelig å bygge, fordi proaktivitet er tre problemer stablet på hverandre, og hopper du over ett av dem, får du noe verre enn agenten bak et inndatafelt.
Kontekst. Agenten trenger selvsagt en levende modell av verdenen den opererer i, ikke et øyeblikksbilde du limte inn i kontekstvinduet da du skrev prompten. En reaktiv agent med dårlig kontekst gir deg et dårlig svar. En proaktiv agent med dårlig kontekst sletter produksjonsdatabasen din fordi den trodde det var staging.
Vurdering. Dette er det som har gitt meg mest hodebry. I ethvert øyeblikk er tusenvis av ting i et produksjonssystem litt galt. En agent som flagger alle, er en støymaskin, støymaskiner blir dempet, og dempede agenter er døde agenter. Hele verdien av proaktivitet ligger i gapet mellom «noe endret seg» og «noe betyr noe»:
[
{
"signal": "memory up 3% on checkout-edge",
"verdict": "no anomaly",
"reasoning": "within the seasonal range for this hour on this worker"
},
{
"signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
"verdict": "incident",
"reasoning": "error class never seen on this worker, tightly correlated with a deploy"
}
]
Handling. Å legge merke til uten å handle er bare et smartere varsel, og varsler er det jeg prøver å avlive. Agenten må fullføre jobben, innenfor grenser som gjør autonomi trygg: reversible handlinger, belegg for alt, og en hard port før noe irreversibelt skjer.
Ingen av disse tre innebærer at agenten avgjør hvordan bra ser ut. Den avgjør hva som er galt, om det betyr noe, og hva som skal gjøres med det, og det er hele listen, fordi i produksjon må ingen definere bra: feil på null, latens på baseline, køer tømt, sertifikater gyldige. Den ønskede tilstanden følger med territoriet.
Det betyr at det egentlige skiftet ikke er fra «du prompter» til «agenten prompter seg selv». Det er fra imperativ drift til deklarativ drift. En automatisering er imperativ: du lister opp feilmodusene på forhånd og skripter en respons på hver. En proaktiv agent er en avstemmingsløkke: den holder systemet du har opp mot systemet du burde ha, og jobber for å lukke gapet. Kubernetes gjorde dette for infrastruktur for et tiår siden, du skriver ned tre replikaer, og en kontroller gjør det som trengs for å holde tre replikaer i live. Ingen har gjort det for selve driften av programvare. Og her er det ikke engang YAML å skrive, fordi den ønskede tilstanden allerede er kjent. Det fungerer rett ut av boksen.
Jeg begynte med drift
Be en proaktiv agent velge produktveikartet ditt, og du får en praktikant med sterke meninger, fordi produktretning er et spørsmål om smak. Produksjon er ikke det. Det er det ene domenet der alle tre problemene kan løses i dag.
Arbeidet melder seg selv: feilrater stiger, en deploy går skeis, et sertifikat utløper, en kø hoper seg opp. Arbeidet ligger allerede i telemetrien og venter på at noen skal legge merke til det. Og i motsetning til smaksdrevne domener finnes det en fasit: feilraten skjøt enten i været eller ikke, rollbacken gjenopprettet enten baselinen eller ikke, så agentens vurdering scores av systemet selv, kontinuerlig, uten rom for magefølelse.
Mest av alt bemanner vi allerede denne jobben med mennesker. Vi kaller det vakt: en person som sover ved siden av en telefon og venter på at en maskin skal si at en annen maskin er misfornøyd. Jeg brukte år på observerbarhet, grunnla et observerbarhetsselskap som Cloudflare kjøpte opp, og skrev et helt manifest om å strukturere telemetri slik at svaret er én spørring unna. Tesen der er grunnen til at dette selskapet finnes: ingen burde ha vakt i 2026.
For den ubehagelige sannheten om det siste tiåret med observerbarhet er at vi gjorde systemer lettere for mennesker å forhøre klokken tre om natten, og så erklærte seier mens det fortsatt var mennesker som ble vekket. Dashbordene ble penere, og vakttelefonen ble liggende på nattbordet. Observerbarhet uten handling er bare dyr lagring.
Slik ser det ut
Dette er det Polylane gjør. Her er en konkret tirsdag:
Ingen konfigurerte en sjekk for denne feilmodusen. Det er ingen regler å skrive og ingen terskler å justere: agenter evaluerer hver tilkoblet ressurs kontinuerlig med jevne mellomrom, og de eksisterende dashbordene og lagrede spørringene dine blir sjekklisten deres. Vurdering er der jeg er strengest. Standardkonklusjonen er ikke noe avvik, fordi det er mye bedre å gå glipp av et grensetilfelle enn å vekke noen for støy. «En deploy kan introdusere en feil» gjelder for hver deploy og er aldri grunn til å vekke noen.
Når noe er ekte, kjører undersøkelsen flere konkurrerende hypoteser parallelt, og hver agents jobb er å avkrefte sin hypotese heller enn å bekrefte den, så korrelasjon aldri får utgi seg for årsak. Når den bekreftede rotårsaken er en kodeendring, kommer fiksen som en pull request med undersøkelsen vedlagt:
Opened by Polylane · gated on review and CI
Proaktiv er ikke uten tilsyn
Autonomien ligger i å legge merke til, i triagen, i arkeologien klokken tre om natten og i skadebegrensningen. Alt som gjenoppretter en kjent god tilstand, gjør agenten på egen hånd: rull tilbake den dårlige deployen, slå flagget av igjen. De handlingene er reversible av natur, og det er de som faktisk gjør vakttelefonen stille. Det som forblir bak en port, er alt som skaper en ny tilstand: en kodeendring leveres gjennom gjennomgangen din og CI-en din, aldri rundt dem.
Skillet går ikke mellom menneske og agent. Det går mellom reversibelt og ikke. Og det er derfor du ikke i hemmelighet fortsatt har vakt: rollbacken avsluttet hendelsen klokken 02:33, seks timer før du slo sammen pull requesten. PR-en var aldri det som stoppet blødningen. Den er det som hindrer at det skjer igjen, og det kan vente til kaffen.
Og porten er din å delegere. Kodegjennomgangsagenter leser allerede hver pull request i repositoryet ditt. Det finnes en verden, ikke langt fra denne, der gjennomgangsagenten din leser fiksen klokken 02:41, sjekker den mot undersøkelsen, godkjenner den, og CI-en din deployer til produksjon før du våkner. Ingenting i løkken endrer seg bortsett fra hvem som holder godkjenn-knappen. Det er der dette ender: programvare som fikser seg selv, med deg som skriver policyen i stedet for å klikke på slå sammen.
Legg merke til hva som mangler i den løkken:
Promptfeltet var en god måte å lære å stole på disse systemene på, og det er en fryktelig måte å drive produksjon på. Agenten har sett hver deploy, hver logglinje og hver metrikk på tvers av hver tjeneste samtidig. Å holde den bak en prompt betyr at det best informerte medlemmet av teamet ditt bare snakker når det blir snakket til.
Ingen burde ha vakt i 2026.