Existe um momento em todo projeto de software onde você percebe que estava construindo a coisa errada. Você passou semanas escrevendo um roteador de mensagens, um motor de execução de ferramentas, um gerenciador de estado de conversa e um sistema de retry — e então descobre que o provedor de IA já cuida de tudo isso, melhor do que você conseguiria, em uma única chamada de API.
Esse momento é o que levou à arquitetura do NanoClaw. O núcleo inteiro — a parte que transforma uma mensagem do WhatsApp em uma resposta de agente de IA com uso de ferramentas, navegação web, acesso a arquivos e conversa multi-turno — tem aproximadamente 500 linhas de TypeScript. Não são 500 linhas de código cola que importam 50.000 linhas de framework. Quinhentas linhas, no total, construídas sobre o Claude Agent SDK da Anthropic.
A reação dos desenvolvedores que leem o código-fonte pela primeira vez geralmente é de descrença, seguida pela pergunta que importa: "Cadê o resto?"
O Que o Claude Agent SDK Realmente Faz
A maioria dos frameworks de agentes de IA existe porque, historicamente, as APIs de modelos de linguagem eram stateless e simples. Você enviava um prompt, recebia uma resposta. Se quisesse uso de ferramentas, tinha que construir o loop de execução de ferramentas você mesmo. Se quisesse conversa multi-turno, tinha que gerenciar o histórico de mensagens você mesmo. Se quisesse que o modelo escolhesse entre múltiplas ferramentas, tinha que construir a lógica de roteamento você mesmo.
O Claude Agent SDK muda essa equação fundamentalmente. O SDK não apenas chama a API do Claude — ele roda um loop de agente. Você fornece um prompt de sistema, um conjunto de ferramentas e uma mensagem do usuário. O SDK cuida de todo o resto: envia a mensagem para o Claude, recebe a resposta, verifica se o Claude quer usar uma ferramenta, executa a ferramenta, envia o resultado de volta para o Claude e repete até o Claude produzir uma resposta final. O loop inteiro de uso de ferramentas — aquilo que a maioria dos frameworks gasta milhares de linhas implementando — é uma única chamada de função. Isso não é um wrapper fino. O SDK lida com streaming, lógica de retry, contagem de tokens e estado de conversa. Ele gerencia o vai e vem entre o Claude e as ferramentas ao longo de múltiplos turnos, tratando casos extremos como falhas na execução de ferramentas e limites de janela de contexto. A complexidade que o NanoClaw não precisa implementar não está faltando — ela foi empurrada para dentro de um SDK bem testado, mantido pela própria equipe de engenharia da Anthropic.
O Que o NanoClaw Realmente Constrói
Se o SDK cuida do loop do agente, o que as 500 linhas do NanoClaw realmente fazem? A resposta é tudo ao redor do loop — as partes que são específicas de rodar um assistente pessoal de IA, e não apenas chamar uma API.
A primeira responsabilidade é a integração de canal. O NanoClaw se conecta ao WhatsApp via a biblioteca Baileys, recebe mensagens e as roteia para o container de agente correto. Esse é o elo entre "alguém mandou uma mensagem no WhatsApp" e "um agente precisa processar essa mensagem." Não é código complicado, mas é código essencial — sem ele, o agente não tem como alcançar os usuários onde eles já estão.
A segunda responsabilidade é a orquestração de containers. Cada conversa de agente roda dentro do seu próprio container Linux — Apple Container no macOS, Docker no Linux. O NanoClaw cria containers, monta os diretórios corretos, passa segredos via stdin e coleta respostas. Essa é a fronteira de segurança que impede um agente comprometido de acessar qualquer coisa fora do seu sandbox. O gerenciamento de ciclo de vida do container tem talvez 80 linhas de código, mas essas 80 linhas são a diferença entre um agente que pode ser confiado com credenciais reais e um que não pode.
A terceira responsabilidade é a memória persistente. O NanoClaw mantém um banco de dados SQLite de conversas, estado de grupo e tarefas agendadas. Cada grupo do WhatsApp recebe seu próprio arquivo CLAUDE.md que serve como memória de longo prazo do agente para aquele grupo. O sistema de memória é simples — intencionalmente — porque a parte complexa da memória (decidir o que é relevante, o que lembrar, como usar contexto) é tratada pelo próprio Claude.
A quarta responsabilidade são as tarefas agendadas. Usuários podem pedir ao agente para fazer coisas em horários específicos — "me lembre às 15h" ou "verifique este site toda manhã." O agendador tipo cron do NanoClaw dispara containers de agentes nos horários certos, o que é uma funcionalidade pequena mas genuinamente útil que transforma um chatbot reativo em um assistente proativo.
Por Que 500 Linhas Importa
A contagem de linhas não é uma métrica de vaidade. É uma medida direta da superfície de manutenção, da superfície de bugs e da carga cognitiva necessária para entender o sistema.
Quando um bug aparece no núcleo do NanoClaw, existem 500 linhas onde ele pode estar. Um desenvolvedor pode ler toda a base de código em menos de uma hora e entender cada decisão que foi tomada. Compare isso com frameworks de 50.000 linhas de código central — encontrar um bug significa navegar abstrações, entender sistemas de plugins e rastrear execução através de camadas de indireção que existem para suportar funcionalidades que você talvez nem use.
As implicações de segurança são igualmente concretas. Cada linha de código é uma vulnerabilidade em potencial. O núcleo de 500 linhas do NanoClaw tem uma superfície de ataque menor que o parser de configuração da maioria dos frameworks. O isolamento por container, a passagem de segredos via stdin, as listas de permissão de montagem — essas funcionalidades de segurança são implementadas em código pequeno o suficiente para ser auditado completamente em uma tarde.
E a história de atualização é simples. Quando a Anthropic lança uma nova versão do Claude Agent SDK com melhor uso de ferramentas, streaming mais rápido ou novas capacidades, o NanoClaw recebe essas melhorias atualizando uma única dependência. Não existe camada de abstração de framework que precise ser atualizada para expor novas funcionalidades do SDK. O SDK é o framework. ## A Filosofia de Não Construir
A parte mais difícil da arquitetura do NanoClaw não foi construí-la — foi decidir o que não construir. A tentação de adicionar um motor de execução de ferramentas customizado, um sistema sofisticado de recuperação de memória, uma camada de abstração multi-provedor, um marketplace de plugins — tudo isso são coisas que outros frameworks construíram, e são todas coisas que o NanoClaw deliberadamente não tem.
Cada uma dessas funcionalidades adicionaria milhares de linhas de código, dezenas de bugs potenciais e semanas de carga de manutenção. E cada uma duplicaria funcionalidade que o Claude Agent SDK já fornece ou que o próprio Claude lida melhor do que qualquer código escrito à mão conseguiria.
O resultado é um projeto onde as decisões interessantes são arquiteturais, não de implementação. Como os containers devem ser isolados? Como os segredos devem ser passados? Como a memória deve ser delimitada por grupo? Essas são as perguntas que importam para um assistente pessoal de IA, e são as perguntas que as 500 linhas do NanoClaw se dedicam a responder.
Da próxima vez que você avaliar um framework de agentes de IA, não conte funcionalidades. Conte linhas. O framework com menos linhas não é o menos capaz — pode ser o que entendeu o problema bem o suficiente para deixar o provedor de IA fazer o trabalho pesado.