Arquitetura de sistemas IA — Maestria2 / 9
Agente único vs. multi-agente — Escolhendo uma topologia
Multi-agente é tendência e geralmente prematura. Aqui está como decidir com honestidade — e por que a maioria dos produtos deve começar com um agente bem equipado.
"Multi-agente" parece avançado, então times adotam cedo. Geralmente é um erro. Um agente único com as ferramentas certas é mais simples, mais barato e mais fácil de debugar — comece aí e ganhe o direito de ter mais.
Quando um agente vence
Se a tarefa é principalmente sequencial e cabe em um contexto, um agente com as ferramentas certas vence um enxame. Menos peças móveis, um único trace para debugar, sem overhead de coordenação. A maioria dos produtos vive aqui por mais tempo do que pensa.
As razões reais para ir multi-agente
- Paralelismo — subtarefas genuinamente independentes (N arquivos, N fontes) rodam concorrentemente para ganhos de tempo de parede.
- Isolamento de contexto — uma subtarefa pesada e leitura-intensiva não deve poluir o contexto do agente principal.
- Especialização — um revisor ou pesquisador com prompt preciso se comporta mais consistentemente que um generalista fazendo vários papéis.
Se nenhum desses se aplica, multi-agente é apenas overhead se passando por tendência.
O custo de coordenação
Decidiu que precisa de coordenação? Próximo: os padrões de orquestração — pipelines, roteadores e enxames.
Série — Arquitetura de sistemas IA — Maestria
- Parte 01Arquitetura de Produtos de IA — Primeiros PrincípiosSistemas de IA falham diferente de software normal: são não-determinísticos, custam por chamada, e são difíceis de testar. A arquitetura precisa levar tudo isso em conta.
- Parte 02Agente único vs. multi-agente — Escolhendo uma topologia — você está aquiMulti-agente é tendência e geralmente prematura. Aqui está como decidir com honestidade — e por que a maioria dos produtos deve começar com um agente bem equipado.
- Parte 03Padrões de Orquestração — Pipelines, Roteadores, EnxamesUma vez que você tem múltiplas etapas ou agentes, como eles estão conectados determina custo, latência e confiabilidade. Quatro padrões cobrem quase tudo.
- Parte 04Context & Memory ArchitectureA janela de contexto é seu recurso mais caro e mais disputado. O que você coloca nela — e o que você lembra entre chamadas — é uma decisão arquitetônica.
- Parte 05Evaluation Pipelines as InfrastructureEm sistemas de IA, avaliação não é QA que você faz no final — é infraestrutura que você constrói primeiro. Sem ela, toda mudança é uma oração.
- Parte 06Engenharia de Custos — Orçamentos de Tokens que FuncionamUm recurso de IA que encanta em 100 usuários pode quebrar você em 100.000. Custo é uma restrição arquitetônica, projetada — não descoberta na fatura.
- Parte 07Latência e Taxa de Transferência em EscalaInferência é lenta e intermitente. Streaming, paralelismo e a fronteira assíncrona mantêm um produto de IA rápido sob carga real.
- Parte 08Confiabilidade — Tentativas, Fallbacks, GuardrailsModelos retornam saídas malformadas, provedores ficam offline e saídas desviam. Um sistema de IA confiável espera todos os três e continua funcionando mesmo assim.
- Parte 09A Arquitetura de Referência em ProduçãoTopologia, orquestração, memória, avaliação, custo, latência e confiabilidade — compostos em um único blueprint para um sistema de IA que sobrevive a usuários reais.