Las nueve capas

1 · Context. Lo que el agente ve antes de generar la respuesta. Incluye system prompt, RAG, memoria persistente, estado de herramienta. Context engineering es la disciplina de decidir qué entra y qué se queda afuera. La capa donde la mayoría de los agentes “extraños” están rotos.

2 · Constraint. Lo que el agente puede y no puede hacer. Tool allowlist, alcance de permiso, rate limit, time budget. Las constraints son la mayor palanca de seguridad operativa. Agente sin constraint clara es demo, no producto.

3 · Verification. Cómo el sistema sabe si el output del agente es correcto, antes de aplicar el efecto. Validación de schema, dry-run, ejecución en sandbox, regex assert. Sin verification, el error del agente sale directo al mundo real.

4 · Feedback. Cómo el agente recibe señal sobre el output: aceptado, rechazado, editado, ignorado. La señal vuelve a refinamiento de prompt, de template o de policy. Sin feedback, el agente no evoluciona.

5 · Advisor. Segunda opinión bajo carga — otro modelo (u otro agente, o regla estática) consultado cuando la confidence cae, los stakes suben o la cadena se hizo demasiado larga. El advisor no sustituye al agente; cambia de silla en momentos de riesgo.

6 · Emotion. Señales de fricción del usuario capturadas como dato de gobernanza: reintentos seguidos, mensajes cortos y tensos, abandono. No es “el agente reconoce sentimiento”; es el sistema reconocer que algo está mal y abrir verificación extra.

7 · Durable pause. Para acciones irreversibles (commit a prod, envío de email masivo, transferencia bancaria), el agente se detiene y pide confirmación humana con ventana de timeout durable. Faltar esta capa es la causa raíz del 80% de los incidentes de agente en producción.

8 · Confidence gating. El agente declara confianza antes de declarar respuesta. Cuando la confidence cae bajo el threshold, escala al Advisor o al humano. La confidence calibrada vale más que la precisión cruda.

9 · Failure corpus. Repositorio versionado de cada falla observada en producción: qué entró, qué salió, por qué estaba mal, qué capa falló. El failure corpus alimenta las otras 8 capas continuamente. Sin corpus, el sistema olvida los errores y los repite.

Cómo aplicarlo

Usa Harness Stack como checklist de auditoría: para cada capa, ¿el agente tiene implementación explícita? “Implícito en el prompt” es respuesta de falla. Cada capa debe ser código, configuración o policy nombrada — no esperanza.

El orden de implementación importa. Construir primero las capas 1-3 (Context, Constraint, Verification); después 7-8 (Durable pause, Confidence gating); después 9 (Failure corpus). Las capas 4-6 (Feedback, Advisor, Emotion) entran después que el agente está rodando.

Dónde Harness Stack hace la diferencia en práctica

Agente de atención multi-canal (WhatsApp/Telegram/Slack): capas 1 (Context), 2 (Constraint) y 9 (Failure corpus) quedan a nivel del gateway; el mensaje nunca llega al agente sin pasar por el policy.
Coding agent en CI (Claude Code, Cursor agent mode): capas 3 (Verification) y 7 (Durable pause) bloquean force-push, drops de schema, exec de scripts no auditados.
Agente conversacional en vertical regulada (legal, contable, salud): capas 5 (Advisor) y 8 (Confidence gating) cortan respuestas donde el agente no tiene evidencia fuerte.

Posts relacionados

Harness Stack: introducción al framework
Agent Trust Stack — qué tarea delegar a qué agente, dado el harness actual.

Cuándo usar

Agente de IA en producción (no demo, no POC) que ejecuta acción en el mundo real.
Auditoría de incidente de agente: identificar qué capa falló.
Briefing para AI engineer construyendo nuevo agente en stack de agentes en producción.

Cuándo NO usar

Prototipado rápido o demo desechable — overhead injustificado.
Agente puramente conversacional sin tool use — algunas capas (Verification, Failure corpus) no se aplican.