Harness engineering é a disciplina que sustenta tudo o que está embaixo de um agente de IA moderno: o ciclo de execução, o roteador de ferramentas, o controle de contexto, a validação de saída, o sistema de retry, a observabilidade e a integração com o mundo real. É o "esqueleto" sem o qual um LLM, por mais inteligente que seja, vira só uma caixa de texto que responde mensagens. Em 2026, o termo deixou de ser jargão de laboratório e virou competência de plataforma em qualquer empresa séria sobre IA.
Este guia explica o que é harness engineering, por que ele virou prioridade arquitetural, quais são os componentes essenciais e como montar uma harness robusta o suficiente para rodar produto em escala, sem virar uma colcha de retalhos de prompts e if-elses.
Por que harness engineering existe
Um modelo de linguagem, sozinho, faz uma coisa só: dado um prompt, gera tokens. Tudo o que parece "inteligência" em um agente real (executar ações, consultar bases, escrever em sistemas, tomar decisões, recuperar-se de erros) vive fora do modelo, na camada que orquestra a execução. Essa camada é a harness. O LLM é o motor. A harness é o chassi, a suspensão, a direção, o painel e os freios.
O motivo de a disciplina ter ganhado nome próprio é simples: quem trata harness como detalhe entrega protótipos que quebram em produção. Latência, custo, qualidade, segurança, rastreabilidade e capacidade de evolução do produto dependem 90% da harness e 10% do modelo escolhido. Empresas que entendem isso conseguem trocar de modelo (Claude, GPT, Gemini, Llama) com poucas linhas de mudança e melhorar a qualidade em ciclos curtos.
Componentes essenciais de uma harness moderna
1. Loop de execução (agent loop). O coração da harness. Recebe a entrada do usuário, monta o estado, chama o modelo, interpreta a resposta, executa ações, observa resultado e itera até atingir critério de parada. Boa harness tem loop explícito e auditável, não um for escondido dentro de um framework opaco.
2. Roteador de ferramentas (tool router). Define quais tools (funções, APIs, queries) o agente pode chamar, valida argumentos, executa e injeta o resultado de volta no contexto. Em arquiteturas modernas, esse roteador segue o padrão MCP (Model Context Protocol) ou um equivalente, separando descoberta, schema e execução.
3. Gestão de contexto. Decide o que entra no prompt e o que fica fora: histórico, memória de longo prazo, documentos recuperados via RAG, instruções de sistema, exemplos. Harness boa faz context engineering de forma determinística, com orçamento de tokens claro, prioridade de blocos e truncamento inteligente quando atinge limite.
4. Validação de saída. Garante que o modelo respondeu no formato esperado (JSON válido, schema correto, dentro de uma lista de opções). Boa harness rejeita saída malformada, pede correção e tem fallback. Sem isso, qualquer resposta inesperada vira exceção em produção.
5. Sistema de retry e fallback. Rede, modelo, ferramenta, tudo falha. Harness madura tem circuit breakers, backoff exponencial, fallback para modelo alternativo, replay de execução e idempotência em ações com efeito colateral.
6. Observabilidade. Cada execução é logada com prompt completo, resposta, ferramentas chamadas, latência, tokens, custo. Sem isso, debugar agente é adivinhação. A regra prática: se você não consegue reproduzir a execução de ontem com um clique, sua observabilidade é insuficiente.
7. Avaliação contínua (evals). Conjunto de cenários reproduzíveis que você roda antes de publicar mudança de prompt, modelo ou ferramenta. Evals viraram o "testes unitários" do mundo de IA, e quem não tem regride sem perceber.
Padrões arquiteturais para harness
Três padrões dominam hoje. ReAct (Reason + Act): o modelo intercala raciocínio e chamada de ferramenta em loop até concluir a tarefa. Simples, eficaz para tarefas médias. Plan-and-Execute: o agente primeiro gera um plano de passos, depois executa cada passo separadamente, com possibilidade de re-planejar. Bom para tarefas longas e ambíguas. Multi-agente: múltiplos agentes especialistas se coordenam via mensagens ou via um orquestrador. Indicado para domínios complexos com fronteiras claras (suporte, finanças, devops, jurídico, cada um com seu subagente).
Trade-offs reais: latência, custo, qualidade, segurança
Toda decisão de harness é um trade-off. Mais ferramentas no contexto = mais qualidade na maioria dos casos, mas mais latência, custo e risco de o modelo escolher errado. Mais retries = mais resiliência, mas mais custo e tempo. Modelos maiores = mais qualidade média, mas mais lentos e caros. Harness madura permite tunar cada um desses eixos por caso de uso, sem reescrever código.
Segurança merece nota separada. Toda ferramenta com efeito no mundo (deletar, enviar, pagar, mudar config) deve ter confirmação humana ou guardrails de blast radius antes da execução. Sem isso, um único prompt mal formulado vira incidente de produção.
Quando NÃO fazer sua própria harness
Frameworks como LangChain, LlamaIndex, Vercel AI SDK, Mastra, Claude Agent SDK e outros já trazem harness pronta. Se seu caso de uso é padrão (chatbot de FAQ, sumarização, classificação), provavelmente faz mais sentido começar com framework e migrar para harness própria só quando bater limite. Construir sem necessidade gera código que ninguém mantém.
Quando faz sentido construir: quando o ciclo de execução é específico do seu domínio, quando você precisa de controle fino de latência e custo, quando precisa rodar on-prem sem dependências externas, ou quando o framework virou gargalo de evolução.
Harness engineering na Steply
Na Steply, harness engineering é um dos pilares dos nossos squads de IA. Tratamos a harness como produto interno: tem versionamento, tem testes, tem owner, tem roadmap. Isso permite que cada cliente nosso receba agentes que evoluem em ciclos curtos, com custo previsível e sem regressão silenciosa. Quando alguém pergunta "qual o segredo de um agente bom?", a resposta honesta é: harness boa, modelo certo, dado limpo, eval contínua. Nessa ordem.
