Harness Stack: introducción al framework de gobernanza runtime
Versión extendida del Harness Stack — las 9 capas que rodean un prompt en producción, con orden de implementación e indicadores de falla por capa.
El Harness Stack define las 9 capas que rodean un prompt en producción. Este post extiende con orden de implementación real, indicadores de falla por capa, y la diferencia práctica entre “agente que demuestra bien” y “agente que aguanta producción”.
La pregunta que motiva el framework
¿Por qué los agentes que corren lindo en demo del vendor fallan en producción real? Respuesta corta: lo que separa demo de producción no es el modelo. Es lo que está alrededor del modelo.
La demo tiene un humano feliz, dando prompts esperados, en ambiente sin dato real. La producción tiene usuario inesperado, dato real con edge case, acción irreversible, y auditoría.
Harness Stack es el checklist del “alrededor”.
Orden de implementación (testeado)
No construyas las 9 capas en paralelo. Construye en orden, validando cada una. Orden aprendido en campo:
Bloque 1 (semana 1-2): Context + Constraint + Verification
Capa 1 · Context. Lo que el agente ve. System prompt + RAG + tool state. Empieza aquí porque cualquier otra capa falla si el context está equivocado.
Indicador de falla: el agente cita info que no existe (alucinación), o ignora info que existe (context perdido).
Capa 2 · Constraint. Lo que el agente puede y no puede hacer. Tool allowlist, scope, rate limit. Crítico antes de cualquier acción en el mundo real.
Indicador de falla: el agente intenta acción que no debería; o se traba en rate limit sin fallback.
Capa 3 · Verification. Output revisado antes de aplicar efecto. Schema validation, dry-run, sandbox execution.
Indicador de falla: action en el mundo con payload equivocado (schema válido sintácticamente, equivocado semánticamente).
Bloque 2 (semana 3-4): Durable pause + Confidence gating
Capa 7 · Durable pause. En acción irreversible, el agente para y espera confirmación humana con ventana de timeout. Antes de Feedback o Advisor — porque producción necesita safeguard prioritario.
Indicador de falla: el agente envía email en masa, transfiere dinero, o borra dato sin confirmación.
Capa 8 · Confidence gating. El agente declara confianza antes de actuar. Threshold de 0.7-0.85 dispara escalonamiento.
Indicador de falla: el agente entrega respuesta confiada para algo que claramente no sabía.
Bloque 3 (semana 5-6): Failure corpus
Capa 9 · Failure corpus. Repositorio versionado de toda falla en producción, con análisis.
Empieza a colectar desde el día 1, incluso manualmente. En 90 días tendrás el primer corpus útil para alimentar las otras capas.
Bloque 4 (mes 3+): Feedback + Advisor + Emotion
Capa 4 · Feedback. Señal de aceptado/rechazado/editado vuelve al prompt. Demora 2-3 meses para tener volumen suficiente para iterar.
Capa 5 · Advisor. Segunda opinión bajo carga. Implementación cara — generalmente otro modelo (Opus revisando Sonnet) o regla estática. Vale solo en acciones críticas.
Capa 6 · Emotion. Señales de fricción del usuario detectadas y usadas para abrir verificación extra. Última capa porque depende de volumen y del resto funcionando.
El error más común: saltar a “demo cool”
Equipos nuevos en agentes quieren Multi-agent + Advisor + RAG complejo en el MVP. Resultado: nueve sistemas que medio-funcionan, ninguno confiable.
Patrón que funciona: haz MVP solo con Bloque 1 (Context + Constraint + Verification). Pon en producción limitada. Sufre. Aprende. Agrega Durable pause en lo que duele. Después Confidence gating. Solo después agrega Advisor.
El insight contra-intuitivo
Failure corpus (capa 9) parece la menos importante porque “es solo log”. Es la más importante. Sin corpus, las otras 8 capas no evolucionan. Estás iterando a ciegas.
Es el pavimento.
Dónde profundizar
Para el framework en sí: Harness Stack hub. Para la delegación relacionada (qué agente recibe qué tarea): Agent Trust Stack.