No Dia 1 eu disse que a Márcia virou um agente monolítico. Hoje eu quero ser mais preciso: o problema não é “um agente grande”. É um agente sem fronteiras.

Monólito não é tamanho. É acoplamento.

Quando você junta memória, execução operacional, escrita, pesquisa e rotinas no mesmo contexto, o resultado é previsível. Comportamento errático, regressões, custo cognitivo subindo. Funciona… até o dia em que não funciona. E aí ninguém sabe se foi bug, estado, contexto, prompt, ou simplesmente interferência entre responsabilidades.

O que eu estou construindo é uma migração arquitetural. Estou saindo de uma agente monolítica para uma agente distribuída. Uma orquestradora, que conversa comigo e coordena o trabalho, e um conjunto de clones leves, cada um com um escopo e um contrato.

Isso não é “ter mais agentes”. É tirar decisões de design do improviso e colocar em fronteiras. Pesquisa deixa de ser “modo mental” e vira processo. Escrita deixa de ser “texto” e vira pipeline. Operação deixa de ser “tarefas que eu lembro” e vira rotina verificável.

Eu quero autonomia com governança. Clones com responsabilidade clara, entradas e saídas definidas, e persistência no Vault. A memória é compartilhada como componente, não como um estado interno invisível preso no workspace de um agente.

Slack não entrou como capricho. Entrou como topologia. WhatsApp e Telegram são ótimos para falar comigo e com a Márcia principal. São ruins para um time. Slack dá separação de contexto por agente, preserva histórico, reduz ruído e deixa cada responsabilidade num espaço próprio.

Na prática, o desenho vira quatro coisas que se encaixam: um componente de memória (Vault + KG) desacoplado, uma orquestradora (Márcia principal) como porta de entrada, especialistas (clones) para tarefas com método, e rotinas (cron/heartbeat) para o que é repetível e chato.

Os clones que já fazem sentido nessa arquitetura são evidentes. Um para pesquisa profunda. Um para VIPs, porque VIP não é notícia, é sinal. Um para escrita longa, porque texto bom não sai de um único passe. E um para transcrições e reuniões, porque transformar áudio em decisão e registro é uma disciplina própria.

O ganho real disso é redução de interferência. Menos mistura de contexto. Menos regressão por acoplamento. Mais previsibilidade.

A regra que eu estou usando é simples. Se é rotina repetível, vira clone ou cron. Se é produção com método, vira especialista. Se é decisão contextual, fica na orquestração. O objetivo é que a Márcia principal deixe de ser “a que executa tudo” e vire “a que coordena tudo”.

Para extrair uma responsabilidade, eu só preciso responder três perguntas. Existe uma saída clara (arquivo, relatório, estado)? Existe um procedimento repetível (passos, fontes, limites)? Existe um modo de testar que não dependa de “confiança”? Se as três respostas forem sim, extrair é quase sempre a decisão certa.

O plano de execução também é pragmático. Primeiro separar memória. Depois separar comunicação. Depois extrair uma capacidade processual (pesquisa ou escrita). Depois extrair a primeira rotina chata (VIPs é um bom candidato). Depois consolidar contratos. Só então limpar o monólito.

Em resumo: eu não estou “melhorando um bot”. Eu estou desenhando uma topologia de trabalho. Eu estou transformando a Márcia de faz-tudo para coordenadora de um time. E isso é o que torna o sistema escalável.

Arquitetura de agentes continua sendo arquitetura de software. Só que agora o legado responde.