Agentes gerenciados vs. harnesses de agentes locais: o que manter

Anthropic e a OpenAI estão transformando a infraestrutura de runtime de agentes em superfície de produto: sessões hospedadas, sandboxes, tracing, memória, handoffs, rubricas e fluxos de eventos agora ficam mais próximos do provedor do modelo do que da pasta de scripts privada de uma equipe.¹²

Quais são os principais aprendizados?

• Agentes gerenciados estão se tornando a camada de runtime. Sessões, sandboxes, traces, eventos e execução assíncrona pertencem cada vez mais à infraestrutura gerenciada quando o provedor atende ao padrão de segurança da equipe.¹²
• Harnesses locais ainda importam. Mantenha as partes que codificam gosto, evidência, integridade da escrita pública, fronteiras de privacidade, verificação de fontes e memória do projeto.
• A unidade de migração é o trabalho, não o comando. Um slash command, uma skill do Codex, um handoff do SDK, um servidor MCP ou um resultado gerenciado podem todos carregar o mesmo workflow se os critérios de aceitação sobreviverem.
• Não publique a maquinaria privada. Posts públicos devem explicar o padrão e os critérios de aceitação, não prompts privados, corpos exatos de hooks, detalhes de conta ou regras internas de pontuação.
• Promoção exige prova. Comece explícito, execute uma tarefa real, registre o resultado e promova apenas quando o caminho visível ao usuário melhorar.

Plataformas de agentes gerenciados devem absorver o trabalho de runtime que virou commodity: execução em sandbox, sessões com estado, fluxos de eventos, tracing, execução de arquivos e finalização assíncrona. Harnesses locais ainda importam, porém seu papel fica menor e mais afiado. Mantenha as partes que codificam gosto de produto, controles de evidência, integridade da escrita pública, fronteiras de privacidade, verificação de fontes e memória operacional específica do projeto. Mova as partes que só existiam porque ninguém mais tinha empacotado o runtime.

A migração ruim é apagar seu harness local porque um provedor lançou infraestrutura gerenciada. A segunda migração ruim é preservar todo comando, hook e prompt local porque um dia resolveram um problema real. A migração certa faz uma pergunta por componente: isto codifica meus padrões ou apenas opera a máquina?

Para a arquitetura mais ampla, leia o guia de Arquitetura de Agentes de IA. Para o padrão real de migração local por trás deste post, leia Guia de Migração de Claude Code para Codex, Padrões do AGENTS.md e Filosofia de Qualidade Jiro.

O que mudou com os agentes gerenciados?

Os Managed Agents do Claude entregam aos desenvolvedores um harness de agente pré-construído rodando em infraestrutura gerenciada. A Anthropic descreve o produto como adequado para tarefas de longa duração e trabalho assíncrono, com conceitos centrais para agents, environments, sessions e events.¹ A mesma documentação descreve um ambiente gerenciado em que o Claude pode ler arquivos, executar comandos, navegar, executar código, usar servidores MCP e persistir o histórico de eventos no servidor.¹

O artigo de engenharia da Anthropic deixa o ponto arquitetural mais claro do que a documentação de produto. A equipe de Managed Agents separou o log de sessão, o harness e o sandbox para que cada parte possa falhar ou mudar de forma independente.³ Essa separação importa porque transforma um loop frágil de agente em um único contêiner num sistema com estado de sessão recuperável, ambientes de execução substituíveis e uma fronteira de segurança mais estreita ao redor das credenciais.³

A OpenAI caminha na mesma direção pelo Agents SDK. A atualização de 15 de abril de 2026 acrescentou um harness nativo do modelo, execução de sandbox nativa, uma abstração de manifesto para workspaces e suporte a primitivas comuns como MCP, skills, AGENTS.md, execução de shell e aplicação de patches.² A documentação do SDK também expõe sessions para memória entre execuções, tracing para gerações do LLM, chamadas de ferramentas, handoffs, guardrails e eventos personalizados, além de handoffs para transferir trabalho entre agentes especialistas.⁴⁵⁶

