O agente mexe em arquivos fora do ticket, “melhora” código que ninguém pediu e esquece convenções no meio da sessão. A correção foi sem glamour: um conjunto de instruções persistente — um CLAUDE.md codificando convenções, guardrails e disciplina de escopo, refinado toda vez que uma falha revelava uma regra faltando. Estabilidade na região do prompt: sem graça, e responsável pela maior queda isolada em violações de convenção que medi no ano todo.

As sessões ficam lentas e a qualidade cai conforme o contexto incha — histórico completo de interação mais arquivos grandes injetados, até o sinal afogar. A intervenção: session grounding. Um hook de SessionStart injeta um conjunto pequeno de arquivos de contexto curados e em checkpoint no lugar do histórico acumulado. A lição que custou caro é um trade-off: o contexto injetado tem que ser pequeno e estável, ou o próprio mecanismo de grounding vira o inchaço.

Agentes em paralelo falham de um jeito específico: cada um completa sua tarefa corretamente isolado, e os resultados não se compõem, porque nenhum agente sabe o que os outros aprenderam. O padrão que resolveu: subagentes rodam em contextos totalmente isolados e devolvem apenas resumos destilados a um agente orquestrador. O contexto fica limitado por agente; o conhecimento ainda circula lateralmente pela etapa de síntese.

O núcleo do trabalho: cinco agentes de revisão específicos de domínio codificando as convenções da agência — semântica de markup, arquitetura de CSS, padrões de backend, acessibilidade, disciplina de escopo. O loop que desenhei para treiná-los: implementar, os agentes revisam, o code review do dono do código — prática padrão na agência para todo pull request — pega o que sobrou, e eu registro cada correção como feedback estruturado — ground truth — e atualizo os agentes. Repete. A cada ciclo a distância encolhia — medida, não sentida — até o revisor principal chegar a 11/11 de concordância com as correções reais de pull request do lead. Não é aprovação por depoimento; é calibração empírica.

O harness deixou de ser um jeito de trabalhar e virou dois plugins. O primeiro ficou com o cliente: um plugin de convenções para os projetos Umbraco da agência, construído em três dias em abril de 2026 — 5 agentes de revisão, 8 skills de carga automática, 2 comandos. Ele roda todos os revisores especializados em paralelo e acrescenta as checagens que nenhum revisor sozinho consegue fazer: um erro de digitação entre um hook js-* no Razor e o querySelector em TypeScript que o procura, um componente usado no Razor mas nunca registrado na init factory, um token usado no SCSS que não existe no variables.scss. Quando o dono do código corrige um pull request, a correção é salva como feedback e codificada como regra no agente correspondente.

O segundo é o compounder, seu sucessor open source — reconstruído do zero e generalizado para além de uma stack, feito para rodar em Fable, Opus, Sonnet e Haiku: 15 skills de cerca de cem linhas cada — o pipeline, mais contratos de objetivo com critérios de aceitação verificáveis, handoffs de sessão, guardrails em camadas e um conselho de avatares para as decisões em volta do trabalho — 7 agentes (pesquisador, quatro revisores, verificador adversarial, executor fork), um hook que captura recados no meio do trabalho para que uma mensagem nunca desvie a tarefa em curso, e /slfg, o pipeline inteiro como enxame. Seus portões de qualidade são rodados por um agente que tenta refutar a evidência em vez de confiar na autodeclaração do próprio pipeline.

Em fevereiro de 2026, a OpenAI publicou “Harness engineering”, cinco meses entregando um produto sem código escrito à mão. O trabalho do engenheiro, nas palavras deles: “desenhar ambientes, especificar intenção e construir loops de feedback que permitam aos agentes fazer trabalho confiável”. Em julho, pesquisadores publicaram “The Harness Effect”: mesmos cenários corporativos, mesmos prompts, mesmos seis modelos — só a camada de orquestração mudou. Cerca de 38% menos tokens, 41% menos custo, 44% menos tempo de execução, qualidade estatisticamente igual. O vocabulário deles descreveu retroativamente este ano: token maxing era o meu problema de degradação antes do session grounding; harness leverage batia com o que eu via a cada upgrade de modelo. A camada que eu vinha construindo tinha nome.

Harness engineering é design de interface. Decidir que contexto um agente vê é arquitetura de informação. Guardrails e disciplina de escopo são design de restrições. O flywheel é um loop de usabilidade — observar a falha, ajustar o sistema, medir de novo. Quase trinta anos de prática de design acabaram sendo estruturais para um problema que parece, de fora, engenharia pura.