Três Decisões de Arquitetura de Harness Que Compradores Estão Tomando sem Saber

Semana passada, o harness virou SKU de fornecedor. Esta semana, virou decisão de arquitetura.

Dois posts caíram com sete dias de diferença e não concordam entre si. A SWE Quiz publicou um relato interno de como o time de Codex da OpenAI cresceu de 3 para 7 engenheiros em cinco meses e entregou cerca de 1.500 PRs e um milhão de linhas de código gerado. A Mendral publicou a decisão do lado oposto: o argumento para colocar o harness fora do sandbox, com runtime de 25ms de retomada via Blaxel, execução durável via Inngest e estado compartilhado da organização virtualizado em Postgres.

Passamos dois meses argumentando que o harness é o produto e que o vocabulário agora atravessa disciplinas. Auditoria pelo lado do comprador foi a sequência natural. O que esta semana adicionou é mais afiado: existem três decisões arquiteturais escondidas dentro de toda compra de harness, e a maior parte dos times de procurement assina às cegas.

Decisão Um: Onde Roda o Loop

O time de Codex e a Mendral não estão escolhendo fornecedores diferentes. Estão escolhendo topologias diferentes.

O post da Mendral é especialmente direto. O loop agêntico, eles argumentam, “roda no seu backend. Quando precisa executar uma ferramenta, chama o sandbox por uma API.” O sandbox é folha. O cérebro de orquestração, uso de tokens, contagem de turnos, retries, checkpointing durável, construção de prompt, escrita em memória, fica no servidor que você opera. O stack é concreto: Blaxel para sandboxes que retomam do standby em 25ms (“baixo o suficiente para que o agente não consiga perceber que o sandbox sumiu”), Inngest para execução durável com checkpoint a cada turno, Postgres para estado compartilhado virtualizado dentro do sandbox em /skills/* e /memory/*.

Compare isso com um produto de agente gerenciado em que loop, sandbox, sistema de arquivos e log de eventos vivem todos dentro do fornecedor. Mesma superfície. Limite diferente. No desenho da Mendral, o seu backend é o sistema de registro. No desenho gerenciado, o fornecedor é.

Nenhum dos dois está errado. Eles otimizam para falhas diferentes. A topologia da Mendral degrada graciosamente quando um sandbox cai, o loop sobrevive, o próximo turno retoma do checkpoint. A topologia gerenciada degrada graciosamente quando você cai, o fornecedor mantém o agente rodando enquanto o time de plataforma dorme.

A pergunta que compradores não percebem que estão respondendo é: qual queda você confia ao outro lado para absorver?

Decisão Dois: Como o AGENTS.md Escala

A peça da OpenAI revela algo operacionalmente interessante que não tem nada a ver com hospedagem. É um padrão de documentação.

O AGENTS.md do time de Codex não é o paredão de instruções que a maioria dos times escreve. É um sumário apontando para quatro diretórios: docs/design-docs/, docs/product-specs/, docs/exec-plans/ e docs/references/. O agente lê o índice e busca apenas o documento relevante. Disclosure progressivo substitui o blob de instruções.

Por que isso importa no nível de arquitetura: todo harness implica uma estratégia de contexto, e a estratégia de contexto se compõe na escala do time. Um time de 3 pessoas consegue curar à mão um system prompt de 5 mil tokens. Um time de 7 pessoas entregando 1.500 PRs não consegue. Ou você constrói uma estratégia de contexto que escala com o repositório, ou o repositório silenciosamente cresce além da memória de trabalho do agente e a qualidade cai sem ninguém perceber.

O time de Codex também roda isolamento por worktree: o agente sobe uma instância isolada do produto por branch e valida visualmente via Chrome DevTools Protocol. Engenheiros prompetam “garanta que a inicialização do serviço completa em menos de 800ms” e o Codex valida direto. Isso não é capacidade do modelo. É capacidade do harness, especificamente, capacidade de sandbox e tooling, e vive inteiramente dentro da infraestrutura do próprio time.

A decisão arquitetural que compradores tomam aqui é se o harness comprado expõe as costuras para plugar convenções próprias. AGENTS.md como sumário só funciona se o harness deixar você controlar working directory, regras de resolução de arquivo e camada de ferramentas. Alguns harnesses gerenciados deixam. Outros não. Procurement raramente pergunta.

Decisão Três: De Quem É o Estado Que o Agente Lê

Esta é a decisão que se esconde à vista e que vai machucar mais times.

Um agente single-user lê o próprio sistema de arquivos e a própria memória. Um agente multi-user dentro de uma organização real lê estado compartilhado, as skills do time, a memória da organização, os artefatos que outro agente escreveu há trinta minutos. A arquitetura da Mendral resolve isso explicitamente: /skills/* e /memory/* são paths virtualizados sobre Postgres, escopados por usuário, por time ou por org, de forma que quando um agente escreve uma skill, todo outro agente no escopo certo lê no próximo turno.

Isso é uma decisão de banco de dados vestida de decisão de sistema de arquivos. Implica row-level security, semântica de escopo, resolução de conflito quando dois agentes escrevem no mesmo path e políticas de retenção de memória. Nada disso aparece na página de overview de um fornecedor de harness, porque nada disso vende.

O time de Codex bate na mesma parede por outro ângulo. Quando o time cresceu, “Friday AI slop cleanup” virou evento recorrente, drift acumulava mais rápido do que humanos conseguiam revisar. A correção foi estrutural: um background agent que varre o acúmulo e propõe PRs de limpeza. Isso só funciona quando o agente consegue ler estado compartilhado do repositório, incluindo o trabalho que outros agentes escreveram durante a semana. É o mesmo problema de estado compartilhado em outra fantasia.

Para compradores, a decisão arquitetural é: este harness modela estado compartilhado multi-user como primitiva de primeira classe ou como algo que vamos remendar depois? A resposta honesta para a maior parte dos produtos gerenciados hoje é “depois”. A resposta honesta para IA em produção dentro de uma organização real é “precisávamos disso no dia um”.

Por Que a Decisão Se Compõe

Cada uma dessas três decisões é recuperável isoladamente. Juntas, não são.

Um harness que coloca o loop na nuvem do fornecedor, embarca AGENTS.md como blob de instruções e trata estado como single-user não são três escolhas pequenas. É uma arquitetura que resiste a todo refactor que você vai querer em dezoito meses. Migrar o limite do loop significa reescrever orquestração. Migrar a estratégia de contexto significa reescrever todo system prompt. Migrar estado compartilhado significa reescrever como agentes leem e escrevem no mundo.

Esta é a camada de procurement da virada da semana passada do harness-as-SKU. Fornecedores tornaram o harness fácil de comprar. Não tornaram a arquitetura óbvia de avaliar. Os dois SKUs numa folha comparativa podem estar em lados opostos das três decisões, e a matriz não vai mostrar.

O que vai mostrar, seis meses depois, é fricção. O time que constrói workflows reais bate no teto de estado compartilhado. O grupo de plataforma bate no teto do limite de loop quando um incidente exige inspecionar estado que o fornecedor controla. Os arquitetos batem no teto do AGENTS.md quando o repositório cresce além da janela de prompt. Nenhum desses é falha do fornecedor. Todos são descasamentos de arquitetura que estavam dentro do contrato no dia um.

Este é o mesmo argumento de contexto passivo para agentes de IA: o sistema que cerca o modelo determina o resultado muito mais do que o modelo. O time de Codex e a Mendral acreditam nisso. Escolheram topologias opostas porque resolvem problemas opostos. Compradores não podem pular a escolha.

A Checklist de Procurement

Antes de assinar o próximo contrato de harness, exija respostas escritas para três perguntas:

Topologia do loop. Onde o loop do agente executa fisicamente, e onde mora o sistema de registro do estado turno-a-turno? Se a resposta for “o fornecedor” para os dois, seu runbook de incidente é um ticket de suporte. Se for “nós” para os dois, o time de plataforma dono de execução durável precisa dizer “Inngest” ou “Temporal” sem hesitar.
Estratégia de contexto na escala do time. O harness consegue carregar contexto progressivamente a partir de uma estrutura de diretórios sob seu controle, ou espera um único blob de instruções? Três engenheiros convivem com a segunda opção. Sete não, e a lacuna é invisível até a qualidade cair.
Semântica de estado compartilhado. Skills e memória são escopadas por usuário, por time ou por organização, e esse escopo é imposto pela plataforma ou pelo código da sua aplicação? Se a plataforma responder “só por usuário”, todo workflow multi-user que você construir é uma revisão de segurança esperando para falhar.

Três perguntas. Cada uma decide uma arquitetura. Cada arquitetura se compõe. O mercado de harness se move rápido o bastante para que fornecedores não vão expor essas decisões por conta própria, a página é otimizada para ativação, não procurement, e isso é racional da parte deles.

Cabe ao comprador perguntar. Semana passada, harness era SKU de fornecedor. Esta semana, é decisão de arquitetura. Semana que vem, será refactor que alguém vai pagar.

Fontes

SWE Quiz. “Harness Engineering: How OpenAI Ships Without Writing Code.” Maio de 2026.
Mendral. “The Agent Harness Belongs Outside the Sandbox.” Abril de 2026.

A Victorino ajuda times de compras a auditar decisões de arquitetura de harness antes que se tornem lock-in: contato@victorino.com.br | www.victorino.com.br