Na minha avaliação, a maioria dos sistemas de IA em produção opera como monolito conversacional: um modelo, um system prompt longo, um catálogo de ferramentas que cresce sem critério, com um loop tentando resolver tudo numa única sessão de contexto. Funciona enquanto o escopo permanece estreito. Quando ele cresce, o comportamento degrada de formas que já descrevi em posts anteriores, desde ambiguidade no roteamento até regressão silenciosa por instruções concorrentes. O que ainda não tratei é a transição estrutural que separa esse regime monolítico de um regime distribuído, onde agentes operam como componentes independentes, com fronteiras de responsabilidade definidas e ciclos de vida próprios sob contratos explícitos. Essa transição é o objeto da arquitetura agêntica enquanto disciplina, e segue padrões que a engenharia de software já conhece, em superfícies novas.
Pra mim o monolito conversacional não é anti-pattern por definição. Um agente único com dez ferramentas coesas, operando sobre um domínio bem delimitado, com contexto que cabe na janela do modelo, é a arquitetura correta pra maioria dos casos. O problema começa quando o sistema ultrapassa os limites naturais desse formato sem que a arquitetura acompanhe. Os sinais são os mesmos do monolito em software tradicional: tempo de resposta crescendo de forma não linear com a complexidade da tarefa, taxa de erro subindo a cada ferramenta nova, custo por requisição escalando com o tamanho do sistema, não da tarefa. A Gartner registrou aumento de 1.445% nas consultas sobre sistemas multi-agent entre o primeiro trimestre de 2024 e o segundo de 2025, o que indica que essa escala atingiu massa crítica em produção.
A passagem do monolito pra orquestração distribuída repete, com precisão quase incômoda, a trajetória da indústria de aplicações monolíticas pra microsserviços. A analogia não é superficial. O monolito conversacional concentra estado, roteamento, execução de ferramentas e composição de resposta num único processo, como a aplicação monolítica concentrava apresentação, regra de negócio e acesso a dados. A decomposição segue o mesmo princípio: separar por fronteira de domínio, não por conveniência técnica. Um agente de extração financeira e outro de geração de relatórios pertencem a domínios distintos, com critérios de sucesso e modos de falha em ritmos próprios. Mantê-los no mesmo processo porque compartilham o modelo é o equivalente agêntico de manter controller e repository na mesma classe porque dependem do mesmo banco.
O que diferencia a decomposição agêntica da decomposição de microsserviços é a natureza do estado compartilhado. Em microsserviços, o estado flui por APIs com contratos tipados e schemas versionados. Em sistemas de agentes, o estado inclui contexto semântico, histórico de raciocínio e metadados de confiança junto com resultados intermediários de ferramentas que não cabem num payload JSON sem perda. A fronteira precisa definir não apenas o que passa, mas em que nível de abstração passa. Um orquestrador que repassa o contexto completo a cada trabalhador paga um custo de tokens que, segundo dados da Anthropic, coloca sistemas multi-agent num consumo de aproximadamente 15x interações de chat simples. Um que repassa só o mínimo economiza tokens ao preço de exigir que cada trabalhador opere com informação incompleta. A decisão correta varia por subtarefa, e pra mim precisa ser tomada como decisão de arquitetura, com trade-offs documentados, não enterrada numa configuração implícita do prompt.
O ecossistema de protocolos que vai se consolidando em 2026 reflete essa necessidade de formalizar fronteiras. O Model Context Protocol da Anthropic, que ultrapassou 97 milhões de downloads mensais dos SDKs combinados no início de 2026, padroniza a interface entre agente e ferramenta. O Agent-to-Agent Protocol do Google cobre a interface entre agentes, da descoberta até a resposta assíncrona. Os dois operam em camadas complementares, sob a Agentic AI Foundation da Linux Foundation. A existência deles não resolve a arquitetura, mas formaliza as superfícies onde a decisão acontece.
O custo da distribuição é real e mensurável. Um estudo da UIUC (University of Illinois Urbana-Champaign) avaliando quinze datasets, sete categorias de tarefa e seis modelos encontrou que sistemas multi-agent consomem entre 4x e 220x mais tokens que seus equivalentes single-agent, com configurações otimizadas ainda exigindo entre 2x e 12x mais tokens de geração. Pra mim esses números não são argumento contra a distribuição, mas contra a distribuição prematura. A arquitetura distribuída se justifica quando o custo de manter o monolito, medido em taxa de erro e fragilidade operacional que vai se acumulando, ultrapassa o custo adicional de tokens e latência.
A heurística que se sustenta em produção é direta: começar com agente único, instrumentar as fronteiras de degradação e decompor apenas quando os sinais de esgotamento aparecem em métricas, e não em intuição. A decomposição preserva o princípio já discutido nesta série de que cada agente deve ser descritível numa frase sem conjunção. O orquestrador opera como ponto de controle de fluxo, mas não como segundo modelo raciocinando sobre o raciocínio dos trabalhadores. E o estado entre agentes é persistido num store externo, com schema e versão, até porque, sem estado intermediário materializado, recuperação de falha vira reexecução completa.
A arquitetura agêntica, pra mim, é a aplicação de princípios de software que a indústria refinou em décadas a um componente cujo comportamento interno é probabilístico em vez de determinístico. O pensamento sobre fronteira, contrato e estado permanece o mesmo. O que muda é que o componente pode falhar de formas que parecem sucesso, e a arquitetura precisa ser desenhada pra detectar essa classe de falha antes que ela se propague. Todo o resto é engenharia.