O Claude Code já tem agentes. Você pode criar subagentes dentro de uma sessão. Eles pesquisam, rodam comandos, leem arquivos e trazem o resultado. Funciona.

Mas esses agentes são todos Claude.

Mesmo modelo. Mesma assinatura. Mesmo orçamento de contexto. Cada agente que você cria consome do mesmo estoque de tokens. Se você precisa de cinco agentes pesquisando cinco partes diferentes de uma base de código, são cinco consumos paralelos no mesmo plano do Claude. Em sessões pesadas, a conta sobe rápido.

E se os agentes não precisassem ser Claude?

A ideia

Use o Claude Code como orquestrador. O cérebro que planeja, delega e sintetiza. Mas deixe que ele crie agentes que rodam em modelos externos — Codex, Gemini, modelos locais do Ollama, o que estiver disponível e for barato para a tarefa.

Esses agentes não precisam ser brilhantes. Precisam ser minuciosos. Varra este diretório. Leia estes arquivos. Busque este padrão. Resuma este módulo. Encontre todos os lugares em que esta função é chamada. Isso é trabalho braçal. Não exige o modelo mais caro da sala.

A parte crítica é como os resultados voltam.

Em vez de passar texto bruto por uma comunicação frágil entre modelos, cada agente guarda o que encontrou direto na memória do SynaBun, usando a ferramenta remember. Ele recebe de volta um ID de memória. Esse ID é tudo o que ele manda para o Claude.

A fase de planejamento do Claude não precisa interpretar o stream de outro modelo. Ele chama recall com os IDs, recebe resultados estruturados do sistema de memória e monta o plano a partir de contexto indexado, pesquisável e persistente.

O sistema de memória vira o barramento.

Por que essa arquitetura funciona

O problema de sempre em workflows multimodelo é a passagem de bastão. O modelo A produz uma saída. Você precisa levar essa saída até o modelo B. Então você encadeia texto, interpreta JSON, monta APIs de wrapper ou enfia tudo em um arquivo compartilhado. Cada abordagem é frágil do seu jeitinho particular.

A memória do SynaBun contorna isso porque já foi projetada para ser a camada de contexto compartilhado entre diferentes sessões de IA.

Quando um agente externo chama remember, ele não está só despejando texto. Está criando uma entrada de memória categorizada, com etiquetas, classificada por importância, pesquisável por semântica e com um UUID estável. Essa entrada vive no armazenamento vetorial do SynaBun. Ela sobrevive à sessão. Pode ser recuperada por conteúdo, por etiqueta, por projeto, por categoria. Não é um artefato temporário. É conhecimento indexado.

Então a passagem de bastão fica assim:

  1. O Claude identifica o que precisa ser pesquisado
  2. O Claude cria um agente externo (Codex, Gemini, modelo local) com uma tarefa clara
  3. O agente faz o trabalho com as ferramentas a que tem acesso
  4. O agente chama remember com o que encontrou — conteúdo estruturado, etiquetas relevantes, arquivos relacionados, nível de importância adequado
  5. O agente devolve o ID da memória para o Claude
  6. O Claude chama recall ou lê a memória direto pelo ID
  7. A fase de planejamento do Claude usa resultados indexados de verdade, não blocos de texto bruto

Sem parsing intermediário. Sem negociar formato de texto. Sem "aqui está minha saída em uma string gigante, boa sorte". Só um UUID apontando para memória estruturada.

Do que o agente externo precisa

Pouca coisa. Essa é a graça.

O agente externo precisa de acesso ao servidor MCP do SynaBun. Mais especificamente, precisa da ferramenta remember. Se também tiver recall, pode conferir o que os agentes anteriores já encontraram antes de repetir trabalho. Mas a única ferramenta indispensável é remember.

O agente não precisa entender todo o conjunto de ferramentas do SynaBun. Não precisa do navegador, do quadro branco, do sistema de loop nem das ferramentas do Discord. Precisa fazer sua tarefa de pesquisa e guardar o resultado em uma única chamada estruturada.

Isso deixa a integração leve. Qualquer modelo que saiba usar ferramentas MCP — ou qualquer wrapper que traduza chamadas de ferramenta para MCP — pode participar.

O Codex já tem suporte a MCP. Modelos locais via OpenCode já se conectam ao MCP do SynaBun. A infraestrutura já existe.

O que o Claude recebe de volta

É essa parte que muda a fase de planejamento.

Hoje, quando o Claude Code cria um subagente, toda a saída do agente volta como um blocão de texto na conversa. O Claude precisa interpretar aquilo, extrair as partes úteis e segurar tudo no contexto enquanto planeja. Se você cria cinco agentes, recebe cinco blocões disputando espaço na janela de contexto.

Com agentes indexados em memória, o Claude recebe cinco UUIDs. Minúsculos. Baratos. Sem pressão no contexto.

Quando entra na fase de planejamento, o Claude puxa exatamente o que precisa:

  • recall com um ID de memória específico, para pegar tudo o que um agente encontrou
  • recall com uma consulta semântica, para buscar nos resultados de todos os agentes
  • recall com um filtro de etiqueta, para pegar os resultados sobre um subsistema específico
  • recall com um filtro de projeto, para pegar tudo o que importa para o trabalho atual

