A peça que faltava no seu agente
Seu agente falha porque o modelo é fraco ou porque a transmissão está errada? A resposta muda tudo.
A TESE
Um modelo de IA sem harness é como um motor sem transmissão. Funciona no banco de testes, não na estrada. AI Jason, criador de conteúdo britânico especializado em arquitetura de agentes, tornou público o que engenheiros de IA já sabem mas raramente explicam: harness engineering é a disciplina que transforma a inteligência bruta de um modelo em trabalho consistente e confiável. Quem entende isso para de culpar o modelo quando o agente falha e começa a corrigir o que realmente está errado.
O QUE A MAIORIA ESTÁ ERRANDO
Quando um agente falha, a reação padrão é trocar o modelo. Usar um mais caro, mais recente, mais capaz. Às vezes funciona. Geralmente não, porque o problema não estava no motor. Estava na transmissão.
O harness é a camada que envolve o modelo: as instruções de sistema, os exemplos de comportamento esperado, as ferramentas disponíveis, os critérios de quando chamar cada ferramenta, os guardrails que impedem o modelo de agir fora do escopo. É o que determina se o modelo vai usar sua inteligência de forma útil ou vai divagar em direções que ninguém pediu.
A maioria das implementações de agentes que falham em produção não têm problema de modelo. Têm problema de harness: instruções ambíguas, ferramentas demais disponíveis sem critério claro, ausência de exemplos do comportamento esperado, nenhum mecanismo para o agente sinalizar quando não sabe o que fazer.
O resultado é um agente que funciona bem nos testes, onde os casos são previsíveis, e quebra em produção, onde os usuários fazem perguntas que ninguém antecipou.
O QUE OS MELHORES ESTÃO FAZENDO
Equipes que constroem agentes confiáveis tratam o harness como produto. Não como configuração inicial que nunca mais é tocada.
Na prática, isso significa iterar sobre as instruções de sistema com a mesma disciplina que se itera sobre código. Cada falha em produção vira um caso de teste. Cada caso de teste informa uma atualização no harness. O modelo não muda. O contexto em que ele opera muda, e fica mais preciso a cada ciclo.
Outro padrão consistente: separar o que o modelo decide do que o harness controla. O modelo decide o conteúdo da resposta. O harness decide quando chamar uma ferramenta, qual ferramenta chamar, e o que fazer quando a ferramenta falha. Misturar essas responsabilidades cria agentes imprevisíveis.
O terceiro padrão é escopo deliberado. Os agentes mais confiáveis fazem menos coisas, não mais. Um harness bem construído define com clareza o que está fora do escopo e instrui o agente a sinalizar quando chega nessa fronteira, em vez de improvisar.
MINHA VISÃO
Harness engineering vai virar uma função explícita nas empresas que levam agentes a sério. Hoje está escondida dentro do papel do engenheiro de IA ou do desenvolvedor que "cuida dos prompts". Nos próximos dois anos, vai ganhar nome, processo e critérios de avaliação próprios.
A analogia que faz mais sentido é com o UX design nos anos 2000. Por muito tempo, interface era responsabilidade do desenvolvedor: uma tarefa técnica entre outras. Quando ficou claro que a qualidade da interface determinava o sucesso do produto, UX virou disciplina separada com metodologia própria.
O harness determina a qualidade do agente da mesma forma que a interface determina a qualidade do software. A diferença entre um agente que os usuários confiam e um que abandonam depois de duas tentativas está, na maioria dos casos, no harness.
Saber construir um harness bem calibrado é vantagem de curto prazo. Vai virar requisito de médio prazo.
A PERGUNTA QUE EU DEIXO
Se você abrisse as instruções de sistema do agente que mais usa hoje, encontraria um documento com intenção clara ou um conjunto de regras que ninguém mais lembra de onde vieram?
Ouça no podcast: Este tema é debatido no episódio EP01: O motor da IA ficou mais forte. E a transmissão?. Mark, Lily e Raquel aprofundam o que a newsletter não cobre.
