# Amazon Bedrock AgentCore Harness: Da Ideia ao Agente de Produção

O AgentCore Harness chegou ao GA em junho de 2026 como uma abstração gerenciada que colapsa o plano de controle de agentes LLM em dois chamadas de API. Neste artigo, analiso como o harness funciona internamente, onde ele falha, e o que arquitetos de sistemas financeiros precisam entender antes de colocá-lo em produção.

- URL: https://fernando.moretes.com/blog/amazon-bedrock-agentcore-harness-da-ideia-ao-agente-de-producao-amazon-bedro

- Markdown: https://fernando.moretes.com/blog/amazon-bedrock-agentcore-harness-da-ideia-ao-agente-de-producao-amazon-bedro/article.md?lang=pt

- Published: 2026-06-24T12:00:00.000Z

- Category: IA & Agentes

- Tags: bedrock, agentcore, agentic-ai, aws, financial-grade, observability, security, llm-orchestration

- Reading time: 9 min

- Source: [Amazon Bedrock AgentCore harness is now generally available: Go from idea to production-grade agent in minutes](https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-harness-is-now-generally-available-go-from-idea-to-production-grade-agent-in-minutes/)

---

O problema que o AgentCore Harness resolve não é inteligência — é encanamento. Qualquer equipe competente consegue fazer um agente LLM funcionar em um laptop em uma tarde. O que explode o cronograma é a camada de produção: isolamento de execução, gerenciamento de sessão, roteamento de ferramentas, armazenamento de credenciais, rastreamento distribuído, e a multiplicação de tudo isso por cada novo caso de uso. Com o GA do AgentCore Harness, a AWS apostou que essa camada de orquestração pode ser gerenciada — e a aposta tem consequências arquiteturais sérias para quem projeta sistemas de IA em ambientes regulados.

## O Loop do Agente Como Denominador Comum

Simon Willison definiu um agente LLM de forma cirúrgica: *um LLM que executa ferramentas em loop para atingir um objetivo*. Essa definição sobreviveu porque ela captura a forma que todo agente de produção real assume — Kiro, Amazon Q Developer, Claude Code, Codex. O loop é o invariante. O que varia é tudo ao redor dele.

Quando analiso sistemas de agentes em ambientes financeiros — automação de reconciliação, triagem de alertas de fraude, geração de relatórios regulatórios — o loop em si raramente é o gargalo. O gargalo é a infraestrutura que sustenta o loop: onde o estado da sessão vive entre invocações, como as credenciais das ferramentas são rotacionadas sem interromper conversas ativas, como o isolamento entre tenants é garantido quando múltiplos usuários compartilham a mesma instância do agente, e como cada etapa do raciocínio do modelo é rastreada para fins de auditoria.

O AgentCore Harness endereça exatamente essa camada. Ele não substitui o modelo, não reescreve o prompt, e não toma decisões de negócio. Ele gerencia o *plano de controle* do agente: o ambiente sandboxed, a memória persistente, o roteamento de ferramentas, o armazenamento de identidade, e a observabilidade. A distinção é importante porque define os limites do que você pode e não pode delegar a ele — e entender esses limites é o que separa uma adoção bem-sucedida de um incidente de produção.

## AgentCore Harness: Ciclo de Vida de uma Invocação de Agente

Fluxo completo de uma invocação do harness — da chamada da API ao loop de ferramentas, memória, identidade e observabilidade. As arestas mostram a sequência e o tipo de interação.

### 🟧 AWS — AgentCore Control Plane

- Harness API CreateHarness / InvokeHarness (edge)
- Session Manager actorId + sessionId isolation (compute)
- MicroVM Sandbox filesystem + shell (compute)

### 🤖 AI — Model Routing

- Model Router bedrock / openAI / gemini / liteLLM (ai)
- Agent Loop tool-use → observe → act (ai)

### 🔧 Tools — Execution Layer