Essa é a notícia. A pergunta de estratégia é outra: depois que as plataformas entregam o runtime do agente, o que seu harness local ainda deve fazer?

Qual é a divisão entre runtime e julgamento?

A maioria dos harnesses locais mistura dois trabalhos que nem sempre deveriam viver juntos.

O primeiro é a infraestrutura de runtime. Um runtime inicia sessões, concede ferramentas, prepara um workspace, executa comandos, armazena eventos, lida com interrupções, retoma o trabalho, transmite status e registra traces. Esse trabalho se beneficia de padronização. E também se beneficia de engenharia de segurança que a maioria das equipes individuais não deveria reconstruir sem um motivo forte.

O segundo trabalho é julgamento. O julgamento diz como é um bom trabalho, quais afirmações públicas exigem fontes primárias, quando um guia está desatualizado demais para publicar, quando um hook está barulhento demais para ser obrigatório, quando uma varredura de fontes deve virar uma nota privada em vez de um post e quando um agente deve recusar um output tecnicamente correto, mas indigno. Esse trabalho fica local porque vem do produto, da equipe e do leitor.

A infraestrutura gerenciada pode rodar um loop melhor. Ela não pode decidir qual deve ser seu gosto.

O que deve migrar para os agentes gerenciados?

Mova os componentes que não codificam seus padrões de produto.

O recurso de Outcomes da Anthropic mostra para onde essa tendência caminha. O desenvolvedor define uma rubrica, o harness gerenciado provisiona um grader separado e o agente itera contra o feedback do grader.⁷ Isso não remove os padrões locais. Isso dá a esses padrões um slot de runtime.

O mesmo padrão se aplica ao tracing da OpenAI. Por padrão, o SDK rastreia a execução, spans de agentes, gerações, chamadas de function tools, guardrails e handoffs, com controles para desabilitar tracing e processadores para outros destinos.⁵ Um script local consegue aproximar isso. Um sistema de produção geralmente deve preferir o trace padronizado e enviá-lo para onde a equipe já depura o trabalho.

O que deve permanecer local?

Mantenha os componentes que definem seus padrões, seu leitor ou seu contexto operacional privado.

Gosto de produto. Uma plataforma pode executar uma tarefa; ela não consegue saber se o resultado melhora o produto como um todo. Mantenha as regras de gosto que rejeitam outputs poluídos, genéricos ou sem dignidade.

Controles de evidência. Mantenha regras que exigem evidência da sessão atual, verificação do caminho do usuário, lacunas nomeadas e análise de causa raiz. Os traces gerenciados dizem o que aconteceu. Seu padrão decide se a evidência é suficiente.

Integridade da escrita pública. Mantenha regras de citação, regras de tier de fontes, checagens de fronteira privada, checagens de SEO/AIO e controles de publicação próximos do site. Um provedor de modelo não deve decidir quais detalhes privados de workflow podem ser publicados.

Memória do projeto. Mantenha doutrina concisa do projeto, decisões de estilo, riscos conhecidos, fronteiras de release e logs operacionais onde a equipe possa inspecioná-los. Mova apenas a camada de armazenamento quando um armazenamento de sessão gerenciado realmente melhorar a durabilidade.

Inteligência de fontes. Mantenha a camada de roteamento editorial. Um scanner pode encontrar 14 itens bons e ainda assim produzir zero posts se a jogada certa for monitorar, manter um guia ou registrar uma nota privada.

Política de promoção. Mantenha as regras de staging. Uma skill pode começar como explicit-only, um hook pode rodar em shadow e um plugin pode ficar em install-pilot até que o trabalho real prove que ajuda mais do que distrai.

Essa lista é o harness de verdade. Os arquivos e comandos são apenas uma implementação dela.

Que erro de migração as equipes devem evitar?

A maneira mais fácil de errar nessa migração é preservar o formato em vez do trabalho.

Slash commands do Claude Code, skills do Codex, ferramentas do SDK, resultados gerenciados e servidores MCP não são sintaxes intercambiáveis para a mesma coisa. São superfícies de ativação diferentes. Um slash command pode virar uma skill. Uma skill pode virar uma rubrica de resultado gerenciado. Um hook pode virar um processador de trace. Um script local pode se tornar desnecessário quando a plataforma expõe sessões ou webhooks.

