Bedrock AgentCore mostra como orquestrar múltiplos agentes sem escrever um orquestrador

Um artigo técnico publicado na DEV Community por um autor terceiro detalha, com base em uma postagem da AWS no AWS Machine Learning Blog, a arquitetura por trás do Amazon Bedrock AgentCore aplicada a um caso real de engenharia aeroespacial: decidir se a peça B pode substituir a peça A em um sistema certificado. O processo que levava dias de cruzamento manual entre PDFs, desenhos CAD, fichas técnicas e documentos regulatórios passa a ser coordenado por agentes especializados que reúnem evidência, validam conformidade e apresentam uma recomendação, sem tirar do engenheiro a decisão final.

O que interessa a quem arquiteta sistemas não é o caso de uso em si, mas os padrões de produção que ele expõe: fluxo de estado entre agentes, pontos de aprovação humana, recuperação de falha e versionamento. São exatamente os problemas que aparecem quando um sistema multiagente sai do notebook e vai para produção.

O problema de orquestração que o AgentCore ataca

Sistemas multiagente costumam falhar quando a orquestração vira gargalo: um coordenador central que serializa cada chamada de agente cria latência e ponto único de falha. O AgentCore trata orquestração como um grafo declarativo de capacidades, não como um script procedural que chama agente por agente em fila.

No workflow de substituição de peças, cada agente tem responsabilidade estreita: o SpecificationAgent busca especificações em bases multimodais, o ComplianceAgent checa diretivas de aeronavegabilidade e boletins do fabricante, o CompatibilityAgent avalia encaixe dimensional e envelope de performance, e o RiskAgent levanta histórico de manutenção e modos de falha em campo. O orquestrador move contexto entre eles sem forçar uma fila única, e rastreia dependências (o agente de compatibilidade espera o de especificação) sem serializar a execução inteira.

Estado como objeto tipado, não texto solto

O primitivo central é o que a AWS chama de evidence bundle. Quando o SpecificationAgent recupera uma ficha técnica, ele não devolve texto cru: devolve um objeto tipado com ID do documento fonte, página de referência, parâmetros extraídos (dimensões, tolerâncias, códigos de material), score de confiança por extração e embeddings multimodais para busca cruzada.

Isso importa porque evita o anti-padrão mais comum em pipelines de agentes: acumular tudo numa janela de contexto monolítica e deixar o próximo agente reinterpretar texto ambíguo. Aqui, cada agente mantém memória de trabalho própria e publica achados num evidence store compartilhado, o que reduz o acoplamento e limita o raio de impacto de um erro de extração.

Busca multimodal: o diagrama como evidência de primeira classe

A base de conhecimento não é um vector store plano. O Amazon Bedrock Knowledge Bases, com backend em OpenSearch Serverless, indexa manuais em PDF (texto e diagramas embutidos), desenhos CAD exportados como imagem com metadados, logs de manutenção e documentos regulatórios. As Amazon Nova Multimodal Embeddings codificam texto e imagem no mesmo espaço vetorial, então uma consulta como "padrão de furos de montagem para suporte" recupera tanto a ficha escrita quanto o print do CAD.

Para quem desenha pipelines de RAG, esse é o ponto prático: tratar o desenho técnico como evidência de primeira classe, e não como um anexo que o agente ignora, evita o modo de falha clássico em que a peça retorna a ficha certa mas perde o diagrama crítico na página seguinte.

O gate de aprovação humana não é um sim/não

O Strands Agents SDK expõe uma flag human_approval_required que pausa a execução depois que todos os agentes contribuíram com evidência, mas antes de gerar a recomendação final. O gate apresenta a evidência estruturada de cada agente, intervalos de confiança para parâmetros críticos, discrepâncias destacadas (como uma incompatibilidade de especificação de material) e citações regulatórias que exigem revisão manual.

O engenheiro pode aprovar, rejeitar ou pedir mais evidência, o que faz o orquestrador rodar de novo agentes específicos com consultas refinadas. O desenho é assíncrono de propósito: o estado do workflow persiste em Amazon DynamoDB e retoma quando o humano volta, mesmo que isso leve horas. Para quem já tentou manter esse tipo de estado numa fila ou num banco próprio, é exatamente o tipo de plumbing que normalmente se reescreve do zero a cada projeto.