- AgentCore Gateway OpenAPI / Lambda / MCP (IAM+JWT) (compute)
- Browser Sandbox click / navigate / screenshot (external)
- Code Interpreter Python + Node sandboxed (compute)
- Inline Function human-in-the-loop / client-side tool (external)

### 🧠 State — Memory & Identity

- Managed Memory SEMANTIC+SUMMARIZATION 30-day TTL, KMS (storage)
- Token Vault AgentCore Identity no raw creds to model (security)

### 📊 Observability — CloudWatch

- CloudWatch Auto-traces every step (data)

### Fluxos

- caller -> harness_api: 1. InvokeHarness (HTTP)
- harness_api -> session_mgr: 2. resolve actorId/sessionId
- session_mgr -> microvm: 3. provisiona sandbox isolado
- microvm -> model_router: 4. seleciona provider/modelo
- model_router -> agent_loop: 5. inicia loop
- agent_loop -> gateway: tool-use → gateway
- agent_loop -> browser: tool-use → browser
- agent_loop -> code_interp: tool-use → código
- agent_loop -> inline_fn: tool-use → cliente (HITL)
- agent_loop -> memory: lê/escreve contexto
- gateway -> token_vault: busca credencial outbound
- agent_loop -> cw_traces: stream de eventos auto-traced
- harness_api -> caller: 6. stream de resposta em tempo real

## Como o Harness Realmente Funciona: Dois Chamadas de API e o que Elas Escondem

A interface pública é deliberadamente simples: `CreateHarness` define o agente (modelo padrão, ferramentas, instruções, configuração de memória) e `InvokeHarness` o executa. Mas o que acontece entre essas duas chamadas é substancial.

Quando `InvokeHarness` chega, o harness resolve o `actorId` e o `sessionId` para determinar o namespace de memória correto — garantindo isolamento multi-tenant por design, não por convenção. Em seguida, ele provisiona um microVM isolado com sistema de arquivos e shell próprios. Esse ambiente não é compartilhado entre sessões concorrentes do mesmo usuário, muito menos entre usuários diferentes. Isso tem implicações diretas para workloads financeiros onde a contaminação de estado entre sessões seria uma violação de conformidade.

O roteamento de modelo é resolvido em tempo de invocação. O campo `model` no `CreateHarness` define o padrão, mas qualquer chamada `InvokeHarness` pode sobrescrever o provider — incluindo uma troca mid-session de Claude Opus para GPT-5.5 sem perda de contexto. O harness serializa o estado da conversa e o reidrata no novo provider. Isso não é trivial: diferentes providers têm formatos de mensagem distintos, limites de contexto diferentes, e comportamentos de tool-use que variam. O harness absorve essa complexidade de tradução.

As credenciais de API para providers externos (OpenAI, Gemini, provedores LiteLLM) são armazenadas no Token Vault do AgentCore Identity. O modelo nunca vê credenciais brutas — o harness injeta os headers de autenticação na chamada de saída. Em um ambiente financeiro, isso é o equivalente funcional de um secrets manager integrado ao plano de execução do agente, sem exigir que o desenvolvedor construa essa integração manualmente.

> **Isolamento por Design vs. Isolamento por Convenção:** O namespace de memória keyed em `actorId` não é apenas uma feature de conveniência — é um controle de conformidade. Em sistemas financeiros, a separação de dados entre clientes é um requisito regulatório (PCI-DSS, SOC 2, LGPD). O fato de o harness enforçar isso por padrão, sem exigir que o desenvolvedor construa lógica de particionamento, remove uma classe inteira de erros de implementação que eu já vi causar incidentes em produção. A pergunta que você deve fazer ao seu time de segurança não é 'o harness isola os dados?' — é 'como auditamos que o isolamento está funcionando?'. A resposta está nos traces do CloudWatch.

## Memória Gerenciada: O Que Você Ganha e o Que Você Abdica