O artigo da Anthropic sobre agentes de longa duração faz o mesmo ponto pelo lado oposto: a compactação sozinha não produzia trabalho com qualidade de produção, então o padrão eficaz adicionou listas de features, artefatos de progresso, estado limpo de handoff e testes ponta a ponta.⁸ Isso não são convenções de UI. São obrigações de prova.

A migração não deve perguntar “Onde coloco o /scan-intel?”. Deve perguntar “Que trabalho o workflow de inteligência de fontes realizava?”.

Para um scanner de fontes, o trabalho não é “rodar um comando”. O trabalho é varrer fontes configuradas, provar a acessibilidade das fontes, pontuar candidatos, recusar gravações amplas e de baixo sinal, preservar notas úteis de forma privada e rotear oportunidades públicas para revisão editorial. A frase exata de ativação pode mudar sem que o workflow se perca.

A mesma regra vale para a doutrina de qualidade. Não publique um pacote privado de prompts. Converta a doutrina em controles de conclusão observáveis: evidência, verificação do caminho do usuário, revisão de fronteira privada e o direito de recusar trabalhos que enfraqueçam o produto.

Como isso se aplica a um scanner de inteligência de fontes?

Um scanner de inteligência de fontes torna a divisão concreta.

O lado de runtime pode migrar. Uma plataforma gerenciada pode rodar o job agendado, armazenar a sessão, executar ferramentas de browser ou de busca de feeds, emitir eventos e preservar traces. Se uma varredura expirar, a sessão gerenciada deve saber o que rodou, quais fontes falharam e onde a próxima execução deve retomar.

O lado do julgamento deve permanecer local. O scanner ainda precisa de um mapa privado de fontes, limiares de pontuação, checagens de duplicatas, limites de volume de gravação e uma rota editorial. Uma varredura que encontra 14 candidatos não deve publicar automaticamente 14 notas nem um artigo. A ação correta pode ser uma nota privada, uma tarefa de manutenção de guia, uma fila de monitoramento ou a recusa de escrever qualquer coisa pública.

Essa distinção transforma uma automação barulhenta num workflow útil:

A mesma lógica vale para workflows de codificação, manutenção de guias, tradução e escrita pública. Mova a mecânica de execução quando uma plataforma fizer melhor. Mantenha o padrão que decide se o output merece existir.

Que checklist as equipes devem usar antes de mover um harness?

Use este checklist antes de mover qualquer componente de harness local para uma plataforma de agentes gerenciados.

O caminho de promoção deve continuar sem graça:

1. Inventarie o componente.
2. Nomeie o trabalho que ele realiza.
3. Classifique-o como runtime, julgamento, memória, publicação, inteligência de fontes ou segurança.
4. Porte a menor versão útil.
5. Rode em uma tarefa real.
6. Registre o que aconteceu.
7. Promova, revise ou remova.

Qualquer coisa mais elaborada costuma esconder incerteza.

Como as equipes devem dividir um harness real hoje?

Para um setup sério de codificação e escrita, eu faria esta divisão.

Camada do provedor ou gerenciada:

• criação de sandbox
• execução de arquivos
• sessões persistentes
• fluxos de eventos
• webhooks
• traces e spans
• recuperação de workers de longa duração
• delegação básica entre múltiplos agentes
• execução de rubricas quando o provedor suporta

Camada local ou do projeto:

• AGENTS.md ou política equivalente do projeto
• padrões de escrita pública
• regras de citação e de tier de fontes
• doutrina de qualidade do produto
• memória operacional privada
• checagens de SEO/AIO específicas do site
• roteamento de inteligência de fontes
• controles finais de publicação
• política de fronteira de release para plugins e pacotes compartilhados

A linha divisória não é “gerenciado versus self-hosted”. A linha divisória é “runtime virou commodity versus julgamento de produto”.

Onde os agentes gerenciados ainda exigem cautela?

Plataformas de agentes gerenciados não removem as partes difíceis. Elas movem essas partes.

