lzt-harness

El reto

Una sesión single-agent de Claude Code pierde contexto más rápido de lo que puedo entregar trabajo útil, y los failure modes de la ejecución agéntica desatendida (operaciones git silenciosas, borrado accidental de archivos, tool calls desbocados) necesitan enforcement belt-and-suspenders en lugar de un prompt esperanzador.

Mi rol

Construí un harness multi-agente sobre Claude Code con ruteo de planner, implementer y reviewer, hooks que bloquean operaciones destructivas por default, y un broker MCP que expone el intent en la metadata de respuesta.

Lo que hice

1. 01

   Tier de ruteo multi-agente

   Por qué: La especialización le gana al contexto en bruto. Un implementer enfocado no dériva como un agente single que está haciendo planning y ejecución a la vez, y un reviewer atrapa lo que el implementer se salta.

   Trade-off: Más overhead de coordinación por tarea y más time-to-first-output para trabajo trivial. La disciplina vale el overhead para cualquier tarea que cruce una sola sesión.

2. 02

   Hooks que bloquean operaciones destructivas por default

   Por qué: Enforcement belt-and-suspenders: el agente nunca debería estar a un keystroke de wipe del working tree o de force-push de una rama. Los hooks bloquean por default y requieren aprobación explícita del operador para hacer bypass.

   Trade-off: Alrededor de 50 milisegundos de latencia por tool call. El bypass requiere una frase literal de aprobación en el mismo turno, lo cual también me frena a mí — a propósito.

3. 03

   Broker MCP con intent-filter

   Por qué: Solo las herramientas en allow-list disparan telemetría, y el broker expone qué pidió un agente versus qué realmente recibió de vuelta. La cadena de auditoría sigue legible incluso cuando una sesión corre por horas a través de múltiples sub-agentes.

   Trade-off: Las nuevas integraciones MCP requieren una entrada explícita en la allow-list. La fricción es intencional — el broker es el chokepoint que evita que herramientas inesperadas corran en silencio.

Lo que cambió

• Duración efectiva de sesión

  Antes: Alrededor de 30 minutos por sesión single-agent

  Después: 4–6 horas a través de sesiones multi-agente

  Evidencia: Logs internos de sesión, 2026-Q3

• Incidentes de pérdida silenciosa de trabajo

  Antes: Alrededor de 2 por mes

  Después: 0 en 2026-Q3 (los casos restantes los atrapa el teleport safety net como advisories)

• Legibilidad de la cadena de auditoría

  Antes: Opaca — agente single, sin trazo por tool

  Después: Log de intent por tool, navegable después de la sesión

Trade-offs

El harness es privado porque las reglas y los hooks están tuneados a mis propios failure modes. Los patrones (ruteo multi-agente, hooks de comandos destructivos, broker con intent-filter) generalizan, pero los archivos de reglas específicas no.

Lo que aprendí

El failure mode del trabajo agéntico no es el agente — son los guardrails faltantes alrededor. Un harness disciplinado convierte al agente de liability en una herramienta en la que confío a las 3am.

Stack

• Go
• Rust
• Python
• Shell
• MCP