O comportamento padrão de memória no GA é revelador das prioridades de design: se você omitir a configuração de memória no `CreateHarness`, o harness provisiona automaticamente um recurso de memória com estratégias `SEMANTIC + SUMMARIZATION`, expiração de eventos em 30 dias, criptografia com chave gerenciada pela AWS, e isolamento multi-tenant por namespace. Isso é um conjunto de defaults razoável para a maioria dos casos de uso.

Mas em ambientes financeiros, esses defaults levantam questões específicas. Primeiro, a criptografia com chave gerenciada pela AWS (AWS-owned KMS) pode não satisfazer requisitos de BYOK (Bring Your Own Key) mandatados por políticas de segurança corporativas ou regulações setoriais. Se sua organização exige controle sobre o material de chave, você precisa provisionar o recurso de memória explicitamente com uma CMK (Customer Managed Key) e passar o ARN no `CreateHarness`. O harness suporta isso, mas o default não o faz.

Segundo, a expiração de 30 dias é um TTL operacional, não um controle de retenção de dados. Em sistemas sujeitos ao GDPR ou LGPD, o direito ao esquecimento exige que você consiga deletar dados de um usuário específico sob demanda — não apenas esperar o TTL expirar. Você precisa entender a API de gerenciamento do recurso de memória subjacente para implementar esse controle.

Terceiro, as estratégias `SEMANTIC + SUMMARIZATION` implicam que o harness está fazendo inferências sobre quais partes da conversa são relevantes para reter. Isso é poderoso para UX, mas significa que o conteúdo exato das mensagens pode não ser preservado verbatim. Para casos de uso de auditoria onde a fidelidade do histórico de conversação é um requisito, você precisa complementar a memória do harness com um log de auditoria separado — que, convenientemente, os traces automáticos do CloudWatch podem fornecer.

## Roteamento de Ferramentas e o Modelo de Autorização do Gateway

A tipologia de ferramentas do harness é uma das decisões de design mais interessantes do produto. Você tem quatro caminhos: `agentcore_gateway` (ferramentas governadas via ARN, com IAM/JWT e autorização por ferramenta), `remote_mcp` (conexão direta a um servidor MCP por URL), `agentcore_browser` (sandbox de browser gerenciado), e `inline_function` (tool-use event emitido no stream, esperando resposta do cliente — o padrão human-in-the-loop).

Para sistemas financeiros, o caminho `agentcore_gateway` é o mais relevante porque ele interpõe uma camada de governança entre o agente e as APIs downstream. O Gateway suporta targets OpenAPI, Smithy, Lambda, e MCP, com autenticação IAM ou JWT, e autorização por ferramenta individual. Isso significa que você pode dar ao agente acesso a um gateway que expõe 50 ferramentas, mas restringir via política quais ferramentas uma invocação específica pode usar — usando o parâmetro `allowed_tools` no `InvokeHarness`.

O caminho `remote_mcp` é mais simples mas menos governado: você aponta para um URL de servidor MCP e o harness conecta diretamente. Isso é adequado quando o servidor MCP já tem sua própria camada de autenticação e você não precisa da auditoria centralizada do Gateway. Em ambientes regulados, eu prefiro o Gateway exatamente porque ele cria um ponto de controle único onde você pode logar todas as chamadas de ferramenta, aplicar políticas de rate limiting, e revogar acesso sem modificar o agente.

O `inline_function` merece atenção especial: ele inverte o fluxo. Em vez do harness executar a ferramenta, ele emite um evento no stream e aguarda o cliente responder. Isso habilita aprovações humanas no loop — um requisito comum em workflows de operações financeiras onde certas ações (transferências acima de um threshold, modificações de configuração) exigem aprovação explícita antes de execução.

## Observabilidade Automática: O Que Você Obtém e o Que Ainda Precisa Construir

