Automatize Aplicações Web Legadas com o Amazon Bedrock AgentCore Browser Tool

O problema que o RPA tradicional não resolve

Grandes empresas de setores como saúde, manufatura, varejo e serviços financeiros compartilham um desafio comum: sistemas legados críticos que só expõem interfaces HTML geradas por middleware server-side, sem Interfaces de Programação de Aplicações (APIs) modernas. Automatizar esses sistemas com Automação Robótica de Processos (RPA) tradicional funciona até certo ponto, mas escalar com confiabilidade é outra história.

O cenário típico envolve operadores navegando manualmente por fluxos de múltiplas telas, inserindo dados, validando regras de negócio e submetendo alterações — tudo isso repetido milhares de vezes por ano. Uma seguradora, por exemplo, pode processar dezenas de milhares de modificações em apólices anualmente, com equipes dedicadas a navegar interfaces complexas geradas por sistemas criados há décadas. Os custos com erros manuais e horas consumidas são significativos.

Os bots de RPA baseados em regras quebram quando a interface renderiza de forma diferente do esperado, quando há autenticação multifator (MFA) ou Single Sign-On (SSO) proprietário, ou quando surgem exceções que exigem raciocínio contextual. É exatamente essa lacuna que o Amazon Bedrock AgentCore Browser Tool se propõe a preencher.

O que é o AgentCore Browser Tool

O Amazon Bedrock AgentCore runtime oferece um serviço de navegador totalmente gerenciado na nuvem. Cada sessão de automação roda em um ambiente isolado com CPU, memória e sistema de arquivos próprios. Quando a sessão termina, o ambiente é encerrado e o estado é sanitizado.

A conexão com o navegador acontece via Playwright sobre o Protocolo Chrome DevTools (CDP) baseado em WebSocket (WSS), o que permite ao agente de IA controlar programaticamente qualquer aplicação web — incluindo interfaces JavaScript pesadas, formulários dinâmicos e fluxos de múltiplas etapas — independentemente da tecnologia por trás do sistema legado. O serviço roda uma instância gerenciada do Chromium na nuvem, exigindo apenas que a aplicação alvo esteja acessível via HTTP ou HTTPS.

Três capacidades do Browser Tool merecem destaque especial por atacar diretamente os problemas clássicos de automação legada:

• Perfis de navegador persistentes: o estado de autenticação é mantido entre sessões. O operador faz login uma vez — inclusive via live-view para fluxos com MFA — e as sessões seguintes já retomam autenticadas, eliminando a necessidade de repetir fluxos de SSO.
• Configuração de proxy: o tráfego pode ser roteado por infraestrutura de proxy corporativa com roteamento por domínio e credenciais armazenadas no AWS Secrets Manager, tornando sistemas internos acessíveis mesmo em redes restritas.
• Gravação de sessão: cliques, entradas em formulários e navegação são capturados e armazenados no Amazon S3, formando uma trilha de auditoria completa e reproduzível. Combinado com o AWS CloudTrail, isso atende aos requisitos de conformidade de setores regulados como financeiro e saúde.

Orquestração com Strands Agents e modelos de fundação

O componente de inteligência da solução vem da combinação entre o Amazon Bedrock e o Strands Agents. Em vez de seguir um script fixo, o agente opera em um ciclo ReAct (Raciocínio + Ação): captura um screenshot, analisa visualmente o estado da página usando um modelo de fundação com capacidade de visão, decide qual ação executar, executa via Playwright, observa o resultado e repete.

Essa abordagem é o que diferencia a solução do RPA tradicional. O modelo vê a página, raciocina sobre o que está na tela e determina o próximo passo — seja um clique, preenchimento de campo, scroll ou pausa para confirmação humana. Se um diálogo inesperado aparecer ou um campo validar de forma diferente do previsto, o modelo raciocina sobre o novo estado em vez de falhar.

Na prática, uma instrução em linguagem natural como “abra a apólice #12345, atualize o valor de cobertura para R$ 500.000 e submeta para aprovação” é suficiente para disparar um fluxo completo de automação. O modelo navega visualmente até a apólice correta, identifica os campos pelo screenshot, preenche as alterações em múltiplas telas, lida com prompts de validação inesperados e submete para aprovação — sem que nenhum humano precise mapear cada seletor CSS ou manter scripts frágeis.

Arquitetura da implementação de referência

A AWS publicou uma implementação de referência completa de um trabalhador digital baseado em IA, construída com AgentCore Browser Tool e Strands Agents. O código-fonte completo está disponível no GitHub.

A arquitetura é composta por um conjunto enxuto de componentes com responsabilidades bem delimitadas:

• Uma interface de chat React como Single Page Application (SPA) para o operador
• Um proxy com terminação TLS que resolve uma limitação específica do navegador
• Um worker Python executando Strands Agents no Amazon Bedrock AgentCore runtime
• O ambiente de navegador gerenciado pelo AgentCore Browser Tool