Você ainda precisa de um modelo de segurança para ferramentas, arquivos, acesso à rede e credenciais. A arquitetura da Anthropic separa explicitamente as credenciais do sandbox em que o código gerado roda, o que é a direção certa, mas as equipes ainda precisam configurar recursos, vaults e fronteiras de acesso corretamente.³

Você ainda precisa de observabilidade. Um trace pode mostrar o grafo de chamadas; ele não pode dizer se o trabalho merecia ser entregue. Um grader pode avaliar uma rubrica; ele não pode saber se a rubrica expressa o gosto certo.

Você ainda precisa de fronteiras de conteúdo. Um artigo público de migração pode descrever o padrão, mas não deve despejar prompts privados, internos exatos de hooks, caminhos privados de arquivos, listas de fontes, detalhes de conta ou pontuação editorial proprietária.

Você ainda precisa de staging. A Anthropic observa que Managed Agents continua em beta, com todos os endpoints exigindo o cabeçalho beta managed-agents-2026-04-01 e alguns recursos exigindo acesso de preview.¹ Um runtime em beta pode ser útil sem se tornar o caminho padrão para todo workflow.

O que as equipes devem levar para casa?

Para líderes de engenharia:

• Mova o trabalho de runtime em direção a sessões, sandboxes, eventos e traces gerenciados quando a plataforma atender ao seu padrão de segurança.
• Mantenha padrões locais para evidência, qualidade de fontes, gosto de produto e fronteiras de release.
• Trate rubricas gerenciadas como slots de execução para seus padrões, não como substitutas deles.

Para construtores de agentes:

• Não porte comandos um a um. Porte os jobs-to-be-done.
• Comece em explicit-only e promova depois que uma tarefa real provar valor.
• Prefira traces, logs de sessão e artefatos públicos a arqueologia de prompts privados.

Para autores públicos:

• Transforme processo privado em critérios de aceitação públicos.
• Cite a documentação oficial do produto para descrever o comportamento atual.
• Recuse o recap quando o artigo melhor for o framework de decisão.

Qual é o resumo rápido?

Plataformas de agentes gerenciados tornam o harness local menor, não irrelevante. Mova o trabalho de runtime para sessões gerenciadas, sandboxes, traces, eventos e orquestração quando a plataforma conquistar essa confiança. Mantenha os padrões locais que definem qualidade, evidência, privacidade, integridade da escrita pública e o que merece ser entregue.

FAQ: Agentes gerenciados e harnesses locais

Os Managed Agents substituem um harness local de agente de IA?

Não. Plataformas gerenciadas substituem cada vez mais a camada de runtime: sessões, sandboxes, fluxos de eventos, tracing e execução de ferramentas. Harnesses locais continuam importando quando codificam padrões de produto, controles de evidência, regras de escrita pública, fronteiras de privacidade, inteligência de fontes e memória específica do projeto.

O que deve ficar no AGENTS.md ou no CLAUDE.md?

Mantenha ali as regras duráveis do projeto: o que o produto valoriza, como a conclusão é verificada, quais detalhes privados não podem ser publicados, como a escrita pública é checada e quais caminhos visíveis ao usuário precisam funcionar antes que uma tarefa conte como concluída. Não enfie outputs transitórios de ferramentas nem corpos de prompts privados em arquivos permanentes de instruções.

Quando uma equipe deve usar uma plataforma de agentes gerenciados?

Use infraestrutura gerenciada quando o trabalho exige execução de longa duração, contêineres seguros, sessões duráveis, fluxos de eventos, conclusão assíncrona, tracing ou orquestração gerenciada entre múltiplos agentes, e quando a segurança, o custo e os controles de dados do provedor caibam no caso de uso.¹²

O que não deve migrar para um pacote de harness público?

Não publique prompts privados, corpos exatos de hooks, caminhos sensíveis de arquivos, identificadores de conta, manuseio de tokens, listas privadas de fontes, regras proprietárias de pontuação ou qualquer coisa que permita a um estranho reconstruir seu sistema operacional interno. Publique o padrão e os critérios de aceitação.

Referências