Jeg satser min virksomhed på proaktive agenter

Agenter kan gøre næsten alt, du beder dem om, og det er problemet: du skal stadig bede.

Jeg hører hele tiden folk kalde agenter “digitale kolleger”. Det billede er forkert. En kollega, der sidder i stilhed, indtil du giver dem en perfekt afgrænset opgave, løser den og så går tilbage til at vente, er ikke en kollega. Hver agent, du nogensinde har brugt, virker præcis sådan. Modellerne blev klogere, harnesses blev bedre, kørslerne blev længere, men grænsefladen ændrede sig aldrig: du kommer med arbejdet, agenten kommer med arbejdskraften.

Og de fleste har ikke bemærket det, fordi prompt-feltet stille og roligt er blevet det, AI er i vores hoveder.

Ask anything about your stack...

Hver grænseflade er stadig et prompt-felt

Inputfeltet er, hvordan hele denne æra begyndte. ChatGPT satte et oven på en model og blev det hurtigst voksende produkt i historien, og vi kopierede det alle sammen. Hvert AI-produkt siden har været en variation over den samme interaktion: menneske taster, maskine svarer, maskine venter.

Claude Code var den næste udvikling. Agenten flyttede ind i din terminal, tog dine filer, din shell og din git-historik op og begyndte at lave rigtigt arbejde i stedet for at tale om det. Det ændrede, hvad agenter kunne, men ikke hvordan de starter: du taster, den arbejder, den stopper, og den venter på, at du taster igen.

~/app

$ claude

✳ 12 files · main · last session 2h ago

> fix the failing checkout tests

? for shortcuts

Så flyttede agenterne til cloud. Codex, Devin, Claude Code på webben. De kører i timer i stedet for minutter, starter underagenter for at parallelisere arbejdet og dør ikke, når du lukker din laptop. Du giver en af dem en opgave før frokost og kommer tilbage til en pull request.

Prompten holdt endda op med kun at være noget fra et tastatur. Baggrundsagenter kan sættes i gang af en alarm eller en webhook, og de fleste agentplatforme tilbyder nu automatiseringer: når denne event udløses, eller denne cron tikker, kør en agent med disse instruktioner.

Triage Sentry alerts Enabled

When

a Sentry alert fires

Do

investigate, open an incident if it's real

Then

post the findings to #incidents

Men hvad er en automatisering? Det er en prompt, du skrev på forhånd. Du forudsagde fejltilstanden, valgte eventen og skrev ned, hvad der skulle gøres ved den. Triggeren starter agenten, men dømmekraften inde i den er din, frosset fast på opsætningstidspunktet. En automatisering fanger præcis det, du forudså, og intet andet.

Du er scheduleren

Skræl værktøjerne af, og arbejdsdelingen har ikke flyttet sig i tre år. Agenten laver arbejdet. At beslutte, hvad arbejdet er, forbliver dit job.

Du læser dashboards, du lytter til brugerne, du finder ud af, hvad der betyder noget, og du komprimerer alt, du har lært, til en prompt, enten live ved tastaturet eller på forhånd i en trigger. Agenten udfører brillant, men hvert stykke dømmekraft i systemet stammer fra dig.

Den næste udvikling: agenter, der finder arbejdet

Jeg satser på, at den næste udvikling er agenter, der selv finder ud af, hvad der skal gøres. Ingen prompt, ingen trigger at konfigurere, ingen instruktioner skrevet på forhånd. Du forbinder din stak, og agenten finder selv arbejdet: den holder øje med de samme signaler, du holder øje med, bemærker hvad der er galt, beslutter om det betyder noget, og begynder at arbejde på det autonomt.

Det er nemt at sige og brutalt svært at bygge, fordi proaktivitet er tre problemer stablet oven på hinanden, og springer du et af dem over, får du noget værre end agenten bag et inputfelt.

Kontekst. Agenten har naturligvis brug for en levende model af den verden, den arbejder i, ikke et snapshot, du indsatte i kontekstvinduet på prompt-tidspunktet. En reaktiv agent med dårlig kontekst giver dig et dårligt svar. En proaktiv agent med dårlig kontekst sletter din produktionsdatabase, fordi den troede, det var staging.

Dømmekraft. Det her er det, der har givet mig de største kvaler. På et hvilket som helst tidspunkt er tusindvis af ting i et produktionssystem lidt ude af kurs. En agent, der markerer dem alle, er en støjmaskine, støjmaskiner bliver sat på lydløs, og agenter på lydløs er døde agenter. Hele værdien af proaktivitet ligger i kløften mellem “noget ændrede sig” og “noget betyder noget”:

