Da prova de conceito à produção: onde os sistemas multi-agente travam
Criar um agente de Inteligência Artificial (IA) funcional ficou relativamente simples. Com frameworks open source e serviços de nuvem, é possível ter algo rodando em poucos dias — algumas chamadas de ferramentas, um prompt bem escrito e o resultado já impressiona. O problema começa quando a equipe tenta levar esse agente para além do piloto e aplicá-lo em processos reais de negócio.
Quem já passou por isso reconhece a frustração: o agente não segue a lógica de negócio, pula etapas de validação, ignora casos de borda. Você ajusta o prompt, troca o modelo, adiciona exemplos — e os mesmos problemas voltam. Isso acontece porque agentes não executam uma sequência fixa de instruções: eles tomam decisões com base no contexto. Prompt sozinho não resolve. É preciso projetar como o agente raciocina, quando ele verifica e o que faz quando algo dá errado.
Com esse diagnóstico em mente, a equipe de Arquitetura de Soluções da AWS construiu o Deep Insight, um sistema multi-agente de nível produtivo. A AWS publicou uma série de três posts documentando o que aprendeu ao longo desse processo. Este artigo cobre a Parte 1 da série, que mapeia os cinco desafios centrais e mostra como cada camada da solução os endereça — do Strands Agents SDK e Amazon Bedrock ao Amazon Bedrock AgentCore, Application Load Balancer e AWS Fargate.
O que é o Deep Insight
O Deep Insight é um sistema multi-agente que transforma análises de dados complexas em relatórios automatizados. Dado um arquivo CSV e um prompt em linguagem natural, uma hierarquia de agentes especializados — Coordinator (Coordenador), Planner (Planejador), Supervisor, Coder (Programador), Validator (Validador), Reporter (Relator) e Tracker (Rastreador) — colabora para carregar os dados, executar análises, gerar gráficos, validar cálculos e produzir um relatório profissional no formato .docx com citações.
O vídeo de demonstração web do Deep Insight mostra o fluxo completo, desde o upload dos dados e a revisão do plano de análise até o streaming em tempo real e o download do relatório final. O projeto está disponível no GitHub com três opções de implantação:
- Versão Self-Hosted: roda localmente via Interface de Linha de Comando (CLI), com acesso total ao código de cada agente, prompt e fluxo. Configuração em cerca de 10 minutos, ideal para desenvolvimento. Uma demonstração está disponível no YouTube.
- Versão Web: interface no navegador para upload de dados, revisão de planos com Humano no Ciclo (HITL — Human-in-the-Loop) e download de relatórios, sem necessidade de escrever código.
- Versão Managed AgentCore: implantação em produção com Amazon Bedrock AgentCore, executando os agentes em uma Nuvem Privada Virtual (VPC — Virtual Private Cloud) privada, com isolamento de sessão por usuário e um interpretador de código customizado no AWS Fargate.
As três versões compartilham a mesma arquitetura multi-agente, então um agente validado em desenvolvimento pode ser implantado em produção sem alterações.
Os cinco desafios e como a arquitetura os resolve
A tabela abaixo resume os cinco desafios e as tecnologias escolhidas para cada um:
- “Como controlar o fluxo de execução entre múltiplos agentes?” → Strands Agents SDK com o padrão Graph e o padrão Agents-as-Tools.
- “Qual Modelo de Linguagem de Grande Escala (LLM — Large Language Model) cada agente deve usar?” → Amazon Bedrock com modelos Claude selecionados por papel: Haiku para roteamento, Opus para planejamento, Sonnet para execução.
- “Como operar um agente de forma confiável em produção?” → Amazon Bedrock AgentCore com runtime gerenciado, isolamento de sessão e implantação em VPC privada.
- “Como mitigar riscos de segurança ao executar código gerado por IA?” → AWS Fargate + Application Load Balancer (ALB) com contêineres sandbox efêmeros por sessão.
- “Como monitorar e gerenciar o sistema?” → Amazon DynamoDB + Amazon Simple Notification Service (Amazon SNS) + Amazon Cognito com painel administrativo e alertas de falha.
Design do sistema multi-agente
O Deep Insight organiza oito agentes em três camadas. Cada agente opera em seu próprio contexto independente, executa apenas suas tarefas especializadas e repassa somente os resultados comprimidos para o próximo.
Dois padrões do Strands Agents SDK combinados controlam esse fluxo. O primeiro é o padrão Graph, que define a ordem de execução dos agentes como um grafo direcionado: as requisições fluem do Coordinator para o Planner, depois para o Plan Reviewer e então para o Supervisor, com uma ramificação condicional que retorna ao Planner em caso de revisão. O segundo é o padrão Agents-as-Tools, que permite ao Supervisor invocar agentes especializados como ferramentas apenas quando necessário, minimizando o uso de contexto.
Camada 1 — Do Coordinator ao Plan Reviewer
Esta camada transforma uma requisição do usuário em um plano de execução aprovado. O Coordinator é o ponto de entrada: responde diretamente a saudações simples e encaminha tarefas complexas ao Planner. A decisão de usar o modelo Claude Haiku aqui é deliberada — como o Coordinator apenas classifica requisições, não faz sentido incorrer no custo de um modelo mais potente.
O Planner usa Claude Opus com Extended Thinking (Raciocínio Estendido) ativado para decompor a análise em 5 a 10 etapas concretas, organizadas em um checklist atribuído a cada agente especializado. Sem esse planejamento prévio, o agente tomaria todas as decisões em tempo de execução, e qualquer correção no meio do caminho invalidaria o trabalho anterior.
O Plan Reviewer é um nó de Humano no Ciclo (HITL): apresenta o plano ao usuário e coleta aprovação ou feedback de revisão. Se houver revisão, o fluxo retorna ao Planner. Um contador máximo de revisões (MAX_PLAN_REVISIONS) evita loops infinitos. Na versão Web, um modal no navegador exibe o plano com um countdown de 300 segundos que aprova automaticamente caso não haja resposta.
Camada 2 — O Supervisor como orquestrador
O Supervisor executa o plano do Planner em ordem, invocando os agentes da Camada 3 como ferramentas registradas via Tool Use (Uso de Ferramentas). Seu prompt de sistema define regras estritas: ordem obrigatória de execução, regra de conclusão de seção (não avança enquanto todos os itens do checklist não estiverem marcados como concluídos) e preservação de contexto ao passar variáveis entre os agentes.
Camada 3 — Agentes especializados
Cada agente da Camada 3 é uma instância independente com seu próprio prompt de sistema, modelo e conjunto de ferramentas:
- Coder: carrega dados, escreve e executa código Python de análise, gera gráficos (.png) e deixa metadados de cálculo para verificação.
- Validator: reexecuta cada cálculo dos metadados a partir dos dados originais. Correspondências dentro de 0,01 são aprovadas; divergências são sinalizadas. Os cálculos verificados vão para citations.json.
- Reporter: lê os resultados e as citações para gerar o relatório final em DOCX em duas versões — com e sem citações.
- Tracker: atualiza o checklist após cada agente usando apenas raciocínio do LLM, sem ferramentas, adicionando pouco overhead.
Configuração de modelo por agente
A seleção de modelo para cada papel é uma decisão arquitetural, não apenas de preferência. O Coordinator usa Haiku (sem cache, executa uma vez). O Planner usa Opus com Extended Thinking (planejamento profundo). O Supervisor, o Coder e o Reporter usam Sonnet com Prompt Caching (Cache de Prompt), reduzindo custos de tokens de entrada em até 90% em chamadas repetidas. O Validator e o Tracker operam com contextos diferentes a cada execução, tornando o cache ineficaz para eles.
Implantação e operações em produção
Execução segura de código gerado por IA
O agente Coder escreve e executa Python para análise de dados. Em produção, executar código gerado por LLM diretamente em um servidor é arriscado: o modelo pode deletar arquivos do sistema, esgotar recursos em um loop infinito ou acessar dados de outros usuários. O Deep Insight resolve isso com contêineres efêmeros por sessão no AWS Fargate, acessados via ALB.
O AgentCore runtime, o ALB e as tarefas do Fargate rodam dentro da mesma VPC privada. Endpoints de VPC conectam esses componentes ao Amazon Simple Storage Service (Amazon S3), ao Amazon Bedrock e ao Amazon Elastic Container Registry (Amazon ECR) sem trafegar pela internet pública. Grupos de segurança restringem quais componentes podem alcançar os contêineres do interpretador de código, e funções do AWS Identity and Access Management (IAM) limitam cada componente apenas aos recursos da AWS que ele precisa.
O fluxo de execução usa dois passos: o código gerado pelo LLM é codificado em base64, enviado via HTTP, gravado em arquivo (Passo 1) e depois executado via subprocess (Passo 2). Cookies de sessão do ALB (sticky sessions) garantem que o agente retorne ao mesmo contêiner em chamadas subsequentes. Ao final da análise, artefatos como gráficos e relatórios são enviados ao Amazon S3, e os contêineres encerram automaticamente após uma hora.
A AWS recomenda adicionar Amazon Bedrock Guardrails como controle de IA responsável em implantações de produção: filtros de conteúdo e detecção de ataques de prompt nos dados enviados pelos usuários, além de verificações de fundamentação contextual nas saídas dos agentes.
Visibilidade operacional
O Deep Insight oferece uma interface web baseada em FastAPI que se comunica com o backend via protocolo nativo do AgentCore. Os usuários monitoram o progresso via Server-Sent Events (SSE) em streaming e podem aprovar ou revisar o plano via modal (HITL). O relatório final pode ser baixado diretamente pela interface, que suporta coreano e inglês.
Para equipes que precisam de visibilidade operacional mais ampla, há um painel de operações opcional com rastreamento de tarefas no Amazon DynamoDB, alertas de falha por e-mail via Amazon SNS e um painel administrativo protegido por autenticação via JSON Web Token (JWT) com Amazon Cognito.
A arquitetura além da análise de dados
O design hierárquico do Deep Insight não se limita à geração de relatórios analíticos. Dois casos validam isso:
LG Electronics: a divisão de vendas da LG na Coreia construiu o ChatInsight sobre a mesma arquitetura multi-agente. Análises que levavam 3 dias passaram a ser concluídas em 30 minutos — uma melhoria de produtividade de 288 vezes. Profissionais de marketing sem conhecimento de SQL conseguem deixar o agente explorar dados e propor estratégias. Mais detalhes estão disponíveis no post sobre o Sistema de Extração de Insights da LG Electronics no AWS Tech Blog.
TechRecon (re:Invent 2025): apresentado na sessão SNR203 do AWS re:Invent 2025, o TechRecon aplica a arquitetura do Deep Insight à inteligência tecnológica estratégica. Dado uma empresa e setor, um agente Researcher coleta tendências, o Coder analisa, o Validator verifica e o Reporter produz documentos de posicionamento técnico. A arquitetura é praticamente idêntica à do Deep Insight — basta trocar os papéis e prompts dos agentes para resolver problemas completamente diferentes. Mais informações no repositório do TechRecon no GitHub e no vídeo da sessão no AWS re:Invent.
Conclusão
Colocar um agente em produção não é uma questão de capacidade do modelo — é uma questão de arquitetura. O Deep Insight oferece uma resposta concreta para os cinco desafios centrais: o padrão Graph do Strands Agents SDK para controle de fluxo e HITL, o padrão Agents-as-Tools para orquestração sob demanda, modelos Claude do Amazon Bedrock selecionados por papel, Amazon Bedrock AgentCore para runtime gerenciado, AWS Fargate + ALB para execução isolada de código e DynamoDB + Cognito + SNS para visibilidade operacional.
O projeto é open source. Explore o código, adapte para o seu domínio e acompanhe as próximas partes da série: a Parte 2 aborda técnicas de Context Engineering (Engenharia de Contexto) para superar os limites da janela de contexto, e a Parte 3 cobre a implantação e operação em produção com o AgentCore. O workshop está disponível em inglês e coreano.
Fonte
5 production challenges in multi-agent systems and how Deep Insight solved them (https://aws.amazon.com/blogs/machine-learning/5-production-challenges-in-multi-agent-systems-and-how-deep-insight-solved-them/)
Leave a Reply