Existe uma cena que se repete em empresa que tentou colocar IA para trabalhar: o agente erra, alguém sugere trocar de modelo, trocam, e o agente continua errando. Aí trocam de novo. Aí concluem que "IA ainda não está pronta".
Na maioria desses casos o modelo nunca foi o problema. O problema estava numa camada que ninguém no projeto sabia nomear.
Agente = Modelo + Harness
O vocabulário se consolidou ao longo de 2026 numa fórmula curta: agente é modelo mais harness.
O modelo é a parte que raciocina. Ele recebe texto, produz texto e decide o que deveria acontecer em seguida. Só isso. Ele não executa nada, não lembra de nada e não sabe o que aconteceu na sessão passada — um modelo de linguagem é stateless por natureza. Toda sessão nova começa cega.
O harness é todo o resto: a infraestrutura de software que envolve o modelo e transforma "sugerir uma ação" em "executar uma ação". Ele gerencia execução de ferramentas, memória, persistência de estado, ambiente de execução e ciclos de verificação. Tudo, menos o raciocínio.
A implicação prática é dura: o mesmo modelo se comporta de formas radicalmente diferentes dependendo do harness em que está rodando. Você pode trocar o motor e manter o carro ruim.
O que exatamente o harness faz
Os componentes que aparecem em praticamente toda implementação séria:
* O loop. Chamar o modelo, ler a saída, executar a ferramenta pedida, devolver o resultado, chamar o modelo de novo. Repetir até terminar. Sem loop, você tem um chat; com loop, você tem um agente.
* Ferramentas. As mãos do sistema: leitura de arquivo, busca na web, chamada de API, consulta a banco, execução de código. A qualidade da descrição de cada ferramenta determina se o modelo escolhe a certa.
* Gerência de contexto. A janela de contexto é finita e a conversa cresce. Alguém precisa decidir o que resumir, o que descartar e o que manter. Essa decisão é uma das mais determinantes para a qualidade do resultado.
* Camada de permissão. O que roda sozinho, o que exige confirmação humana, o que é proibido. Regras declarativas de permitir/negar, mais um modo em que o agente para e pergunta antes de uma ação perigosa.
* Persistência de estado. Sessão que continua, memória entre execuções, retomada depois de falha.
* Observabilidade. Rastro do que foi feito, com qual entrada e qual resultado. Sem isso, você não depura nada.
Repare que nenhum desses itens é "inteligência". São decisões de engenharia. E são elas que definem se o sistema é confiável.
Harness interno e harness externo
Uma distinção útil vem de Birgitta Böckeler, da Thoughtworks: existe o harness interno, que vem pronto do fabricante — o SDK do agente, ou uma ferramenta como Cursor e Codex — e o harness externo, que você monta por cima: arquivos de instrução, servidores MCP, skills customizadas.
Isso importa porque delimita o que é seu problema. Se o agente escolhe mal a ferramenta, pode ser o harness interno. Se ele não sabe as regras do seu negócio, é o harness externo — e é sua responsabilidade.
Böckeler também separa dois papéis dentro dessa camada:
Guias orientam o agente antes* de ele agir: instrução, exemplo, restrição.
Sensores observam o resultado depois* e permitem que ele se corrija.
Cada um dos dois pode ser computacional — uma checagem determinística, como um teste automatizado ou um validador — ou inferencial, como usar outro modelo para julgar a saída.
A maioria dos projetos ruins tem guias demais e sensores de menos. Escrevem um prompt gigante e nenhuma verificação. Aí ficam surpresos quando o agente afirma que terminou uma tarefa que não terminou.
Por que todo mundo chegou na mesma arquitetura
O detalhe mais interessante dessa história é que ninguém desenhou isso de cima para baixo. Cursor, Claude Code, Windsurf e Codex são harnesses, e todos convergiram de forma independente para estruturas parecidas: um loop que chama ferramentas, um gerenciador que comprime o histórico, uma camada de permissão que evita estrago.
Convergência independente é sinal forte. Quando várias equipes resolvendo o mesmo problema chegam na mesma solução sem combinar, geralmente a solução não é arbitrária.
Há também uma mudança de filosofia visível nas implementações mais recentes: empurrar decisões para o modelo em vez de fixá-las no código. Em vez de truncar o contexto num limite fixo, deixar o modelo decidir o que vale manter. Em vez de listar arquivos relevantes, deixar o modelo buscar. O harness deixa de ser o cérebro e passa a ser o sistema nervoso.
O termo não é novidade conceitual. Test harness existe em teste de software há décadas, e evaluation harness é vocabulário comum em benchmark de LLM. O que mudou foi a percepção de que essa camada, e não o modelo, virou o gargalo.
O que isso muda para quem contrata ou avalia um projeto de IA
Aqui está a parte prática.
O modelo é uma peça trocável. Vários modelos podem rodar no mesmo harness. Isso significa que "qual IA vocês usam" é uma pergunta muito menos importante do que parece — e que depender de um fornecedor específico é uma escolha, não uma inevitabilidade.
Falha de agente é problema de sistema, não de prompt. A disciplina de harness engineering trata cada erro como algo a ser corrigido estruturalmente, não como um prompt para reescrever e tentar de novo. Se a resposta da sua equipe para um agente que errou é sempre "vou ajustar o prompt", vocês estão remediando sintoma.
Nem todo caso precisa de harness. Tarefa de um passo só, sem ferramenta e sem estado, não precisa de nada disso. O peso se justifica quando o trabalho é longo, multi-etapa e toca sistemas reais.
Como saber se o seu problema é o modelo ou o harness
Um diagnóstico grosseiro, mas que funciona na maioria dos casos:
* O agente entende errado o que foi pedido → provavelmente instrução e contexto, não modelo.
* O agente entende certo e faz a coisa errada → ferramentas mal descritas ou mal escolhidas.
* O agente esquece o que já tinha feito → gerência de contexto ou persistência.
* O agente fez algo que não deveria ter permissão de fazer → camada de permissão. Esse é o erro caro.
* O agente diz que terminou e não terminou → falta de sensor, falta de verificação.
* O agente raciocina mal sobre um problema genuinamente difícil → aqui sim, pode ser o modelo.
Só o último item justifica trocar de IA. Os outros cinco são engenharia.
Fechando
Se você está avaliando trazer agentes de IA para dentro da empresa, a pergunta que separa proposta séria de vendedor de fumaça não é "qual modelo vocês usam". É:
Como é o loop, o que ele pode executar sozinho, como o contexto é gerenciado e como vocês verificam que o trabalho foi feito de verdade?
Quem não responde isso está vendendo prompt, não sistema.