[
  {
    "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. At bemærke uden at handle er bare en klogere alarm, og alarmer er det, jeg forsøger at slå ihjel. Agenten skal gøre arbejdet færdigt, inden for grænser der gør autonomi sikker: handlinger, der kan rulles tilbage, beviser for alt og en hård gate, før noget uigenkaldeligt sker.

Ingen af de tre indebærer, at agenten beslutter, hvordan godt ser ud. Den beslutter, hvad der er galt, om det betyder noget, og hvad der skal gøres ved det, og det er hele listen, fordi ingen i produktion behøver at definere godt: fejl på nul, latens på baseline, køer tømt, certifikater gyldige. Den ønskede tilstand følger med territoriet.

Hvilket betyder, at det virkelige skift ikke er fra “du prompter” til “agenten prompter sig selv”. Det er fra imperativ drift til deklarativ drift. En automatisering er imperativ: du opremser fejltilstandene på forhånd og scripter en respons til hver. En proaktiv agent er et afstemningsloop: den holder det system, du har, op mod det system, du burde have, og arbejder på at lukke kløften. Kubernetes gjorde det for infrastruktur for et årti siden, du skriver tre replikaer ned, og en controller gør, hvad der skal til, for at holde tre replikaer i live. Ingen har gjort det for selve driften af software. Og her er der ikke engang YAML at skrive, fordi den ønskede tilstand allerede er kendt. Det virker ud af boksen.

Jeg begyndte med drift

Bed en proaktiv agent om at vælge dit produkt-roadmap, og du får en praktikant med holdninger, fordi produktretning er et spørgsmål om smag. Det er produktion ikke. Det er det ene domæne, hvor alle tre problemer kan løses i dag.

Arbejdet melder sig selv: fejlrater stiger, et deploy går skævt, et certifikat udløber, en kø sander til. Arbejdet ligger allerede i telemetrien og venter på, at nogen bemærker det. Og i modsætning til smagsdrevne domæner findes der en ground truth: fejlraten steg enten brat, eller den gjorde ikke, rollbacken genskabte enten baseline, eller den gjorde ikke, så agentens dømmekraft bliver bedømt af systemet selv, løbende, uden plads til fornemmelser.

Frem for alt bemander vi allerede dette job med mennesker. Vi kalder det on-call: en person, der sover ved siden af en telefon og venter på, at en maskine siger, at en anden maskine er utilfreds. Jeg brugte år i observability, stiftede et observability-firma, som Cloudflare opkøbte, og skrev et helt manifest om at strukturere telemetri, så svaret er én query væk. Dets tese er grunden til, at denne virksomhed findes: ingen bør være on-call i 2026.

Fordi den ubehagelige sandhed om det seneste årtis observability er, at vi gjorde systemer nemmere for mennesker at udspørge klokken 3 om natten og så erklærede sejr, mens det stadig var mennesker, der blev vækket. Dashboards blev pænere, og pageren blev liggende på natbordet. Observability uden handling er bare dyr lagerplads.

Sådan ser det ud

Det er det, Polylane gør. Her er en konkret tirsdag:

Ingen konfigurerede en kontrol for denne fejltilstand. Der er ingen regler at skrive og ingen tærskler at justere: agenter evaluerer hver forbundet ressource med faste intervaller, og dine eksisterende dashboards og gemte queries bliver deres tjekliste. Dømmekraft er der, hvor jeg er strengest. Standardvurderingen er no anomaly, fordi det er langt bedre at overse et grænsetilfælde end at vække nogen for støj. “Et deploy kunne indføre en fejl” er sandt om hvert deploy og aldrig grund til at page nogen.

Når noget er ægte, kører undersøgelsen flere konkurrerende hypoteser parallelt, og hver agents job er at afkræfte sin hypotese i stedet for at bekræfte den, så korrelation aldrig får lov at udgive sig for årsag. Når den bekræftede rodårsag er en kodeændring, kommer rettelsen som en pull request med undersøgelsen vedhæftet:

Restore Hyperdrive pool size in checkout-edge

PR open coreplane/checkout-edge

Investigation report attached Checks passing

Opened by Polylane · gated on review and CI

Proaktiv er ikke uden opsyn

Autonomien ligger i at bemærke, i triagen, i arkæologien klokken 3 om natten og i afhjælpningen. Alt, der genskaber en kendt god tilstand, gør agenten på egen hånd: rul det dårlige deploy tilbage, slå flaget fra igen. De handlinger kan rulles tilbage af natur, og det er dem, der faktisk gør pageren tavs. Det, der forbliver bag en gate, er alt, der skaber en ny tilstand: en kodeændring leveres gennem din gennemgang og din CI, aldrig uden om dem.

Grænsen går ikke mellem menneske og agent. Den går mellem kan rulles tilbage og kan ikke. Og det er derfor, du ikke i al hemmelighed stadig er on-call: rollbacken afsluttede hændelsen klokken 02:33, seks timer før du mergede pull requesten. PR’en var aldrig det, der stoppede blødningen. Den er det, der forhindrer, at det sker igen, og det kan vente til kaffen.

Og gaten er din at uddelegere. Kodegennemgangsagenter læser allerede hver pull request i dit repository. Der findes en verden, ikke langt fra denne, hvor din gennemgangsagent læser rettelsen klokken 02:41, kontrollerer den mod undersøgelsen, godkender den, og din CI deployer til produktion, før du vågner. Intet i loopet ændrer sig, bortset fra hvem der holder godkend-knappen. Det er der, det her ender: software, der retter sig selv, med dig, der skriver politikken i stedet for at klikke på merge.

Læg mærke til, hvad der mangler i det loop:

Ask anything about your stack...

Prompt-feltet var en god måde at lære at stole på disse systemer, og det er en frygtelig måde at drive produktion. Agenten har set hvert deploy, hver loglinje og hver metrik på tværs af alle services på én gang. At holde den bag en prompt betyder, at det bedst informerede medlem af dit team kun taler, når der bliver talt til det.

Ingen bør være on-call i 2026.