Amazon Bedrock AgentCore Harness: O que é, como funciona e principais recursos

Criar um agente de AI que funciona em uma demonstração é relativamente fácil. Criar um que consiga executar tarefas de forma confiável, usar ferramentas, gerenciar contexto e operar em um ambiente de produção é muito mais difícil. É aí que entra um agent harness.

Um agent harness fica entre o modelo e os sistemas com os quais ele precisa interagir. Ele gerencia o loop do agente, a execução de ferramentas, o contexto, a memória, o sandboxing e outras questões de runtime necessárias para transformar um LLM em um agente funcional.

O Amazon Bedrock AgentCore Harness é um serviço proprietário e gerenciado da AWS que fornece um loop de agente pré-construído e é executado dentro do AgentCore Runtime.

Neste guia, vamos detalhar como o AgentCore Harness funciona, como ele se difere do AgentCore Runtime e como ele se compara ao TrueForge em relação a suporte a modelos, gerenciamento de contexto, sandboxing, extensibilidade, implantação e controle sobre o loop do agente.

O que é o AgentCore Harness?

O AgentCore Harness é um agent harness gerenciado dentro do Amazon Bedrock AgentCore. Ele entrou em preview público em abril de 2026 e agora está disponível para o público geral. O loop de orquestração é fornecido prontamente para você, impulsionado pelo Strands Agents, permitindo que você descreva o agente em vez de desenvolvê-lo do zero.

Na prática: você declara um modelo, um prompt de sistema, um conjunto de ferramentas, configurações de memória e limites de execução como configuração. A AWS executa o loop. A maioria das alterações que normalmente exigiriam uma edição de código e uma nova implantação torna-se apenas um único campo de configuração. Alternar de um provedor de modelo para outro é questão de alterar um campo. Adicionar uma ferramenta é apenas um campo.

Cada sessão do harness é stateful por padrão e executada em uma microVM isolada. O agente obtém seu próprio sistema de arquivos e shell, de modo que pode gravar um arquivo, executar código e manter memórias e arquivos entre sessões, em vez de começar do zero a cada vez.

Duas chamadas de API são suficientes para começar a rodar. O CreateHarness define o agente e o InvokeHarness o executa. Também há uma opção via CLI do AgentCore e um caminho pelo console, caso prefira clicar em vez de usar comandos cURL.

Como funciona o AgentCore Harness?

O AgentCore Harness é construído em torno de uma abordagem focada em configuração para a execução de agentes.

Em vez de escrever um loop de agente como:

você define os componentes de que o agente precisa e deixa o harness gerenciar o loop.

Em um nível alto, um AgentCore Harness consiste em:

• Modelo - o modelo que o agente usa para raciocínio e geração
• Instruções - o comportamento no nível de sistema e as instruções para o agente
• Ferramentas - capacidades que o agente pode invocar, incluindo servidores MCP e ferramentas do AgentCore
• Memória - estado que pode ser mantido entre as interações
• Skills - capacidades e instruções adicionais que podem ser disponibilizadas para o agente
• Configurações de execução - controles sobre como o agente opera

O harness então coordena esses componentes durante a execução.

Por exemplo, se um agente precisa pesquisar um tópico, ele pode raciocinar sobre a tarefa, chamar uma ferramenta para recuperar informações, incorporar o resultado em seu contexto e continuar o loop até atingir uma resposta final.

Essa abstração significa que os desenvolvedores não precisam construir cada parte da camada de orquestração por conta própria.

No entanto, isso também significa que o modelo de execução é amplamente determinado pelo harness. Se você precisar alterar o loop subjacente ou introduzir uma lógica de orquestração personalizada, terá menos flexibilidade do que teria com um harness de código aberto no qual o próprio loop fica acessível.

Você nunca vê o loop. Esse é todo o propósito do produto, e é também a origem da maioria das suas restrições.

O que vem integrado?

O harness gerenciado cobre uma ampla gama de recursos sem a necessidade de código:

A seleção de modelos abrange Bedrock, OpenAI, Gemini e LiteLLM, sendo possível trocar de provedor no meio de uma sessão. Ferramentas integradas de shell e file_operations vêm de fábrica, assim como os Agent Skills. A memória está disponível nas formas de curto e longo prazo, cobrindo nesta última a memória semântica, de sumarização, de preferências do usuário e episódica, com escopo por usuário via ID de ator.

