Dashbord
5. juli 2026

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.

Ask anything about your stack...
KI-ens standardgrensesnitt.

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.

~/app
$ claude
✳ 12 files · main · last session 2h ago
> fix the failing checkout tests
? for shortcuts
Det samme inndatafeltet, i en terminal.

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.

graph TD
    A[You write the task] --> B[Cloud agent]
    B --> C[Sub-agent]
    B --> D[Sub-agent]
    B --> E[Sub-agent]
    C --> F[Pull request]
    D --> F
    E --> F
    style F fill:#d1fae5,stroke:#6ee7b7,color:#065f46

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.

Triage Sentry alerts Enabled
When
a Sentry alert fires
Do
investigate, open an incident if it's real
Then
post the findings to #incidents
En automatisering: agenten handler på en hendelse, etter instruksjoner du skrev.

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.

graph TD
    A[Dashboards] --> D[You]
    B[Alerts] --> D
    C[User complaints] --> D
    D --> E[The prompt you type today]
    D --> F[The automation you configured last month]
    E --> G[Agent]
    F --> G
    style D fill:#fee2e2,stroke:#fca5a5,color:#991b1b

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:

graph TD
    A["02:14 — checkout p99 jumps from 180ms to 2.1s"] --> B["02:15 — agent flags it: new error pattern, right after the 01:52 deploy"]
    B --> C["02:16 — incident opens, 3 hypotheses investigated in parallel"]
    C --> D["02:31 — verdict: connection pool exhausted by a new N+1 query"]
    D --> R["02:33 — the 01:52 deploy is rolled back, p99 back to 180ms. The incident is over."]
    R --> E["02:38 — PR opened with the fix and the evidence attached"]
    E --> F["08:30 — you wake up, read the investigation, merge"]
    style A fill:#fee2e2,stroke:#fca5a5,color:#991b1b
    style R fill:#d1fae5,stroke:#6ee7b7,color:#065f46
    style E fill:#d1fae5,stroke:#6ee7b7,color:#065f46

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:

Restore Hyperdrive pool size in checkout-edge
PR open coreplane/checkout-edge
Investigation report attached Checks passing
Fiksen kommer som en PR. Du gjennomgår, den slås sammen.

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.

graph TD
    A[Signals] --> B[Detection]
    B --> C[Investigation]
    C --> R[Rollback, on its own]
    C --> D[Pull request]
    D --> E[You or your agent review, it merges]
    R --> F[Memory]
    E --> F
    F --> B
    style R fill:#d1fae5,stroke:#6ee7b7,color:#065f46
    style D fill:#d1fae5,stroke:#6ee7b7,color:#065f46
    style F fill:#dbeafe,stroke:#93c5fd,color:#1e40af

Legg merke til hva som mangler i den løkken:

Ask anything about your stack...
Ingen skrev noe. Ingen konfigurerte noe.

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.

Ingen burde ha vakt i 2026. Polylane følger med på infrastrukturen din, undersøker og fikser det som går i stykker.

Bli med på ventelisten