Web Search no Bedrock AgentCore: Revisão Técnica Aprofundada

O Web Search não é um endpoint REST avulso colado ao Bedrock. Ele é um connector target dentro do Bedrock AgentCore Gateway, exposto via Model Context Protocol (MCP). Isso importa arquiteturalmente: o MCP define um contrato padronizado de tool-calling entre o modelo e ferramentas externas, permitindo que o agente descubra, invoque e interprete resultados de busca como parte do seu ciclo de raciocínio — sem que o desenvolvedor precise escrever parsers ou gerenciar o schema de resposta manualmente.

Na prática, o fluxo é: o agente envia uma query em linguagem natural → o Gateway roteia para o connector de Web Search → o serviço consulta o índice web da Amazon combinado com o Amazon Knowledge Graph (dados estruturados verificados) → retorna snippets, URLs, títulos e datas de publicação → o modelo raciocina sobre esses fragmentos para produzir uma resposta grounded com citações.

A escolha do MCP como protocolo de integração é uma aposta clara da AWS na padronização do ecossistema agentic. Isso significa que o mesmo Gateway pode agregar múltiplos targets MCP — busca web, bases de conhecimento internas, APIs corporativas — e o agente os trata de forma uniforme. Para arquitetos que já trabalham com Strands Agents ou frameworks compatíveis com MCP, a adoção é praticamente zero-friction no lado do código. O ponto de atenção é que o Gateway em si introduz um hop adicional de latência e um ponto de controle centralizado que precisa ser dimensionado e monitorado.

Em ambientes financeiros regulados — bancos, corretoras, fintechs sob BACEN, CVM, SEC ou FCA — o maior bloqueador para adoção de busca web em agentes não era tecnológico: era de governança. Enviar prompts contendo dados de clientes ou estratégias proprietárias para APIs de busca de terceiros (Google, Bing, Brave) cria um vetor de vazamento de dados que a maioria dos times de segurança simplesmente não aceita. O Web Search no AgentCore elimina esse vetor ao manter tudo dentro do perímetro AWS do cliente.

Isso tem implicações concretas: não há necessidade de Data Processing Agreements (DPAs) adicionais com provedores de busca externos; o tráfego pode ser mantido dentro de uma VPC via PrivateLink (verificar disponibilidade por região); os logs de queries ficam no CloudWatch Logs do próprio cliente, auditáveis via CloudTrail; e as políticas IAM do AgentCore Gateway podem ser escopadas por role, permitindo que apenas agentes autorizados invoquem a ferramenta de busca.

O caso de uso que mais me convence é o de agentes de compliance e monitoramento regulatório: um agente que precisa verificar se uma nova circular do BACEN ou uma atualização da SEC afeta uma posição ou produto específico, consultando fontes públicas em tempo real, sem que a query revele a posição do cliente para nenhum terceiro. Combinado com o Amazon Knowledge Graph — que traz dados estruturados verificados sobre entidades, fatos e relações — o grounding vai além de snippets de texto puro, o que reduz alucinações em domínios com ontologias bem definidas como regulação financeira e taxonomias de produtos.

Nenhuma capacidade de GA chega perfeita, e o Web Search no AgentCore não é exceção. O primeiro limite que impacta projetos enterprise imediatamente é a disponibilidade em uma única região (us-east-1). Para workloads financeiros com requisitos de DR multi-region ou com restrições de residência de dados fora dos EUA (LGPD, GDPR, regulação europeia), isso não é um detalhe — é um bloqueador de adoção até que regiões adicionais sejam habilitadas. A AWS promete expansão no roadmap, mas sem SLA de data.

O segundo ponto crítico é a ausência de controle sobre o índice consultado. Diferente de uma Knowledge Base gerenciada onde você define o corpus, o Web Search consulta o índice público da Amazon. Isso significa que não há como excluir domínios específicos, priorizar fontes confiáveis (ex: apenas reguladores, bancos centrais, publicações peer-reviewed) ou filtrar por jurisdição geográfica do conteúdo. Para agentes que precisam de grounding em fontes curadas — um requisito comum em compliance financeiro — isso é uma limitação funcional relevante.