O que quebra, e como o sistema reage

A AWS não esconde falha: o orquestrador rastreia o status de execução de cada agente e expõe erros ao operador humano na mesma interface do gate de aprovação.

Nenhuma falha é retentada em silêncio: cada uma é logada com contexto (qual agente, qual ferramenta, qual consulta) e aparece no gate de aprovação. É uma escolha deliberada de auditabilidade sobre velocidade, coerente com um domínio onde correção importa mais que latência.

Versionamento: por que você não pode fazer hot-patch

O Bedrock versiona definições de agente nativamente. Ao atualizar a instrução ou o schema de ferramentas de um agente, o Bedrock cria uma nova versão e preserva a antiga. Workflows referenciam versões explicitamente: um fluxo em andamento continua usando a versão antiga até terminar, e só fluxos novos pegam a versão atualizada.

Isso evita que uma mudança de lógica quebre um workflow no meio da execução, mas tem custo: se você descobre um bug num agente, precisa esperar os fluxos em andamento concluírem ou abortá-los manualmente. Para quem opera em produção, é o mesmo trade-off de blue-green deployment aplicado a definições de agente, só que sem o controle fino sobre quando forçar a migração.

Definição de agente como schema declarativo

O SpecificationAgent é definido como JSON que o Bedrock interpreta diretamente:

{
 "agentName": "SpecificationAgent",
 "instruction": "Retrieve technical specifications for aerospace components from multimodal knowledge bases. Extract dimensions, materials, and performance parameters.",
 "tools": [
 {
 "name": "query_knowledge_base",
 "description": "Search technical documentation using text and image queries",
 "parameters": {
 "query_text": "string",
 "query_image": "optional base64 image",
 "filter": "optional metadata filter"
 }
 },
 {
 "name": "extract_parameters",
 "description": "Parse structured data from retrieved documents",
 "parameters": {
 "document_id": "string",
 "parameter_names": "array of strings"
 }
 }
 ],
 "knowledgeBases": [
 {
 "id": "kb-aerospace-specs",
 "retrievalConfig": {
 "vectorSearchConfiguration": {
 "numberOfResults": 10,
 "overrideSearchType": "HYBRID"
 }
 }
 }
 ]
}

O agente não implementa retry nem tratamento de erro: isso vive na plataforma. É a inversão de controle típica de serviço gerenciado, e é aí que mora o trade-off real.

O que você ganha e o que entrega em troca

Quem já construiu um orquestrador de agentes do zero sabe o custo de manter DAG dinâmico, retry policy e persistência de estado funcionando sob carga. O AgentCore resolve isso como plataforma: sem código de orquestrador para manter, persistência de estado e execução assíncrona nativas, recuperação multimodal sem pipeline de embedding customizado, e primitivos de human-in-the-loop prontos para latência de decisão assíncrona.

Em troca, você aceita lock-in no Bedrock e no modelo de preço dele, controle limitado sobre a lógica de orquestração (sem DAG dinâmico sob medida), comportamento de retry e timeout configurável mas não totalmente transparente, e embeddings multimodais que funcionam como caixa-preta, sem inspeção direta do espaço vetorial.

Quando faz sentido usar, e quando não

O AgentCore faz sentido quando a coordenação multiagente precisa rodar em infraestrutura AWS sem orquestrador próprio, o workflow exige gate de aprovação humana com latência assíncrona, a evidência é inerentemente multimodal (PDF com diagrama, CAD, imagem) e você não quer operar banco de dados próprio só para rastrear estado de workflow.

Não faz sentido quando você precisa de controle fino sobre a lógica de orquestração, os agentes rodam on-premises ou em outra nuvem (o AgentCore é AWS-only), o lock-in na superfície de API e no preço do Bedrock é inaceitável para o seu contexto, ou o workflow exige coordenação em sub-segundo: o AgentCore otimiza para correção e auditabilidade, não para velocidade. O caso aeroespacial encaixa porque correção pesa mais que rapidez e a supervisão humana é obrigatória por regulação; vale checar se o seu domínio tem as mesmas restrições antes de replicar a arquitetura.

Fonte: DEV Community — #aws