O modelo não é o sistema: por que IA poderosa ainda precisa de um harness

Toda nova geração de modelos convida à mesma fantasia: agora a tecnologia ficou tão capaz que o resto da engenharia virou detalhe. O demo entende a intenção, escreve código, usa ferramentas e parece concluir uma tarefa de ponta a ponta. A pergunta muda rapidamente de “isso funciona?” para “quanto podemos automatizar?”.

É nesse intervalo que projetos promissores viram sistemas frágeis.

O modelo produz possibilidades. O sistema precisa transformar uma possibilidade em resultado aceito, no ambiente correto, sob permissões explícitas, com custo conhecido, verificação e responsabilidade. Um modelo melhor pode elevar o teto. Ele não define sozinho o que deve ser feito, quais dados pode acessar, quando precisa parar nem o que conta como pronto.

Essa camada ao redor do modelo é o engineering harness.

O erro de categoria

Comparar modelos ajuda a escolher uma capacidade: raciocínio, código, visão, contexto, latência ou custo. Mas uma empresa não compra capacidade abstrata. Ela precisa que uma mudança seja entregue, uma análise seja confiável, um atendimento seja resolvido ou uma decisão seja tomada dentro de limites.

Entre a solicitação e o resultado existem perguntas que um benchmark de modelo não responde:

• quem definiu a intenção e os critérios de aceite;
• quais fontes, repositórios, ferramentas e ambientes podem ser usados;
• que ações são reversíveis e quais exigem confirmação;
• como uma execução longa recupera contexto depois de falhar;
• quem verifica comportamento, segurança e impacto;
• qual evidência liga o resultado à versão, ao controle e ao aprovador;
• como uma falha vira aprendizado, e não apenas uma nova tentativa.

Quando essas perguntas ficam implícitas, o prompt vira política, o modelo vira fronteira de segurança e uma resposta convincente vira sinônimo de entrega. São três responsabilidades que o modelo não deveria acumular.

Harness é o sistema de trabalho do agente

Na FORGE, o harness é organizado em seis planos. Eles não precisam ser seis serviços nem seis produtos; precisam ser seis responsabilidades visíveis.

1. Intenção

Transforma desejo em objetivo, escopo, restrições e definição de pronto. “Melhore o checkout” não é uma especificação. É uma abertura para que o sistema descubra o problema errado com muita velocidade.

2. Política

Define autoridade: o que pode ser lido, escrito, executado, publicado ou enviado; quais dados são proibidos; quando a tarefa deve parar; e qual decisão continua humana. Policy não é uma recomendação no prompt. É uma regra que o ambiente e as ferramentas conseguem impor.

3. Execução

Fornece ferramentas, sandbox, identidade de sessão, memória durável e mecanismo de retomada. O trabalho precisa sobreviver à queda de um processo e continuar atribuível. A pesquisa de engenharia da Anthropic sobre agentes gerenciados descreve a separação entre harness, sandbox e log de sessão; as fontes analisadas pela FORGE sustentam que histórico, política de orquestração e isolamento devem ser fronteiras explícitas, e que modelo ou canal não podem se tornar a fronteira de segurança. [HARNESS31-C2]

4. Verificação

Testa propriedades diferentes com controles diferentes. Teste unitário, contrato de API, eval de comportamento, scanner de segredo, revisão arquitetural e navegação real não são votos repetidos da mesma coisa. Cada controle precisa declarar o que observa e o que não prova.

5. Evidência

Prende o resultado à sua origem: commit, versão de contrato, relatório, hash, fonte, executor, verificador, validade e residual. “Passou” sem subject e sem artefato é apenas uma frase.

6. Feedback

Converte correção, incidente e exceção em melhoria durável. O loop só fecha quando a falha produz um teste, um guardrail, uma decisão, uma atualização de contexto ou um limite explícito.

Um exemplo simples: alterar um fluxo de autenticação

Imagine pedir a um agente: “adicione login social”. Um modelo capaz pode localizar arquivos, gerar a integração e produzir uma tela. Ainda assim, o resultado pode falhar por razões fora da geração de código:

• o provedor escolhido não atende à estrutura de identidade do produto;
• um segredo foi parar no bundle do navegador;
• o callback aceita uma origem indevida;
• não existe teste de tenant isolation;
• a experiência móvel não cobre erro e recuperação;
• a documentação afirma que a função está pronta antes do deploy;
• ninguém aprovou a mudança de superfície de ataque.

O harness muda o trabalho. A intenção exige cenários e critérios. A policy restringe segredo e permissão. A execução ocorre em branch e ambiente isolados. A verificação combina contrato, testes, segurança e fluxo real. A evidência liga tudo ao mesmo commit. A aprovação humana ocorre onde o risco se torna externo ou difícil de reverter.

