Vercel publiserte mandag Open Agents på GitHub som vercel-labs/open-agents, et open-source template for å kjøre kode-agenter i bakgrunnen mot dedikerte sandbox-VM-er. InfoQ omtalte slippet samme dag. Repoet ligger på 4 268 stjerner og 491 forks etter en ukes tid og er pushet senest 29. april.
Arkitekturen har tre adskilte lag. Web-laget håndterer autentisering, sesjoner og strømming. Agent-laget kjører som en durable workflow. Kode kjøres i en isolert VM med filsystem, shell og dev-server. Det viktige designvalget er at agenten ikke kjører inni VM-en, men snakker med den via verktøy som filoperasjoner, søk og shell-kommandoer. Dermed kan agentens livssyklus og sandkassens livssyklus utvikle seg uavhengig: sandkasser kan pause, hibernere og våkne igjen mens agenten lever videre.
«You mentioned that the separation between VM and agent is the main point of the project. I think this slows down agentic development in the mid to long run. It probably scales better, but you limit the freedom of the agent.» — Michiel Voortman, kommentar på InfoQ
Den kritikken peker på en reell avveining. Vercel har valgt skalerbarhet og isolasjon over rå agent-frihet. Hver agent får verktøy mot maskinen, ikke maskinen selv. For deg som bygger langtkjørende agenter er gevinsten at workflows ikke dør med en HTTP-forespørsel. Sesjoner kan resumes ved å koble seg på workflow-strømmen igjen, og sandkasser bruker snapshot-basert state for å gjenopprette miljøet etter inaktivitet.
Kravlisten er nøktern: PostgreSQL for state, OAuth for innlogging, GitHub-integrasjon for repo-cloning og PR-automatisering. Redis er valgfritt cache-lag. Voice-input går via ElevenLabs. Hele greia er ment som en mal du forker og tilpasser, ikke en ferdig SaaS.
Hva bør du gjøre?
- Klon vercel-labs/open-agents og les hvordan agent og sandkasse er koblet via verktøyabstraksjon. Der bor designvalget.
- Sammenlign mot Cloudflares agent-runtime og E2Bs sandbox-SDK før du velger plattform. De tre løser samme problem med ulike avveininger.
- Hvis du allerede kjører på Vercel, test deploy-flyten direkte. Hvis ikke, vurder om PostgreSQL- og OAuth-kravet rettferdiggjør oppsettet for ditt prosjekt.