Os outros primitivos do AgentCore conectam-se como configuração em vez de chamadas de SDK: Gateway, Browser, Code Interpreter e ferramentas de servidor MCP remoto. As opções de sistema de arquivos incluem armazenamento de sessão gerenciado pelo serviço, um ponto de acesso EFS ou um ponto de acesso S3 Files.

Do lado da segurança, a autenticação de entrada suporta IAM SigV4 e OAuth; a autenticação de saída é realizada através do cofre de tokens de identidade para tokens OAuth e chaves de API; e as sessões são isoladas com redes VPC disponíveis. Observabilidade, respostas em streaming, versionamento e endpoints funcionam sem código personalizado.

Uma exceção importante que vale notar: ferramentas inline e do lado do cliente ainda exigem que você escreva e mantenha uma implementação, mesmo no harness.

AgentCore Harness vs AgentCore Runtime

Esta é a comparação que leva a maioria das pessoas à documentação, por isso vale a pena ser preciso. Os dois resolvem partes diferentes do mesmo problema, e o aws agentcore harness é construído sobre a outra camada.

O AgentCore Harness é uma abstração gerenciada que roda dentro do Runtime. O CloudTrail inclusive registra as operações do harness sob o serviço AWS::BedrockAgentCore::Runtime, o que mostra exatamente onde fica essa fronteira.

O AgentCore Runtime é um ambiente de hospedagem serverless. Você traz seu código de agente escrito em qualquer framework (ou nenhum), envolve-o com o ponto de entrada BedrockAgentCoreApp do SDK do AgentCore, empacota-o em um contêiner ARM64, faz o push para o Amazon ECR e realiza o deploy. O Runtime cuida do isolamento, escalabilidade, sessões, autenticação e canalização de observabilidade. O loop de orquestração é seu.

O padrão em quase todos os recursos é o mesmo. No harness, tudo é feito por configuração sem código. No Runtime, é suportado, mas você precisa manter a implementação.

O que o AgentCore Harness não pode fazer

A AWS publica essas limitações em sua própria tabela de recursos. Quatro capacidades são marcadas como não suportadas no harness:

Sem opção de escolha do framework de agente. O loop é construído em torno do Strands Agents. Se sua equipe já desenvolveu soluções sobre LangGraph, CrewAI ou outro framework, esse código não poderá ser reaproveitado diretamente.

Sem suporte a padrões fora do loop tradicional de agentes. Aplicações estruturadas como grafos ou workflows não são suportadas. Se apenas uma etapa da sua pipeline precisa de um modelo e o restante é código determinístico, o harness não possui uma forma de expressar esse fluxo de trabalho.

Sem hooks. Você não pode injetar sua própria lógica em pontos específicos do loop. Isso elimina casos de uso como uma verificação de conformidade ou uma regra de negócio que precise ser executada em um momento exato do ciclo de execução, em vez de quando o modelo decidir chamar uma ferramenta.

Sem streaming bidirecional. O harness não suporta streaming bidirecional, limitando aplicações que exigem comunicação contínua de duas vias entre o cliente e o agente.

Existe um quinto item que é menos uma limitação técnica e mais uma decisão de design, mas que afeta bastante agentes de longa duração: o tratamento de contexto utiliza truncamento.

Quando a janela de contexto fica cheia, o conteúdo mais antigo é removido. Isso mantém o agente dentro de seus limites de contexto, mas também significa que as informações iniciais podem desaparecer.

Uma abordagem alternativa é a compactação: resumir o histórico mais antigo em um registro estruturado e reter essa síntese. Em vez de simplesmente descartar as interações anteriores, o agente preserva uma versão condensada do que aconteceu, ajudando a manter a continuidade em execuções mais longas.

Para um agente de suporte rápido, o truncamento pode ser perfeitamente adequado. Para uma tarefa de pesquisa ou migração que leva várias horas, a diferença torna-se muito mais perceptível: o agente precisa trabalhar com uma quantidade menor do seu contexto inicial à medida que a execução se prolonga.

TrueForge: Uma alternativa open-source ao AgentCore Harness

O TrueForge adota uma abordagem diferente para o problema do agent harness. Em vez de fornecer um loop de orquestração fixo e gerenciado, o TrueForge é um agent harness open-source com licença MIT que você pode executar na sua própria infraestrutura.

O servidor principal é de código aberto, o que permite que os desenvolvedores inspecionem e modifiquem o loop de execução em vez de tratá-lo como uma caixa-preta. Você pode executar o TrueForge localmente, com Docker Compose ou implantá-lo usando Helm.