O agente de planejamento não está se afogando em saída bruta. Está consultando uma base de conhecimento indexada, construída em paralelo por modelos mais baratos fazendo pesquisa focada.

É um jeito fundamentalmente diferente de planejar.

A conta

Não é só uma questão de elegância de arquitetura. É uma questão de custo.

O Claude Opus é caro. Vale a pena para planejamento, síntese, raciocínio de arquitetura e as decisões finais de implementação. Dá para dizer que é exagero para "leia todos os arquivos deste diretório e me diga o que cada um exporta".

Se você conseguir repassar pesquisa e indexação para modelos mais baratos — Codex para entender código, modelos locais para varrer arquivos, modelos de nuvem mais leves para reconhecer padrões — e mandar só os resultados estruturados de volta ao Claude para a fase cara de planejamento, o custo por sessão muda de verdade.

Você paga preço de Opus por trabalho de nível Opus: síntese, julgamento, planejamento. E paga preço de commodity por trabalho de commodity: ler, varrer, resumir, catalogar.

O sistema de memória é a camada que torna essa divisão possível sem perder coerência.

Como isso funciona na prática

Imagine que você está começando uma refatoração grande. Precisa entender o estado atual de cinco subsistemas antes de planejar as mudanças.

Sem esse padrão: o Claude lê os cinco subsistemas em sequência, queimando tokens caros em leituras de arquivo e resumos, comprimindo o contexto pelo caminho e correndo o risco de perder detalhes do primeiro subsistema quando terminar o quinto.

Com esse padrão:

  1. O Claude olha a tarefa e identifica cinco perguntas de pesquisa
  2. O Claude cria cinco agentes — talvez o Codex para os módulos de backend, um modelo local para os arquivos de configuração, o Gemini para os recursos da API
  3. Cada agente pesquisa seu subsistema e chama remember com resultados estruturados (o que o módulo faz, suas dependências, sua API pública, problemas conhecidos, padrões relevantes)
  4. Cada agente devolve um ID de memória
  5. O Claude entra no planejamento com cinco IDs de memória
  6. O Claude faz recall de cada um, recebe achados limpos e estruturados e monta um plano de refatoração a partir de um contexto completo e indexado

A pesquisa rodou em paralelo, em modelos mais baratos. O planejamento acontece no Claude, com acesso total a resultados indexados e pesquisáveis. Sem estouro de contexto. Sem detalhes perdidos. Sem reler arquivos que o Claude já pagou para varrer.

O que ainda falta, sem rodeios

Isso ainda não existe como um recurso pronto para usar. As peças estão no lugar, mas a camada de orquestração ainda precisa ser construída.

O que falta hoje:

  • O Claude Code não cria agentes de outros modelos nativamente. Hoje o sistema de subagentes é só Claude. Para criar um agente com um modelo externo, você precisa de um wrapper, de um webhook ou de um orquestrador externo que o Claude consiga acionar.
  • A qualidade do uso de ferramentas varia. Nem todo modelo chama ferramentas MCP direito. O Codex é sólido. Os modelos locais via OpenCode estão melhorando. Mas alguns modelos ainda tropeçam em chamadas de ferramenta estruturadas, então a chamada de remember pode precisar de proteções ou de lógica de nova tentativa.
  • A qualidade da memória depende do agente. Um modelo mais barato pode guardar achados incompletos ou mal estruturados. A memória só é tão boa quanto o que o agente escreve. Isso provavelmente pede uma etapa de validação ou um contrato de schema que defina o que são "bons achados".
  • Custo de coordenação. Decidir qual agente fica com qual tarefa, e com qual modelo, já é um problema de planejamento. Dividir demais é pior do que usar o Claude em sequência, se o custo de coordenação passar da economia.

Nada disso é impeditivo. São problemas de engenharia com contornos conhecidos.

Para onde isso vai

A direção está clara, mesmo que a implementação completa não saia amanhã.

O SynaBun já é a camada de memória compartilhada entre Claude Code, Codex, OpenCode e modelos locais. As ferramentas remember e recall já funcionam em todos eles. O sistema de categorias, as etiquetas, o ranking de importância, a busca semântica e o escopo por projeto já estão prontos.

A peça que falta é a orquestração: deixar o Claude Code dizer "rode esta tarefa no Codex, passe a conexão MCP do SynaBun para ele e me traga de volta o ID da memória". Isso é um recurso, não um problema de pesquisa.

Quando essa orquestração existir, a economia do desenvolvimento assistido por IA muda. Você para de pagar preço premium por pesquisa em volume. E passa a pagar preço premium só pelo trabalho que de fato exige raciocínio premium.

E o sistema de memória deixa de ser só uma camada de persistência. Ele vira o protocolo de comunicação entre modelos.

O melhor uso de um modelo caro não é fazer ele cuidar de tudo. É fazer dele o cérebro que dirige modelos mais baratos e sintetiza o trabalho deles.

A memória do SynaBun é a camada que deixa essa passagem de bastão limpa: estruturada, indexada, pesquisável e persistente. Não é um pipe. Não é um dump em arquivo. É uma base de conhecimento compartilhada em que todo agente pode escrever e que o agente de planejamento pode consultar.

Modelos externos como agentes de pesquisa. A memória do SynaBun como barramento. O Claude como arquiteto.

É esse o desenho de desenvolvimento multimodelo que estamos construindo.