Construyendo un harness de agente de producción alrededor de Claude Code
La respuesta corta
Un agente de codificación por sí solo es un cerebro en un frasco. Puede pensar y escribir código, pero no puede responder tu Slack DM a las 3am, reintentar un trabajo de CI fallado, ni recordar que la pregunta de un revisor sigue sin responder. El harness —el andamiaje de ejecución alrededor del LLM— es lo que le da sentidos, manos y memoria.
Esta es una vista de arriba hacia abajo de la canalización multiagente en producción de un equipo construida sobre Claude Code: una que ha vigilado un canal de Slack, abierto MRs contra cinco repositorios internos, atendido comentarios de revisores durante la noche y ha autorreparado CI de manera silenciosa durante varios meses. El cerebro (el modelo) es esencialmente intercambiable; lo que cambia es el harness que lo rodea.
Por qué un harness, no solo un agente
Tres modos de falla aparecen durante la primera semana de poner una UI de chat frente a un LLM:
- Pierde contexto cuando cierras la pestaña. Una tarea real se extiende días. Ninguna llamada única al LLM mantiene ese estado.
- No puede reaccionar al cambio externo. Un revisor comenta a las 4pm; CI falla en el tercer commit. El agente debe activarse con eventos, no hacer polling hasta el infinito.
- No puede recuperarse de sus propias fallas. Hace push de un commit, CI se rompe, y el operador tiene que volver a explicarlo mañana.
El harness cierra tres brechas correspondientes: reactividad, persistencia y calidad.
Las seis capas
1. Ingesta de eventos
El harness se despierta con señales externas — menciones en Slack, eventos MR/CI de GitLab, pages de PagerDuty — canalizados a una cola de despacho unificada. El LLM nunca hace polling; lo invocan. Los detalles prácticos importan: congelar cursores en polls vacíos de Slack para evitar saltarse ocasiones por latencias de consistencia, eliminar duplicados por message tsc past, y emparejar Socket Mode con un poller como red de seguridad para que las caídas de conexión no devoren mensajes.
2. Orquestación de agentes
Los workers se crean como unidades transitorias que llevan una carga JSON nombrando un workflow + directorio del caso + contexto del hilo. Cada pipeline es una invocación de larga duración de Claude Code con un prompt curado y un espacio de trabajo escribible. La coreografía usa varios agentes especializados encadenados en puntos de entrega definidos: un agente de investigación, un agente de seguimiento de larga duración, un consolidator y un "doer" que hace el cambio, vigila CI y atiende comentarios de revisión.
Dos elecciones no obvias: todo corre en git worktrees (los casos concurrentes nunca se pisan entre sí), y el directorio del caso es la única fuente de verdad a la que cada workflow converge.
3. Estado persistente
El estado vive en tres capas: caches en memoria (reconstruibles), mapas JSON locales (seguros ante reinicios) y workspaces sincronizados con git (duraderos, entre máquinas). El estado vive en git, no en un proceso — así es como una sesión se reanuda en una laptop o en una VM remota con contexto completo.
4. Bucles de autorreparación
Tres bucles se cierran sin intervención del operador: auto-fix de CI (limitado a 3 fallos consecutivos, luego escalar), respuesta automática a revisores (con deduplicación consciente del autor para que no vuelva a dispararse) y una renovación de tokens protegida por MFA. Sin presupuestos de reintento y autoconocimiento, los bucles se espiralan — una prueba inestable produjo 80 commits sin efecto en una tarde.
5. Observabilidad
Cuatro superficies: actualizaciones de estado en vivo en Slack (editando un único mensaje), logs estructurados para grep, DMs en Slack para eventos terminales (MR abierto/mergado, escalado) y un log del sistema. Deliberadamente sin dashboard — Slack y grep son las consolas. La salud del MCP tiene su propio watchdog para que un token expirado aparezca como "herramienta devolvió resultado vacío" en lugar de "el agente está tonto hoy".
6. Control humano en el bucle
Toda interacción del operador fluye por un único self-DM con seis familias de comandos (task, on-call, MR control, pause, finalize, registry). El interruptor de pausa está calibrado con precisión: silencia el despacho automático impulsado por la actividad de otras personas, pero nunca los propios comandos del operador.
El punto de palanca más importante: salida estructurada
La conclusión del equipo: la prosa libre es la enemiga de una canalización. Cada iteración de investigación termina con un contrato parseable en JSON — completion_report — con estado, confianza, preguntas abiertas, fuentes sin verificar, contradicciones, suposiciones y una respuesta de borrador. Las puertas evalúan el JSON parseado como Python determinista, no como prosa.
Puertas de calidad: hacer que la confianza signifique algo
La confianza sería ruido de marketing si el modelo pudiera simplemente escribir 95 sin sustento. El harness impone un marco de puertas de 19 funciones con tres familias:
- G-gates (consistencia lógica) — el razonamiento no puede contradecirse a sí mismo entre rondas; un aumento en preguntas abiertas invalida una subida de confianza.
- N-gates (completitud estructural) — los artefactos deben estar completamente formados; cada fix va acompañado de una acción de verificación.
- A-gates (techos de aserción) — límites mecánicos que el modelo no puede anular con prosa. La confianza se capifica aritméticamente:
1.0 − (open_questions × 0.08) − (unchecked_sources × 0.05), sin importar lo que escriba el modelo.
Las violaciones de puertas se convierten en notas de guardia prepended al prompt de la siguiente iteración — el mecanismo de imposición. Las violaciones no bloquean al modelo; hacen que las violaciones previas sean lo primero que lea en la ronda siguiente.
Revisión adversarial: el equipo rojo interno
Una vez que la investigación se declara terminada con confianza ≥ 70, el control pasa a una invocación separada de Claude que hace el papel de revisor adversarial. Evalúa 15 dimensiones y produce un veredicto — problemas críticos devuelven el bucle; dos pases consecutivos con solo menores o un pase limpio lo completan. El mismo modelo interpretando un rol distinto captura una fracción significativa de la complacencia propia que una iteración en un solo prompt suele pasar por alto. Un revisor de equipo rojo estructuralmente separado ve solo la declaración del problema y la conclusión final, comprobando si la conclusión era alcanzable sin el encuadre de la investigación.
Auto-mejora: el harness se arregla a sí mismo
La característica distintiva: el sustrato del harness es su propio código fuente, y cada caso cerrado retroalimenta.
- Reparación por caso — un analizador de brechas identifica dónde el harness no funcionó bien y abre un PR contra el propio codebase del harness. Merge humano, sin escritura humana.
- Refuerzo entre casos — los modos de falla se cuentan por proyecto; un cron semanal sugiere cambios en el SOP cuando un modo cruza umbrales. Deliberadamente no se aplican automáticamente, porque las decisiones automatizadas que acumulan errores son una clase de falla conocida.
Después de 20–30 casos, el SOP de cada proyecto se personaliza según sus propios patrones de falla. El harness lo practica sobre sí mismo: pr-ci-fixer recoge fallos en las MRs de mejora del propio harness, para que el agente mantenga su propio CI en verde.
Conclusión
La lección estructural es el meta-bucle: cada cicatriz se detectó porque un ticket real lo ejercitó. El bucle de construir y el bucle de operar son el mismo bucle en diferentes escalas temporales.
> Construye el bucle primero. Hazlo autónomo después. Un sistema autónomo sin una vía de retroalimentación hacia su propio sustrato es solo una forma más rápida de enviar el mismo conjunto de errores, a escala.
Este es un escrito de arquitectura sobre el sistema de producción de un practicante construido sobre Claude Code. Los conceptos y citas hacen referencia al ensayo original de Messi Li (mayo de 2026); el diseño del mecanismo aquí es síntesis original. No hay afiliación con Anthropic.