Construir um Agente não é fácil.
Um ano atrás, precisávamos gerenciar contexto e memória por conta própria, pensar em RAG e bancos de dados vetoriais, e ajustar com muito cuidado a precisão do uso de ferramentas. O surgimento do Claude Code / Claude Agent SDK mudou tudo isso. Agora, cada vez mais equipes começam a construir Agentes diretamente usando o Claude Agent SDK + VM. Então o problema ficou mais simples? Não.
Rodar o Claude Code em VMs ainda é algo bastante desafiador.
-
Cada sessão de usuário precisa de uma VM independente. Em alguns cenários, a capacidade de persistência das VMs pode ser útil, mas isso também torna as VMs difíceis de atualizar e orquestrar. Por exemplo, do ponto de vista do usuário, ele espera que o software instalado na VM ainda esteja disponível meses depois. Mas as partes da VM que se comunicam com a camada de orquestração também precisam ser capazes de receber atualizações.
-
Criar e orquestrar VMs em larga escala. Um único cluster k8s suporta a orquestração de cerca de alguns milhares de pods, o que é suficiente para clusters de serviços de aplicação. Mas não é bem o bastante para cenários em que cada sessão precisa iniciar um pod de claude code.
-
Usar soluções de k8s enfrenta a latência trazida pelo k8s, tornando difícil alcançar desempenho dentro de 1 segundo.
-
Usar soluções de e2b exige fazer a persistência por conta própria, e o upload de arquivos / download de arquivos são ambos muito lentos.
-
A solução de e2b não atende a requisitos específicos de ambiente de rede, e a implantação privada é trabalhosa.
Como resolvemos esses problemas? Vamos aprender com a história. Quando o calendário volta para mais de uma década atrás, em 2012, não havia serverless no mundo, não havia k8s e não havia docker. Os engenheiros de backend precisavam manter manualmente um processo de serviço em uma máquina física para rodar um serviço. Naquela época, ssh e ansible eram ferramentas padrão para os engenheiros de servidor. Os processos de serviço dependiam fortemente de diversos ambientes de ferramentas na máquina física. Conseguir configurações de ambiente de ferramentas consistentes entre máquinas físicas era muito desafiador, e o escalonamento em larga escala era um grande empreendimento para o qual as equipes precisavam se preparar com muita antecedência. Ainda me lembro de quando um engenheiro mudou o ambiente de uma máquina e esqueceu de sincronizá-lo com o ambiente das outras máquinas, causando um bug fantasma em produção, muito difícil de diagnosticar. Aquele período foi um velho tempo bastante doloroso.
Em 2012, surgiu o docker. O docker empacotou todos os ambientes de ferramentas em uma única imagem, resolvendo o problema da inconsistência de ambiente. A comunidade aos poucos percebeu que um processo de serviço rodando em uma máquina virtual sobre uma máquina física podia ser gerenciado como um processo na própria máquina física. Mas a orquestração do docker ainda exigia que as equipes de engenharia construíssem um sistema de orquestração. E, uma vez que o processo de serviço dentro do docker se tornava acoplado à rede e ao sistema de arquivos da máquina física, a orquestração virava algo muito doloroso.
Em 2014, os serviços stateless começaram a se tornar a tendência dominante. Aquele ano viu o nascimento do Kubernetes e do AWS Lambda. Cada um deles descreveu o futuro dos serviços stateless a partir de ângulos diferentes. Serviços stateless significavam que a lógica do serviço evitava o acoplamento com endereços de rede e não dependia mais localmente de sistemas de arquivos persistentes.
Então vieram os 10 anos de cloud native; a onda de serviços stateless deu origem a um grande lote de infraestrutura cloud native, como:
- Gateways de serviço Istio/Linkerd/Envoy/Treafik
- Plataformas de CI/CD Argo CD / Flux
- Plataformas de observabilidade Prometheus/Grafana/ELK Stack
- Análise de cadeia de chamadas Jaeger/Zipkin/OpenTelemetry
- Armazenamento Rook/MinIO/JuiceFS
E agora estamos em um novo começo. Dez anos atrás, uma unidade de computação era um processo de serviço de API em java/python. A partir deste ano, essa unidade de computação se tornou um coding agent.
O ACFS é como a era de manter manualmente processos de serviço em máquinas físicas. O E2B é como o Docker. Sem plataformas de orquestração de tarefas, plataformas de observabilidade e capacidades de armazenamento distribuído de estado persistente, a escalabilidade ainda é algo difícil para coding agents. E a Serverless Agent Infra que eu espero tem estas capacidades:
- Capaz de persistir adequadamente as sessões e os diretórios de trabalho do coding agent sem perder contexto.
- Super rápida, capaz de colocar um coding agent para trabalhar em até 100ms.
- Possui Logging / Metric / Tracing para o comportamento do Agente que seja fácil de os humanos entenderem, tornando mais simples para as pessoas compreenderem e ajustarem os padrões de comportamento do Agente.
- Os desenvolvedores não precisam mais se preocupar com detalhes como máquinas virtuais, contêineres e outros detalhes de ops, tornando a orquestração em larga escala muito fácil.
Acho que toda a infraestrutura capaz de atender a essas capacidades já está pronta; por exemplo, o firecracker validou o desempenho e a estabilidade das microVMs, e há também muitas opções de plataformas de observabilidade distribuída e sistemas de armazenamento de arquivos. Mas, como um desenvolvedor que já passou pela experiência de usar o e2b para encapsular o claude code, integrar tudo isso ainda é muito difícil. Por exemplo, quando o claude code no E2B é inesperadamente interrompido por OOM, é difícil para os engenheiros monitorarem isso, e ainda mais difícil obter o cenário e os logs daquele momento.
Espero que os desenvolvedores depois de 2026 não precisem passar por um processo tão doloroso, assim como a maioria dos engenheiros em 2026 já não precisa usar ssh para inicializar máquinas físicas manualmente.
Esse é o sonho da VM0. Espero que um dia eu possa dirigir um coding agent por meio de uma API ergonômica, assim:
cosnt agent = vm0.run({
framework: 'claude-code',
prompt: 'buy me a coffee'
})