O harness traça automaticamente cada etapa do loop do agente para o CloudWatch — sem instrumentação manual. Cada invocação, cada chamada de ferramenta, cada transição de modelo, cada evento de memória aparece como um trace rastreável. Para equipes que estavam construindo essa instrumentação manualmente com OpenTelemetry e Datadog, isso é uma redução de trabalho significativa.

Mas 'automaticamente rastreado' não é o mesmo que 'operacionalmente observável'. O que o harness fornece é telemetria de execução — o que aconteceu, em que ordem, com que latência. O que você ainda precisa construir é a camada de interpretação: SLOs sobre latência de invocação do agente, alertas sobre taxa de falha de ferramentas, dashboards que correlacionam uso de memória com qualidade de resposta, e — crítico para ambientes financeiros — trilhas de auditoria que registram quais decisões o agente tomou e com base em qual contexto.

Um padrão que uso em sistemas financeiros é complementar os traces automáticos do harness com um log de auditoria estruturado emitido via `inline_function`. Cada vez que o agente está prestes a executar uma ação de alto impacto, ele emite um evento `inline_function` que o cliente captura, loga em um sistema de auditoria imutável (S3 com Object Lock, por exemplo), e então responde ao harness com aprovação ou rejeição. Isso cria uma cadeia de custódia auditável que os traces do CloudWatch por si só não fornecem — porque os traces capturam o que aconteceu, mas o log de auditoria captura por que foi aprovado.

A integração com o novo Bedrock Guardrails API para workflows agênticos (anunciado na mesma semana do GA do harness) é o complemento natural aqui: Guardrails pode inspecionar as saídas do modelo antes que elas se tornem chamadas de ferramenta, adicionando uma camada de controle de conteúdo que opera independentemente da lógica de autorização do Gateway.

## Anti-Padrões Críticos no Uso do AgentCore Harness

- **Confiar no TTL de 30 dias como controle de retenção de dados**: O TTL é operacional, não regulatório. Em sistemas sujeitos a LGPD/GDPR, implemente deleção explícita via API de gerenciamento do recurso de memória — não espere o TTL expirar para satisfazer um direito ao esquecimento.
- **Usar `remote_mcp` para ferramentas de alto impacto sem camada de governança**: Conectar diretamente a um servidor MCP bypassa o modelo de autorização por ferramenta do Gateway. Para ações financeiras (transferências, modificações de configuração), sempre interponha o `agentcore_gateway` para ter auditoria centralizada e controle de revogação.
- **Assumir que o default de criptografia satisfaz BYOK**: A criptografia padrão usa chaves gerenciadas pela AWS. Se sua política de segurança exige CMKs (Customer Managed Keys) — comum em instituições financeiras — você deve provisionar o recurso de memória explicitamente com sua própria CMK antes de criar o harness.
- **Tratar os traces automáticos do CloudWatch como trilha de auditoria completa**: Os traces capturam telemetria de execução, não intenção de negócio. Para auditoria regulatória, complemente com um log de auditoria estruturado que capture o contexto de decisão — use `inline_function` para interceptar ações de alto impacto antes da execução.
- **Fazer switch de modelo mid-session sem validar compatibilidade de tool-use**: Nem todos os providers suportam os mesmos esquemas de tool-use. Ao trocar de provider mid-session, valide que o novo modelo suporta as ferramentas configuradas — especialmente para ferramentas com schemas complexos ou multi-step.
- **Ignorar o parâmetro `allowed_tools` no InvokeHarness**: Criar um harness com um conjunto amplo de ferramentas e invocar sem restringir via `allowed_tools` viola o princípio do menor privilégio. Para cada tipo de invocação, defina explicitamente o conjunto mínimo de ferramentas necessárias.

## AgentCore Harness pelo Prisma do AWS Well-Architected

