Serverløs agent

Å bygge en agent er ikke lett.

For ett år siden måtte vi selv håndtere kontekst og minne, tenke på RAG og vektordatabaser, og justere verktøybrukens nøyaktighet svært nøye. Fremveksten av Claude Code / Claude Agent SDK endret alt dette. Nå begynner stadig flere team å bygge agenter direkte med Claude Agent SDK + VM. Har problemet blitt enklere? Nei.

Å kjøre Claude Code i VM-er er fortsatt svært utfordrende.

1. Hver brukersesjon trenger en egen VM. I noen scenarier kan persistensmuligheten til VM-er være nyttig, men det gjør også VM-er vanskelige å oppgradere og orkestrere. For eksempel håper brukeren at programvare installert på VM-en fortsatt er tilgjengelig flere måneder senere. Men delene på VM-en som kommuniserer med orkestreringslaget må også kunne rulles ut med oppgraderinger.

2. Å opprette og orkestrere VM-er i stor skala. Et enkelt k8s-kluster støtter orkestrering for noen tusen pods, noe som er tilstrekkelig for applikasjonstjenester. Men det er ikke nok for scenarier der hver sesjon må starte en claude code-pod.

3. Bruk av k8s-løsninger gir ventetid forårsaket av k8s, noe som gjør det vanskelig å oppnå ytelse innen 1 sekund.

4. Bruk av e2b-løsninger krever at du selv håndterer persistens, og opplasting/nedlasting av filer er begge svært tregt.

5. E2b-løsningen kan ikke møte spesifikke krav til nettverksmiljø, og privat distribusjon er tungvint.

Hvordan løser vi disse problemene? La oss lære av historien. For over ti år siden, i 2012, fantes det ikke serverløs, ingen k8s og ingen docker. Backend-utviklere måtte manuelt vedlikeholde en tjenesteprosess på en fysisk maskin for å kjøre en tjeneste. På den tiden var ssh og ansible standardverktøy for serveringeniører. Tjenesteprosesser var sterkt avhengige av ulike verktøymiljøer på den fysiske maskinen. Å oppnå konsistente verktøymiljøkonfigurasjoner på tvers av fysiske maskiner var svært utfordrende, og storskala skalering krevde mye forberedelse. Jeg husker fortsatt da en ingeniør endret miljøet på én maskin og glemte å synkronisere det til de andre, noe som førte til en vanskelig feilsøkbar "spøkelsesfeil" i produksjon. Den perioden var en smertefull, gammel tid.

I 2012 dukket docker opp. Docker pakket alle verktøymiljøer inn i ett enkelt image, og løste problemet med inkonsistente miljøer. Fellesskapet innså gradvis at en tjenesteprosess som kjører i en virtuell maskin på en fysisk maskin kunne håndteres som en prosess på den fysiske maskinen. Men docker-orkestrering krevde fortsatt at utviklingsteam bygde et orkestreringssystem. Og når tjenesteprosessen inne i docker ble koblet til den fysiske maskinens nettverk og filsystem, ble orkestrering svært vanskelig.

I 2014 begynte statsløse tjenester å bli den dominerende trenden. Det året ble Kubernetes og AWS Lambda født. De beskrev fremtiden for statsløse tjenester fra ulike vinkler. Statsløse tjenester betydde at tjenestelogikk unngikk kobling til nettverksadresser og ikke lenger var lokalt avhengig av vedvarende filsystemer.

Så kom 10-årene med cloud native, og bølgen av statsløse tjenester ga opphav til en rekke cloud native-infrastruktur, som:

• Tjenestegatewayer Istio/Linkerd/Envoy/Treafik
• CI/CD-plattformer Argo CD / Flux
• Observabilitetsplattformer Prometheus/Grafana/ELK Stack
• Kallkjedeanalyse Jaeger/Zipkin/OpenTelemetry
• Lagring Rook/MinIO/JuiceFS

Og nå står vi ved et nytt startpunkt. For ti år siden var en beregningsenhet en java/python api-tjenesteprosess. Fra og med i år har denne beregningsenheten blitt en kodeagent.

ACFS er som tiden da man manuelt vedlikeholdt tjenesteprosesser på fysiske maskiner. E2B er som Docker. Uten plattformer for oppgaveorkestrering, observabilitet og distribuert vedvarende lagring, er skalerbarhet fortsatt vanskelig for kodeagenter. Og den serverløse agentinfrastrukturen jeg ser for meg har disse egenskapene:

1. Kan hensiktsmessig lagre kodeagentens sesjoner og arbeidskataloger uten å miste kontekst.
2. Superrask, kan få en kodeagent i gang på under 100 ms.
3. Har logging / metrikk / sporing for agentatferd som er lett å forstå for mennesker, slik at det blir enklere å forstå og justere agentens atferdsmønstre.
4. Utviklere trenger ikke lenger bry seg om detaljer som virtuelle maskiner, containere og andre driftsdetaljer, noe som gjør storskala orkestrering svært enkelt.

Jeg mener at infrastrukturen som kan oppfylle disse kravene allerede finnes, for eksempel har firecracker vist ytelsen og stabiliteten til microVM-er, og det finnes mange valg for distribuerte observabilitetsplattformer og fillagringssystemer. Men som utvikler som har erfaring med å bruke e2b for å kapsle inn claude code, er det fortsatt svært vanskelig å integrere alt dette. For eksempel, når claude code i E2B uventet blir avbrutt av OOM, er det vanskelig for ingeniører å overvåke dette, og enda vanskeligere å hente ut situasjonen og loggene fra det tidspunktet.

Jeg håper utviklere etter 2026 slipper å gå gjennom en så smertefull prosess, akkurat som de fleste ingeniører i 2026 ikke lenger trenger å bruke ssh for å manuelt initialisere fysiske maskiner.

Dette er VM0s drøm. Jeg håper jeg en dag kan styre en kodeagent gjennom et ergonomisk API, slik som:

cosnt agent = vm0.run({
	framework: 'claude-code',
	prompt: 'buy me a coffee'
})