Harness Stack: introdução ao framework de governança runtime
Versão estendida do Harness Stack — as 9 camadas que cercam um prompt em produção, com ordem de implementação e indicadores de falha por camada.
O Harness Stack define as 9 camadas que cercam um prompt em produção. Este post estende com ordem de implementação real, indicadores de falha por camada, e a diferença prática entre “agente que demo bem” e “agente que aguenta produção”.
A pergunta que motiva o framework
Por que agentes que rodam lindo na demo do vendor falham em produção real? Resposta curta: o que separa demo de produção não é o modelo. É o que está em volta do modelo.
A demo tem um humano feliz, dando prompts esperados, em ambiente sem dado real. Produção tem usuário inesperado, dado real com edge case, ação irreversível, e auditoria.
Harness Stack é o checklist do “em volta”.
Ordem de implementação (testada)
Não construa as 9 camadas em paralelo. Construa em ordem, validando cada uma. Ordem aprendida em campo:
Bloco 1 (semana 1-2): Context + Constraint + Verification
Camada 1 · Context. O que o agente vê. System prompt + RAG + tool state. Comece aqui porque qualquer outra camada falha se context está errado.
Indicador de falha: o agente cita info que não existe (alucinação), ou ignora info que existe (context perdido).
Camada 2 · Constraint. O que o agente pode e não pode fazer. Tool allowlist, scope, rate limit. Crítico antes de qualquer ação no mundo real.
Indicador de falha: o agente tenta ação que não deveria; ou trava em rate limit sem fallback.
Camada 3 · Verification. Output checado antes de aplicar efeito. Schema validation, dry-run, sandbox execution.
Indicador de falha: action no mundo com payload errado (schema válido sintaticamente, errado semanticamente).
Bloco 2 (semana 3-4): Durable pause + Confidence gating
Camada 7 · Durable pause. Em ação irreversível, agente para e espera confirmação humana com janela de timeout. Antes de Feedback ou Advisor — porque produção precisa de safeguard prioritário.
Indicador de falha: agente envia email em massa, transfere dinheiro, ou deleta dado sem confirmação.
Camada 8 · Confidence gating. Agente declara confiança antes de agir. Threshold de 0.7-0.85 dispara escalonamento.
Indicador de falha: agente entrega resposta confiante para algo que claramente não sabia.
Bloco 3 (semana 5-6): Failure corpus
Camada 9 · Failure corpus. Repositório versionado de toda falha em produção, com análise.
Comece a coletar desde o dia 1, mesmo manualmente. Em 90 dias você terá o primeiro corpus útil para alimentar as outras camadas.
Bloco 4 (mês 3+): Feedback + Advisor + Emotion
Camada 4 · Feedback. Sinal de aceito/rejeitado/editado volta ao prompt. Demora 2-3 meses para ter volume suficiente para iterar.
Camada 5 · Advisor. Segunda opinião sob carga. Implementação cara — geralmente outro modelo (Opus revisando Sonnet) ou regra estática. Vale só em ações críticas.
Camada 6 · Emotion. Sinais de fricção do usuário detectados e usados para abrir verificação extra. Última camada porque depende de volume e do resto funcionando.
O erro mais comum: pular para “demo legal”
Times nuvem-novos em agentes querem Multi-agent + Advisor + RAG complexo no MVP. Resultado: nove sistemas que metade-funcionam, nenhum confiável.
Padrão que funciona: faça MVP só com Bloco 1 (Context + Constraint + Verification). Coloque em produção limitada. Sofra. Aprenda. Adicione Durable pause no que dói. Depois Confidence gating. Só depois adicione Advisor.
O insight contra-intuitivo
Failure corpus (camada 9) parece a menos importante porque “é só log”. É a mais importante. Sem corpus, as outras 8 camadas não evoluem. Você está iterando no escuro.
É o pavimento.
Onde aprofundar
Para o framework em si: Harness Stack hub. Para a delegação relacionada (qual agente recebe qual tarefa): Agent Trust Stack.