Een agent bouwen is niet eenvoudig.
Een jaar geleden moesten we zelf context en geheugen beheren, nadenken over RAG en vector-databases, en het gebruik van tools zeer nauwkeurig afstellen. De opkomst van Claude Code / Claude Agent SDK heeft dit allemaal veranderd. Steeds meer teams bouwen nu direct agents met Claude Agent SDK + VM. Is het probleem daarmee eenvoudiger geworden? Nee.
Het draaien van Claude Code in VM's blijft een grote uitdaging.
-
Elke gebruikerssessie vereist een onafhankelijke VM. In sommige scenario's is de persistentie van VM's nuttig, maar het maakt VM's ook lastig te upgraden en te orkestreren. Gebruikers verwachten bijvoorbeeld dat geïnstalleerde software op de VM maanden later nog steeds werkt. Maar de onderdelen op de VM die met de orkestratielaag communiceren, moeten ook upgrades kunnen ontvangen.
-
VM's op grote schaal aanmaken en orkestreren. Een enkele k8s-cluster ondersteunt de orkestratie van enkele duizenden pods, wat voldoende is voor applicatieserviceclusters. Maar het is niet genoeg voor scenario's waarin elke sessie een claude code-pod moet starten.
-
K8s-oplossingen brengen vertraging met zich mee, waardoor het moeilijk is om prestaties binnen 1 seconde te halen.
-
Bij e2b-oplossingen moet je zelf persistentie regelen, en bestanden uploaden/downloaden gaat erg traag.
-
De e2b-oplossing voldoet niet aan specifieke netwerkeisen en private deployment is omslachtig.
Hoe lossen we deze problemen op? Laten we leren van de geschiedenis. Meer dan tien jaar geleden, in 2012, bestonden serverless, k8s en docker nog niet. Backend-engineers moesten handmatig een serviceproces op een fysieke machine onderhouden om een dienst te draaien. Destijds waren ssh en ansible standaardtools voor serverengineers. Serviceprocessen waren sterk afhankelijk van de toolomgevingen op de fysieke machine. Het consistent configureren van toolomgevingen op verschillende fysieke machines was erg lastig, en grootschalig opschalen vergde veel voorbereiding. Ik herinner me nog dat een engineer de omgeving van één machine wijzigde en vergat deze aan te passen op andere machines, wat leidde tot een lastig te traceren bug in productie. Dat was een pijnlijke periode.
In 2012 verscheen docker. Docker verpakte alle toolomgevingen in één image en loste het probleem van inconsistente omgevingen op. De community realiseerde zich dat een serviceproces in een virtuele machine op een fysieke machine beheerd kon worden als een proces op de fysieke machine. Maar voor docker-orkestratie moesten engineeringteams nog steeds een orkestratiesysteem bouwen. En zodra het serviceproces in docker gekoppeld raakte aan het netwerk of bestandssysteem van de fysieke machine, werd orkestratie erg lastig.
In 2014 werden stateless services de mainstream. Dat jaar ontstonden Kubernetes en AWS Lambda. Zij beschreven elk op hun eigen manier de toekomst van stateless services. Stateless services betekenden dat servicelogica niet meer gekoppeld was aan netwerkadressen en niet langer lokaal afhankelijk was van een persistent bestandssysteem.
Toen brak het tijdperk van cloud native aan, de 10-jaren. De golf van stateless services bracht een reeks cloud native-infrastructuren voort, zoals:
- Servicegateways Istio/Linkerd/Envoy/Treafik
- CI/CD-platforms Argo CD / Flux
- Observability-platforms Prometheus/Grafana/ELK Stack
- Call chain-analyse Jaeger/Zipkin/OpenTelemetry
- Opslag Rook/MinIO/JuiceFS
En nu staan we aan een nieuw begin. Tien jaar geleden was een rekeneenheid een java/python api-serviceproces. Vanaf dit jaar is deze rekeneenheid een coding agent geworden.
ACFS lijkt op het tijdperk waarin serviceprocessen handmatig op fysieke machines werden beheerd. E2B is vergelijkbaar met Docker. Zonder taakorkestratieplatforms, observability-platforms en mogelijkheden voor gedistribueerde persistente opslag blijft schaalbaarheid lastig voor coding agents. De Serverless Agent Infra die ik voor ogen heb, beschikt over deze mogelijkheden:
- Kan de sessies en werkmappen van de coding agent adequaat persistent opslaan zonder context te verliezen.
- Supersnel, een coding agent werkt binnen 100ms.
- Beschikt over Logging / Metrics / Tracing van agentgedrag die voor mensen begrijpelijk zijn, zodat gedragspatronen van agents makkelijker te begrijpen en aan te passen zijn.
- Ontwikkelaars hoeven zich niet meer bezig te houden met details als virtuele machines, containers en andere operationele details, waardoor grootschalige orkestratie eenvoudig wordt.
Ik denk dat alle infrastructuur die aan deze eisen voldoet al beschikbaar is. Firecracker heeft bijvoorbeeld de prestaties en stabiliteit van microVM's aangetoond, en er zijn veel opties voor gedistribueerde observability-platforms en bestandsopslagsystemen. Maar als ontwikkelaar die ervaring heeft met het inpakken van claude code met e2b, is het integreren van deze onderdelen nog steeds erg lastig. Bijvoorbeeld, wanneer claude code in E2B onverwacht wordt onderbroken door OOM, is het moeilijk voor engineers om dit te monitoren, laat staan om de situatie en logs op dat moment te achterhalen.
Ik hoop dat ontwikkelaars na 2026 niet meer door zo'n pijnlijk proces hoeven, net zoals de meeste engineers in 2026 niet meer handmatig fysieke machines hoeven te initialiseren met ssh.
Dit is de droom van VM0. Ik hoop dat ik op een dag een coding agent kan aansturen via een ergonomische API, zoals:
cosnt agent = vm0.run({
framework: 'claude-code',
prompt: 'buy me a coffee'
})