- **security**: O Token Vault remove credenciais brutas do plano de execução do modelo — isso é Zero Trust aplicado ao agente. Mas você precisa ir além: use `agentcore_gateway` com políticas IAM com condições de `aws:RequestedRegion` e `aws:SourceAccount` para limitar o blast radius de uma ferramenta comprometida. Para memória, provisione CMKs explicitamente e implemente rotação de chave. Adicione Bedrock Guardrails no pipeline de saída do modelo para inspecionar conteúdo antes de tool-use.
- **reliability**: O harness gerencia o retry do loop do agente internamente, mas falhas de ferramentas externas são propagadas como eventos no stream. Implemente idempotência nas suas ferramentas downstream — o agente pode tentar re-executar uma ferramenta após um timeout. Para o Gateway, configure circuit breakers no nível do target. A troca de modelo mid-session tem um ponto de falha: se o novo provider estiver indisponível, o harness deve ter um fallback configurado. Teste explicitamente o comportamento de failover de provider em seus runbooks.

> **Nota do Arquiteto: O Que Eu Faria Diferente:** Em qualquer implantação financeira do AgentCore Harness, eu não aceitaria os defaults de memória — provisionaria o recurso explicitamente com uma CMK e TTL alinhado à política de retenção de dados da organização, antes de criar o harness. A lição aprendida em anos de sistemas financeiros em nuvem é que defaults de segurança razoáveis para uso geral raramente satisfazem requisitos regulatórios setoriais — e corrigir isso depois de dados de produção já estarem no sistema é sempre mais caro do que fazer certo desde o início. Eu também instrumentaria o padrão `inline_function` para toda ação de alto impacto desde o dia zero, criando uma trilha de auditoria estruturada em S3 com Object Lock — os traces do CloudWatch são excelentes para debugging operacional, mas não substituem um log de auditoria imutável para fins regulatórios. Por fim, trataria o `allowed_tools` como um controle de segurança, não como uma otimização opcional — cada tipo de invocação teria um conjunto explicitamente definido de ferramentas permitidas, revisado e aprovado pelo time de segurança.

## Veredicto: Uma Aposta Arquitetural Sólida com Condições

O AgentCore Harness GA resolve um problema real e concreto: a multiplicação do overhead de infraestrutura de agentes com cada novo caso de uso. A abstração de dois chamadas de API é bem projetada — ela colapsa isolamento, memória, roteamento de ferramentas, identidade e observabilidade em uma interface configurável sem sacrificar a flexibilidade de substituir qualquer componente. Para equipes construindo agentes em ambientes não-regulados ou em fase de experimentação, o harness é uma escolha clara: você obtém produção-grade em minutos sem construir o plano de controle.

Para ambientes financeiros regulados, o harness é viável — mas com condições não-negociáveis. Você precisa: (1) provisionar memória explicitamente com CMK e política de deleção alinhada ao LGPD/GDPR; (2) usar `agentcore_gateway` (não `remote_mcp`) para todas as ferramentas de alto impacto; (3) implementar `inline_function` para aprovações humanas em ações críticas; (4) complementar os traces do CloudWatch com um log de auditoria imutável; e (5) tratar `allowed_tools` como um controle de segurança revisado pelo time de segurança. Com essas condições satisfeitas, o harness é uma aceleração arquitetural legítima — não um atalho que você vai lamentar em uma auditoria.

## Referências

- [Amazon Bedrock AgentCore Harness GA Announcement](https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-harness-is-now-generally-available-go-from-idea-to-production-grade-agent-in-minutes/)
- [Amazon Bedrock AgentCore — Developer Documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-agentcore.html)
- [Amazon Bedrock Guardrails — Agentic AI Workflows API](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-guardrails-api-ai/)
- [Amazon Bedrock AgentCore Optimization Capabilities](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-new-optimization-capabilities)
- [AWS Well-Architected Framework — Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/wellarchitected-machine-learning-lens.html)
- [AWS KMS — Customer Managed Keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)
- [Model Context Protocol (MCP) Specification](https://modelcontextprotocol.io/specification)
- [Simon Willison — What is an LLM Agent?](https://simonwillison.net/2025/Jun/)