O terceiro ponto é observabilidade e custo previsível. A $7/1k queries, um agente conversacional com 10k usuários ativos fazendo 5 buscas por sessão gera $350/dia — $10.500/mês — apenas em Web Search, antes de computar o custo do modelo. Sem mecanismos nativos de rate limiting por agente ou por usuário no Gateway, um loop de raciocínio mal configurado pode gerar centenas de queries em segundos. É imprescindível implementar quotas via API Gateway ou lógica de retry com backoff exponencial e limite de iterações no próprio agente. CloudWatch Metrics para WebSearchQueryCount deve ter alarme configurado desde o dia zero.

O padrão arquitetural que recomendo para ambientes financeiros não usa o Web Search de forma isolada. A composição correta é: Knowledge Base interna (documentos regulatórios, políticas, dados proprietários) + Web Search (eventos recentes, publicações públicas) + Guardrails do Bedrock (filtragem de conteúdo e PII), todos expostos como targets MCP no mesmo AgentCore Gateway.

O agente decide qual ferramenta invocar com base no tipo de query: para fatos históricos e políticas internas, usa a Knowledge Base; para eventos recentes ou validação de informações públicas, usa o Web Search. Essa decisão pode ser guiada por um router de intenção implementado como uma chain de prompt antes da chamada de tool, reduzindo queries desnecessárias ao Web Search e, consequentemente, o custo.

No plano de observabilidade, instrumentalize o Gateway com OpenTelemetry: trace cada invocação de tool com agent.tool.name, agent.tool.latency_ms, agent.search.query_hash (nunca o texto raw por PII) e agent.search.result_count. Correlacione com os traces do modelo via trace_id para ter visibilidade end-to-end do ciclo de raciocínio. No Datadog ou CloudWatch, crie um SLO de latência P95 para o ciclo completo de grounding (target: <3s para queries síncronas em interfaces conversacionais).

Para IAM, o princípio de menor privilégio se aplica com granularidade: a role do agente deve ter bedrock:InvokeAgent e a permissão específica para invocar o Gateway, mas não deve ter acesso direto às credenciais do índice ou a outros targets não autorizados. Use resource-based policies no Gateway para restringir quais roles podem invocar quais targets MCP.

O Web Search no AgentCore não é um produto isolado — é uma peça de um movimento estratégico maior. Olhando o conjunto de anúncios do AWS Summit New York 2026: Managed Knowledge Base, AgentCore Gateway, Web Search, AWS DevOps Agent, AWS Transform — a AWS está construindo uma plataforma de orquestração agentic enterprise, onde o MCP é o barramento de integração e o AgentCore é o plano de controle.

Isso tem implicações para decisões de build vs. buy. Hoje, muitas equipes constroem sua própria camada de tool-calling com LangChain, LlamaIndex ou frameworks proprietários, integrando manualmente APIs de busca, bases vetoriais e ferramentas de ação. O AgentCore + Web Search representa a proposta da AWS de que essa camada deve ser gerenciada, assim como a AWS gerencia filas (SQS), streams (Kinesis/MSK) e orquestração (Step Functions). A aposta é que o custo de operação e governança de ferramentas agentic customizadas supera o custo de adoção da plataforma gerenciada.

Para arquitetos de sistemas financeiros, a questão não é se o Web Search é tecnicamente superior a uma integração Bing/Google customizada — em muitos aspectos, ainda não é, especialmente em controle de corpus e cobertura regional. A questão é se a redução de risco de compliance + redução de overhead operacional justifica o preço e as limitações atuais. Para a maioria dos casos de uso que avaliei — monitoramento regulatório, enriquecimento de relatórios, assistentes de research — a resposta é sim, com as mitigações adequadas.