Isso altera consideravelmente a relação de prós e contras. Com o AgentCore Harness, a AWS gerencia o loop e a infraestrutura ao redor para você. Com o TrueForge, você obtém mais controle sobre como o agente realmente funciona.

Traga seu próprio modelo e ferramentas

O TrueForge é neutro em relação a modelos e funciona com endpoints compatíveis com a OpenAI. Você pode apontar o harness para o provedor de modelo ou endpoint que desejar sem alterar a implementação subjacente do agente.

O mesmo se aplica às ferramentas que o agente utiliza. O TrueForge suporta servidores MCP e permite que você traga sua própria sandbox, em vez de vincular o agente a um único ambiente de execução gerenciado.

Isso torna a camada de harness independente do modelo e da infraestrutura subjacentes:

Modelo → TrueForge → MCP / ferramentas / sandbox

Você pode alterar o endpoint do modelo sem reconstruir o agente para um provedor diferente.

Controle o loop do agente

Uma das maiores diferenças em relação ao AgentCore Harness é que o loop do TrueForge é open-source.

Isso significa que os desenvolvedores podem inspecionar como o harness lida com a execução e modificá-lo quando precisarem de comportamentos que não estão disponíveis como opção de configuração.

Isso é útil quando um agente requer lógica personalizada para:

• Execução de ferramentas
• Aprovações
• Gerenciamento de contexto
• Subagentes
• Sandboxing
• Políticas de execução
• Orquestração personalizada

Em vez de esperar que um harness gerenciado exponha um hook ou opção de configuração específica, a implementação subjacente está disponível para ser alterada.

Gerenciamento de contexto

O TrueForge também adota uma abordagem diferente para o gerenciamento de contexto.

Em vez de depender apenas do truncamento quando o contexto se torna grande demais, o TrueForge utiliza a compactação juntamente com técnicas como carregamento diferido de ferramentas, Code Mode e offloading de respostas.

O objetivo é reduzir a quantidade de contexto que precisa permanecer na conversa ativa, mantendo ao mesmo tempo as informações de que o agente precisa para continuar trabalhando.

Para agentes de longa duração, essa distinção é fundamental. Um agente trabalhando em uma grande base de código ou em uma tarefa de pesquisa de várias etapas pode acumular uma quantidade substancial de saídas de ferramentas e contexto intermediário. Simplesmente remover mensagens antigas pode tornar essas informações indisponíveis; a compactação fornece uma maneira de reter uma representação condensada.

Sandbox como uma ferramenta

O TrueForge também lida com a sandbox de forma diferente.

Com o AgentCore Harness, a sessão roda dentro de uma microVM isolada. O TrueForge, por outro lado, trata a sandbox como uma ferramenta que pode ser provisionada apenas quando o agente realmente precisa executar código.

Isso significa que a sandbox não precisa ser o ambiente de toda a sessão do agente. Ela se torna apenas mais uma capacidade que o agente pode invocar quando necessário.

A camada de runtime para agentes de AI em produção

Execute agentes em produção com um runtime de código aberto para seus modelos, ferramentas MCP, sandboxing, aprovações e observabilidade.

Explore o TrueForge

Ver no GitHub

Onde o TrueForge se encaixa

A distinção resume-se, fundamentalmente, ao nível de controle desejado.

O AgentCore Harness foi projetado para oferecer aos desenvolvedores um caminho gerenciado para executar agentes sem a necessidade de construir o loop de orquestração por conta própria. O TrueForge foi projetado para desenvolvedores que desejam que o próprio harness permaneça customizável e independente de um provedor de nuvem ou framework de agente específico.

Isso torna o TrueForge especialmente relevante quando você precisa controlar o loop do agente, alterar a forma como o contexto é gerenciado, escolher seu próprio endpoint de modelo ou executar o harness em sua própria infraestrutura.

O comando npx @truefoundry/trueforge coloca um agente em execução em cerca de um minuto, ou veja como o TrueForge lida com contexto em execuções longas.

FAQ

P: O que é o AgentCore Harness?

R: O AgentCore Harness é o agent harness gerenciado da AWS dentro do Amazon Bedrock AgentCore, disponível para o público geral a partir de 2026. O loop de orquestração é fornecido e impulsionado pelo Strands Agents, permitindo que você declare o agente via configuração (abrangendo modelo, prompt de sistema, ferramentas, memória e limites de execução) em vez de escrever o loop manualmente. As sessões são stateful por padrão e executadas em uma microVM isolada com seu próprio sistema de arquivos e shell.