O fluxo completo funciona assim: a interface é carregada via Amazon CloudFront a partir de um bucket privado no S3. O operador se autentica pelo Amazon Cognito via OpenID Connect (OIDC), que emite um JSON Web Token (JWT). O navegador abre uma conexão WebSocket através de um Application Load Balancer (ALB) que termina o TLS. O ALB encaminha para um proxy NGINX rodando como tarefa do AWS Fargate em sub-rede privada. O proxy injeta o JWT no cabeçalho de autorização e encaminha ao AgentCore runtime, que valida o token e roteia para o container do agente. O agente chama o modelo de fundação no Amazon Bedrock para analisar screenshots e decidir as próximas ações, enquanto controla o navegador Chrome isolado via CDP. Transcrições e screenshots de sessão são armazenados no S3 com URLs pré-assinadas transmitidas ao chat do operador — os bytes da imagem não trafegam pelo WebSocket, apenas a URL de curta duração.

A infraestrutura de suporte inclui o Amazon ECR para hospedar as imagens de container e o Amazon CloudWatch para logging de auditoria e observabilidade.

Integração humana no loop

O operador acompanha a automação em tempo real. O agente transmite rastros de raciocínio e screenshots para a interface de chat à medida que avança. Quando o modelo determina que precisa de confirmação humana antes de uma ação crítica — como submeter uma modificação de apólice ou confirmar uma alteração de beneficiário — ele chama a ferramenta handoff_to_user, que pausa a automação e apresenta ao operador uma pergunta junto com o screenshot atual.

A sessão do navegador permanece ativa enquanto o agente aguarda resposta (até 300 segundos por padrão). O operador pode aprovar, rejeitar, fornecer instruções adicionais ou pedir ao agente que tente uma abordagem diferente. Após a resposta, o modelo retoma o ciclo ReAct com o input recebido. Se o operador não responder dentro do tempo limite, o modelo decide se tenta novamente, tenta uma abordagem alternativa ou aborta de forma controlada.

Decisões de design que afetam a confiabilidade em produção

A implementação de referência destaca duas escolhas técnicas relevantes para quem pretende levar a solução para produção:

Isolamento de event loop: o agente de navegador roda junto com um servidor WebSocket que transmite atualizações ao operador. O modelo de threading da ferramenta de navegador interfere no event loop do servidor, causando quedas de conexão após cerca de 15 segundos. A implementação de referência sobrescreve esse comportamento para que as operações do navegador rodem em seu próprio loop isolado, mantendo a conexão do operador estável durante toda a sessão.

Localizadores semânticos em vez de seletores CSS: bots de RPA tradicionais quebram quando elementos de UI mudam de posição ou são renomeados. A ferramenta semantic_action adota uma abordagem diferente: o modelo descreve o que vê (“clique no botão rotulado Enviar”) e a ferramenta mapeia isso para a API de Locator semântico do Playwright usando correspondência fuzzy sem distinção de maiúsculas/minúsculas. Isso torna a automação resiliente às variações de UI comuns em aplicações legadas.

Como implantar e testar

A solução completa é implantada com um único stack Terraform. Os pré-requisitos são: uma conta AWS com acesso a modelos de fundação com capacidade de visão no Amazon Bedrock, AWS Command Line Interface (AWS CLI) v2 configurado, Docker 24+, Terraform 1.5+, Node 20+ com Yarn e Python 3.12.

Os comandos de implantação são:

git clone <repo-url> && cd <repo>
cp deployment/terraform/stacks/all/terraform.tfvars.sample \
   deployment/terraform/stacks/all/terraform.tfvars
# Edite terraform.tfvars - defina aws_region, project_name, cognito_domain_prefix
terraform -chdir=deployment/terraform/stacks/all init
terraform -chdir=deployment/terraform/stacks/all apply

O stack provisiona o Cognito User Pool, distribuição CloudFront, repositórios ECR, serviço de proxy ECS, AgentCore runtime com autorizador JWT e armazenamento de sessão no S3. Os provisioners do Terraform constroem e publicam as imagens de container, compilam a interface React, sincronizam com o S3 e invalidam o CloudFront — tudo em uma única execução. O primeiro apply leva aproximadamente 20 a 30 minutos, a maior parte em propagação do CloudFront e builds de imagem.

Após a implantação, o Terraform exibe a URL do CloudFront. Para testar, basta abrir no navegador, fazer login com um usuário Cognito e enviar um prompt como:

"Open https://httpbin.org/forms/post, fill the customer name with John Smith, pick medium pizza, check bacon topping, and submit the form."

O rastro de raciocínio deve aparecer no chat, screenshots surgem a cada etapa e um prompt de confirmação humana aparece antes do envio final. Cenários adicionais de teste estão disponíveis no README do repositório.

Para encerrar a infraestrutura e evitar cobranças contínuas:

terraform -chdir=deployment/terraform/stacks/all destroy

Próximos passos e extensões possíveis

A implementação de referência foi projetada com espaço para crescer. Se o fluxo precisar de contexto entre sessões, o Amazon Bedrock AgentCore memory oferece memória gerenciada de curto e longo prazo. Para integrar APIs REST existentes como ferramentas que o agente possa chamar junto com as ações de navegador, o Amazon Bedrock AgentCore Gateway resolve isso sem a necessidade de criar Strands tools customizadas. Para portais que exigem comportamento de navegador personalizado, extensões do Chrome podem ser carregadas nas sessões do AgentCore Browser Tool no momento da criação.

O código-fonte completo da implementação está disponível no GitHub.

Fonte

Automate legacy web applications with Amazon Bedrock AgentCore Browser Tool (https://aws.amazon.com/blogs/machine-learning/automate-legacy-web-applications-with-amazon-bedrock-agentcore-browser-tool/)