Escalando Managed Agents: separando cérebro e mãos

• O serviço hospedado Managed Agents, para agentes de longa execução, adota uma arquitetura baseada em interfaces que permanece estável mesmo quando o harness muda com a evolução do modelo
• O harness codifica suposições sobre tarefas que o Claude não consegue realizar sozinho, mas, à medida que o modelo evolui, essas suposições se tornam obsoletas (stale), gerando overhead desnecessário
• Assim como um sistema operacional virtualiza o hardware em abstrações como processos e arquivos, o Managed Agents virtualiza componentes do agente (sessão, harness, sandbox), permitindo sua substituição independente
• Ao separar o cérebro (harness) das mãos (sandbox), alcançou melhorias de desempenho com redução de cerca de 60% no p50 TTFT e de mais de 90% no p95
• Esse design passa a atuar como um meta-harness capaz de acomodar futuros harnesses e sandboxes, quaisquer que sejam

---

As suposições do harness ficam obsoletas com a evolução do modelo

• O harness é uma estrutura que codifica suposições sobre tarefas que o Claude não consegue fazer por conta própria, mas, à medida que o modelo evolui, essas suposições deixam de ser necessárias
• No Claude Sonnet 4.5, havia um fenômeno de "context anxiety" em que a tarefa era encerrada cedo quando o limite de contexto se aproximava, então um reset de contexto foi adicionado ao harness
• No Claude Opus 4.5, esse comportamento desapareceu, e a lógica de reset virou código desnecessário
• Como se esperava que o harness continuasse mudando, foi criado o serviço Managed Agents com base em uma interface genérica que não depende de uma implementação específica

Filosofia de design inspirada em sistemas operacionais

• O sistema operacional virtualiza o hardware em abstrações como processos e arquivos, de modo que até programas que ainda não existem possam ser executados
• Assim como o comando read() funciona da mesma forma tanto em disk packs dos anos 1970 quanto em SSDs modernos, a abstração dura mais do que o hardware
• O Managed Agents segue o mesmo padrão e virtualiza os componentes do agente
  • Sessão (session): log append-only de todos os eventos ocorridos
  • Harness: loop que chama o Claude e roteia as chamadas de ferramentas
  • Sandbox: ambiente de execução em que o Claude roda código e edita arquivos

Design inicial: os limites de um contêiner único (o problema do "pet")

• No início, sessão, harness e sandbox eram colocados em um único contêiner
• Isso tinha vantagens, como permitir a edição de arquivos diretamente por syscall e eliminar a necessidade de projetar fronteiras entre serviços
• Porém, surgiu o problema de o contêiner virar um "pet" (uma instância individual que não pode ser substituída)
  • Em caso de falha do contêiner, a sessão era perdida
  • Se ele deixasse de responder, era necessário recuperá-lo manualmente
• Do ponto de vista de depuração, apenas o stream de eventos do WebSocket não permitia identificar onde a falha ocorreu, e acessar o shell do contêiner era difícil porque ele continha dados do usuário
• O harness presumiu que todos os alvos de trabalho estariam dentro do contêiner, então, quando clientes pediam conexão com sua VPC, era necessário fazer peering de rede ou executar o harness no próprio ambiente deles

Separando cérebro e mãos (arquitetura central)

• O "cérebro" (Claude e harness), as "mãos" (sandbox e ferramentas) e a "sessão" (log de eventos) foram separados em interfaces independentes
• Cada componente pode falhar ou ser substituído de forma independente

O harness sai do contêiner

• O harness foi movido para fora do contêiner, passando a chamar o contêiner como qualquer outra ferramenta via execute(name, input) → string
• O contêiner deixa de ser "cattle"? Não, passa de "pet" a "cattle" (instâncias substituíveis)
• Em caso de falha do contêiner, o harness trata isso como erro de chamada de ferramenta e, se o Claude decidir tentar de novo, inicializa um novo contêiner com provision({resources})

Recuperação de falhas do harness

• Como o log de sessão existe fora do harness, não há estado interno que precise sobreviver dentro dele
• Em caso de falha, wake(sessionId) → getSession(id) busca o log de eventos e retoma a partir do último evento
• Durante o loop do agente, o harness mantém um registro durável de eventos com emitEvent(id, event)

Fronteira de segurança