O modelo continua sendo essencial. Só deixou de ser confundido com o produto inteiro.

Mais camadas não significam um sistema melhor

Existe também o erro oposto: responder a toda falha com mais agentes, mais reviewers e mais loops. Complexidade pode melhorar um resultado e, ao mesmo tempo, tornar custo, latência e diagnóstico piores.

Em um experimento de desenvolvimento de aplicações de longa duração, a Anthropic relatou melhor resultado com planner, generator e evaluator, mas com custo e duração materialmente maiores. Esse resultado pertence à tarefa, ao modelo e ao desenho testados. Ele sustenta a necessidade de evals e ablação por caso; não uma regra de que toda tarefa precisa de uma squad multiagente. [HARNESS31-C3]

Um componente deve permanecer no harness porque prova valor mensurável ou controla risco real. A cada salto de capacidade do modelo, vale perguntar:

• este passo ainda evita uma classe de falha;
• o mesmo controle pode ficar mais simples;
• o ganho compensa custo e latência;
• o verificador é realmente independente do executor;
• a remoção piora resultados em evals realistas.

O harness é arquitetura adaptativa. Não é uma coleção permanente de compensações para limitações de uma versão antiga do modelo.

Ferramenta não é autoridade

Um agente pode operar no terminal, no navegador, no Slack, em uma API ou em um portal. Esses canais são superfícies de integração. Não devem conceder, por conveniência, autoridade sobre toda a organização.

As fontes examinadas pela FORGE apontam para capacidades compartilhadas administradas e escopadas, mantendo web, chat e futuras interfaces como canais substituíveis. Elas não definem um modelo universal de autorização; deny-by-default, revogação e testes continuam necessários em cada produto. [HARNESS31-C4]

Essa distinção ajuda a trocar modelos sem reconstruir segurança. O roster pode mudar por tarefa, custo e risco. A identidade que executa, os recursos que ela acessa e os gates de publicação continuam estáveis.

O que pessoas de negócio precisam exigir

Uma decisão de IA fica mais madura quando sai de “qual é o melhor modelo?” e responde:

1. Qual outcome será aceito e por quem?
2. Qual baseline existe hoje para tempo, qualidade, custo e risco?
3. Onde a IA sugere, executa, verifica ou precisa parar?
4. Que dados e ações ficam fora do escopo?
5. Qual evidência acompanha cada entrega?
6. Como corrigimos, retiramos ou revertemos o resultado?
7. O que acontece quando o modelo, a ferramenta ou o ambiente muda?

Essas perguntas permitem comparar sistemas, não demonstrações.

O que equipes técnicas precisam tornar explícito

Para a engenharia, o mínimo útil é um contrato operacional:

• input e output com schema;
• identidade e capabilities por tarefa;
• contexto versionado e recuperável;
• sandbox e segredos fora do alcance do código não confiável;
• limites de tentativa, custo e duração;
• evals e testes ligados ao perfil de risco;
• provenance do artefato e dos verificadores;
• gate humano para ação irreversível ou externa;
• telemetria suficiente para explicar falha e consumo;
• rollback e retirada pública quando aplicável.

Isso não exige começar com uma plataforma enorme. Exige que a primeira versão não esconda as fronteiras que precisarão existir quando o experimento se tornar operação.

Um teste de sete perguntas

Antes de chamar uma solução de “agente em produção”, tente responder sem recorrer ao nome do modelo:

1. O que ele está autorizado a fazer?
2. Como sabemos que fez a coisa certa?
3. Quem pode interromper ou revogar a execução?
4. O que sobrevive se o processo cair?
5. Qual evidência liga o resultado à versão executada?
6. Quem responde quando o outcome afeta outra pessoa?
7. Como o sistema aprende sem reescrever silenciosamente o passado?

Se as respostas não existem, talvez haja uma capacidade impressionante. Ainda não há um sistema confiável.

Conclusão

Modelos melhores importam. Eles ampliam o espaço do que pode ser delegado e permitem simplificar partes do scaffolding. Mas quanto mais capazes se tornam, maior pode ser o efeito de uma permissão errada, de um objetivo ambíguo ou de uma verificação circular.

O harness não compete com o modelo. Ele converte capacidade em trabalho governável: intenção, política, execução, verificação, evidência e feedback.

O modelo gera possibilidades. O sistema é o que torna uma delas aceitável, atribuível e corrigível.

Próxima leitura: Humano accountable, IA executora, o contrato operacional que organiza autoridade e execução dentro da squad.