P: Qual é a diferença entre AgentCore Harness e AgentCore Runtime?

R: O Runtime é a hospedagem serverless e o harness é um loop gerenciado que roda dentro dele. Com o Runtime, você traz seu próprio código de agente em qualquer framework, empacota-o como um contêiner ARM64, envia para o ECR e escreve a orquestração por conta própria. Com o harness, não há contêiner nem loop para escrever. A AWS registra as operações do harness sob o serviço AWS::BedrockAgentCore::Runtime, o que é o sinal mais claro de como os dois se relacionam.

P: Posso usar LangGraph ou outro framework com o agent harness fornecido pelo AgentCore?

R: Não no harness. A AWS marca a escolha de framework de agente como não suportada, pois o loop é baseado no Strands Agents. Você pode executar LangGraph, CrewAI ou código personalizado no AgentCore Runtime, já que o Runtime é agnóstico a frameworks por design, mas migrar para o harness significa deixar esse código para trás. Esta é a razão principal pela qual equipes comprometidas com frameworks específicos permanecem no Runtime.

P: Posso executar um agent harness na minha própria VPC ou on-premises?

R: Com um harness auto-hospedado, sim. O TrueForge roda a partir de um único comando npx localmente, ou via Docker Compose e Helm para implantações em equipe com Postgres, Redis, réplicas e login OIDC. A plataforma gerenciada da TrueFoundry também roda de forma auto-hospedada, on-premise, air-gapped ou híbrida, garantindo que nenhum dado saia do seu domínio. O AgentCore Harness suporta redes VPC, mas roda na infraestrutura da AWS.

P: Como posso governar modelos e servidores MCP em uma grande quantidade de agentes?

R: Por meio de uma camada de gateway, quando o gerenciamento de chaves por equipe deixa de ser escalável. O AI Gateway da TrueFoundry coloca mais de 1.000 LLMs atrás de uma única API compatível com a OpenAI, com cerca de 3 a 4 ms de latência adicional e mais de 350 RPS em uma única vCPU. Ele oferece RBAC, orçamentos, guardrails e rotação de credenciais, além de rastreamentos via OpenTelemetry para Grafana, Datadog ou Prometheus. Agentes no AgentCore, TrueForge ou qualquer outro sistema são governados da mesma forma.

Leituras relacionadas

• Agent Harness vs Agent Framework: Qual é a real diferença?: a distinção de categoria por trás deste artigo
• Melhores Agent Harnesses em 2026: Comparativo das 5 principais opções: como o mercado está estruturado
• Melhores Agent Harnesses de Código Aberto: as opções open-source, caso esteja descartando soluções gerenciadas
• Alternativas ao Claude Managed Agents: a mesma decisão aplicada ao harness gerenciado da Anthropic
• Amazon Bedrock Agents vs. O Plano de Controle: uma visão mais ampla sobre a arquitetura AWS

Conclusão

O AgentCore Harness e o TrueForge adotam abordagens fundamentalmente diferentes para a construção de agentes de AI.

O AgentCore Harness abstrai o loop do agente. Você define o modelo, instruções, ferramentas, memória e outras configurações, e a AWS gerencia a execução. Isso pode simplificar o processo de levar um agente para produção, especialmente se você já estiver desenvolvendo no ecossistema AWS e se sinta confortável com as restrições de um harness gerenciado.

O TrueForge coloca mais controle nas mãos do desenvolvedor. É de código aberto, pode ser executado na sua própria infraestrutura e expõe o loop de agente subjacente para modificação. Você pode escolher seu endpoint de modelo, servidores MCP e sandbox, utilizando o harness como uma base em vez de uma camada de orquestração fixa.

A escolha resume-se menos a qual harness possui mais recursos e mais a quanto controle você deseja ter sobre o runtime do agente.

Se você deseja que a AWS gerencie a orquestração e a infraestrutura, o AgentCore Harness oferece essa abstração. Se você deseja inspecionar, customizar e executar o harness por conta própria, o TrueForge fornece uma alternativa open-source.

Para equipes que estão avaliando a infraestrutura de agentes, a pergunta importante não é simplesmente qual agent harness devemos usar? É quais partes da stack de agentes queremos que a plataforma gerencie e quais partes queremos controlar nós mesmos?

O comando npx @truefoundry/trueforge coloca um agente em execução em cerca de um minuto, ou veja como o TrueForge lida com contexto em execuções longas.