• No design acoplado, código não confiável gerado pelo Claude era executado no mesmo contêiner que as credenciais, permitindo que prompt injection extraísse variáveis de ambiente
• Se um invasor obtivesse o token, poderia criar novas sessões sem restrições e delegar tarefas livremente
• A solução estrutural foi separar as partes de modo que o sandbox jamais possa acessar tokens
• Git: ao inicializar o sandbox com um token de acesso ao repositório, o clone é feito e o remote git local é configurado, permitindo ao agente usar push/pull sem manipular diretamente o token
• Ferramentas customizadas via MCP: o token OAuth é armazenado em um vault seguro, e um proxy dedicado recupera as credenciais do vault com o token associado à sessão ao chamar ferramentas MCP e então acessa o serviço externo

A sessão não é a janela de contexto do Claude

• Tarefas de longa duração frequentemente ultrapassam o tamanho da janela de contexto do Claude, exigindo decisões irreversíveis sobre o que manter
• Compaction: o Claude salva um resumo da janela de contexto
• Ferramenta de memória: o Claude grava contexto em arquivos para poder aprender ao longo das sessões
• Context trimming: remoção seletiva de tokens antigos, como resultados de ferramentas ou blocos de raciocínio
• O descarte irreversível de contexto pode levar a falhas porque é difícil prever quais tokens os turnos futuros vão precisar
• Pesquisas anteriores exploraram armazenar o contexto como um objeto fora da janela de contexto e permitir que o LLM escreva código para acessá-lo programaticamente

Uso do log de sessão no Managed Agents

• A sessão atua como um objeto de contexto que existe fora da janela de contexto
• Ela é armazenada de forma durável no log de sessão, e não em um sandbox ou REPL
• A interface getEvents() permite selecionar fatias posicionais do stream de eventos
  • Continuar lendo a partir do último ponto lido
  • Voltar alguns eventos antes de um momento específico para revisar
  • Reler o contexto anterior a uma ação específica
• Os eventos recuperados podem ser transformados no harness e depois enviados à janela de contexto do Claude
• Essa transformação inclui organização de contexto e context engineering para obter alta taxa de acerto no prompt cache
• A sessão garante apenas armazenamento e consulta duráveis, enquanto o gerenciamento concreto de contexto é delegado ao harness para acompanhar futuras mudanças nas necessidades dos modelos

Muitos cérebros, muitas mãos

Muitos cérebros (Many Brains)

• Separar cérebro e mãos resolveu uma reclamação inicial dos clientes: ao trabalhar com recursos dentro da VPC, o peering de rede deixou de ser necessário
• No design inicial, cada cérebro precisava de um contêiner, então a inferência não podia começar antes do provisionamento do contêiner terminar
• Mesmo sessões que não precisavam de sandbox arcavam com o custo completo de setup do contêiner, incluindo clone do repositório, boot de processos e recuperação de eventos pendentes
• Após a separação, o contêiner é provisionado como chamada de ferramenta apenas quando necessário, eliminando latência desnecessária
• A inferência pode começar assim que a camada de orquestração recupera os eventos pendentes do log de sessão
• Houve redução de cerca de 60% no p50 TTFT e de mais de 90% no p95 TTFT
• Escalar para muitos cérebros passa a ser simplesmente iniciar vários harnesses stateless e conectá-los às mãos apenas quando preciso

Muitas mãos (Many Hands)

• Surgiu a necessidade de conectar cada cérebro a múltiplos ambientes de execução
• Como o Claude precisa raciocinar sobre vários ambientes de execução e decidir como distribuir o trabalho, isso é cognitivamente mais difícil do que um único shell
• No início, por limitação da capacidade do modelo, o cérebro ficava em um único contêiner, mas, com o avanço da inteligência, esse contêiner único passou a ser uma restrição
• No design separado, cada mão é tratada como uma ferramenta execute(name, input) → string
  • Suporta ferramentas customizadas, servidores MCP e ferramentas próprias
  • O harness não precisa saber se o sandbox é um contêiner, um telefone ou um emulador de Pokémon
• Como cérebro e mãos não estão acoplados, também é possível passar mãos entre cérebros

Conclusão: Managed Agents como meta-harness

• É a mesma abordagem pela qual o sistema operacional virtualiza o hardware para acomodar programas que ainda nem existem
• O Managed Agents é um meta-harness que não depende de um harness específico e oferece uma interface genérica para acomodar vários harnesses
• O Claude Code pode ser usado como um harness, e harnesses de agentes especializados em tarefas também podem ser acomodados
• Há uma posição clara quanto à interface: o Claude precisa da capacidade de manipular estado (sessão) e executar computação (sandbox)
• Trata-se de um design de interface voltado para expansão a muitos cérebros e mãos, com operação segura e estável no longo prazo
• Não faz qualquer suposição sobre a quantidade ou localização de cérebros e mãos