Quando a Anthropic publicou o paper "Dive into Claude Code", esperávamos encontrar a arquitetura de um sistema dominado por IA. Encontramos o oposto. O Claude Code tem 1.900 arquivos TypeScript. Só 1,6% é lógica de IA. Os outros 98,4% são infraestrutura de controle. Na Tech86, isso confirmou o que vemos na prática: a inteligência do modelo não é o produto. O harness é o produto. Se dois times usam modelos similares, o time com melhor harness entrega o agente mais seguro e confiável.
O núcleo é um while-loop — e isso é correto
O coração do Claude Code é um queryLoop implementado como gerador assíncrono. Monta contexto, chama o modelo, executa ferramenta, repete. Simples. Quem espera complexidade no loop central está procurando no lugar errado.
Toda a complexidade está nos sistemas ao redor desse loop. O QueryEngine abstrai o loop para as interfaces — CLI, SDK, IDE. O loop não sabe nada sobre permissões, compactação ou persistência. Ele só itera. Essa separação é deliberada: o núcleo permanece previsível enquanto a complexidade cresce nas camadas periféricas.
Na nossa experiência, times que tentam empilhar lógica no loop central criam sistemas frágeis. Cada nova capacidade adiciona acoplamento. O Claude Code evita isso por design — o loop é o último lugar onde você quer complexidade.
Cinco camadas que não compartilham modos de falha
A arquitetura se divide em cinco camadas independentes. Surface Layer: CLI, SDK, IDE — as interfaces que o usuário toca. Core Layer: o queryLoop como gerador assíncrono. Safety/Action Layer: framework de permissões deny-first, hooks, shell sandbox. State Layer: hierarquia CLAUDE.md, auto-memory, transcritos JSONL append-only. Backend Layer: execução real (Bash, PowerShell) e integrações MCP.
A independência entre camadas não é acidental. Se a camada de segurança falha, a camada de estado captura a violação no transcript. Se o backend executa algo inesperado, a camada de segurança intercepta na próxima iteração. O sistema degrada de forma graciosa porque IA e sistema operacional não compartilham modos de falha.
Já vimos projetos onde a camada de segurança e a camada de execução compartilham estado. Quando uma falha, a outra também cai. É o padrão de design mais perigoso em sistemas agênticos: acoplamento entre quem decide e quem executa.
O pipeline de contexto como recurso escasso
Contexto é o bem mais escasso em um agente de IA. O Claude Code trata isso com seriedade de engenharia. Cinco shapers sequenciais processam o contexto antes de cada chamada ao modelo: budget reduction, snip, microcompact, context collapse e auto-compact. Cada um opera em um nível diferente de granularidade.
O resultado é que o modelo sempre recebe o contexto mais relevante dentro do orçamento disponível. Não é mágica — é um pipeline determinístico que prioriza, resume e compacta. A alternativa, que vemos com frequência, é estourar o limite de tokens e torcer para o modelo se virar. Não funciona.
O transcript é append-only. Nenhuma mutação direta. Trilha de auditoria imutável. Operações de rewind e fork são reconstruídas a partir do log, não restauradas de snapshots. Isso significa que qualquer estado pode ser reproduzido a qualquer momento. Em auditoria de segurança, essa propriedade vale mais do que qualquer funcionalidade de IA.
Permissões deny-first e o problema da fadiga de aprovação
O framework de permissões tem 7 modos técnicos. É deny-first: nada executa sem aprovação explícita. O yoloClassifier avalia se uma ação pode rodar em modo auto. O bashSecurity faz verificação AST em comandos shell antes da execução. É camada sobre camada.
Mas aqui está o dado que importa: usuários aprovam 93% dos prompts de permissão. Fadiga de aprovação é real. O sistema responde com automação inteligente, não com mais prompts. Classificar automaticamente o que é seguro rodar sem confirmação é tão importante quanto bloquear o que não é.
E tem mais: ao retomar uma sessão, permissões não são restauradas. O agente nunca herda autorizações passadas. Isso contradiz a intuição de "facilidade", mas é o design correto. Sessões são fronteiras de confiança. Herdar permissões de uma sessão anterior é herdar contexto que pode ter mudado.
Não existe blueprint universal — mas o harness é universal
O paper compara o Claude Code com o OpenClaw e mostra algo revelador: as mesmas perguntas de design produzem respostas arquiteturais diferentes quando o contexto de deployment muda. CLI interativa versus execução autônoma em CI/CD geram arquiteturas fundamentalmente diferentes.
Mas uma coisa é universal: se dois times usam modelos similares, o time com melhor harness — permissões, engenharia de contexto, isolamento de execução, persistência — entrega o agente mais seguro e confiável. A autonomia agêntica não nasce da liberdade do modelo. Nasce do rigor do harness.
Na Tech86, aplicamos essa lógica em cada projeto de arquitetura de IA que desenhamos. Não começamos pelo modelo. Começamos pelo harness — porque é ele que determina se o sistema vai funcionar na sexta-feira à noite quando ninguém está olhando.
O que isso significa para o seu projeto
A lição do Claude Code não é "copie essa arquitetura". É "entenda o princípio". O princípio é que o harness é o produto. O modelo é commodity — todo mundo tem acesso aos mesmos modelos. O que diferencia um agente confiável de um demo bonito é a infraestrutura de controle ao redor.
Se você está construindo agentes de IA e investindo 80% do esforço na lógica do modelo, está investindo no lugar errado. O modelo já é bom. O que falta na maioria dos projetos é o harness que transforma capacidade em confiabilidade. É por isso que na Tech86 nossa consultoria de arquitetura de IA começa sempre pela mesma pergunta: como o seu sistema falha? Não como ele funciona — como ele falha. A resposta a essa pergunta define o harness que você precisa.