O modelo é o motor. O harness é o carro.

Hipótese

Quase toda conversa sobre agentes começa pelo modelo: qual é o mais capaz, qual raciocina melhor, qual custa menos. Mas quem já colocou um agente para trabalhar de verdade sabe que a diferença entre uma demo bonita e um sistema confiável raramente está ali. Ela está em tudo que cerca o modelo: o que ele vê, quais ferramentas recebe, como erra e como se recupera.

A hipótese desta série é simples de enunciar e difícil de praticar: tratar o harness como um produto de engenharia, com arquitetura, testes e decisões explícitas, e não como um acúmulo de remendos em volta de uma chamada de API.

Experimento

O núcleo de qualquer harness cabe em poucas linhas. O que importa é a última: cada passo e cada resultado viram evidência registrada, e não apenas texto que passa e some.

while (!tarefa.concluida) {
  const passo = await modelo.proximo(contexto);
  const saida = await ferramentas.executar(passo);
  contexto.registrar(passo, saida); // tudo vira evidência
}

Abaixo, o registro de uma execução real, editado só para caber aqui. Repare onde o agente hesita: é exatamente onde o harness deveria ter dado mais contexto.

Um bom harness não torna o modelo mais inteligente. Torna os erros dele mais baratos.

— hipótese de trabalho

O que fica

Existe algo de antigo nessa ideia. Os artesãos sempre souberam que a qualidade do trabalho depende tanto da bancada quanto da mão. Projetar um harness é, no fundo, projetar uma bancada para alguém que não somos nós e que pensa de um jeito que ainda estamos aprendendo a entender.

Questões em aberto

• Registrar cada passo do loop
• Medir quanto contexto cada tarefa realmente consome
• Decidir quando um erro de ferramenta encerra a tarefa