El teatro de la intervención humana
El debate equivocado que los equipos siguen teniendo: automatización total versus control manual total.
Los equipos de alto rendimiento no hacen ninguna de las dos cosas. Automatizan la ejecución determinista y reservan las decisiones humanas para los límites de riesgo donde el juicio cambia materialmente el resultado.
La pregunta no es "¿deberían participar los humanos?". Es "¿dónde mejora realmente un humano la decisión?".
La revisión humana añade valor real cuando:
- Hay una ambigüedad en la compensación de riesgos
- Se está manejando una excepción de política
- Un conflicto de prioridades entre equipos necesita resolución
- Un incidente que afecta al cliente está en contexto
No añade valor para comprobaciones deterministas repetitivas que ya tienen criterios explícitos de aprobación/rechazo. Pedir aprobaciones allí no aumenta la seguridad, sino que aumenta el tiempo de espera en la cola.
Define los límites de aprobación como decisiones de arquitectura, no como hábitos. La promoción a producción, las anulaciones de controles de seguridad, las excepciones temporales de políticas, los saltos de reversión de emergencia: estos son los límites reales. Todo lo demás debe ser impulsado por el flujo de trabajo.
En 2025 y 2026, otro límite pertenece a esa lista: cambios de confianza ascendentes.
Si un flujo de trabajo introduce una nueva acción de terceros, cambia una acción de fijación de SHA de commit a una etiqueta mutable, expande el alcance del token del ejecutor, o abre una nueva ruta de ejecución que contiene secretos, eso no es una edición de fontanería rutinaria. Eso es un evento de gobernanza. Trátalo como tal.
Tres estados de gobernanza:
- Aprobado: todas las puertas automatizadas requeridas tuvieron éxito
- Bloqueado: la puerta requerida falló o hubo una violación de política estricta
- Escalar: evidencia automatizada insuficiente; se requiere decisión humana
Cuando se necesita una escalada, la transferencia debe ser compacta: qué falló, qué puertas están afectadas, enlaces de evidencia, riesgo operativo, opciones recomendadas. Sin volcados de registros. Los revisores necesitan apoyo para la toma de decisiones, no arqueología.
La señal de advertencia de que algo anda mal: gobernanza en la sombra. Ingenieros diciendo "obtuvimos aprobación verbal" sin un artefacto. Decisiones de reejecución manual no reflejadas en los registros del flujo de trabajo. Los criterios de decisión difieren entre equipos. Si esto está sucediendo, tu modelo de gobernanza no está codificado con la suficiente solidez.
No saltes de operaciones manuales a autonomía total. Construye confianza a través de la evidencia:
- Modo de observación - el flujo de trabajo recomienda, los humanos deciden.
- Modo asistido - el flujo de trabajo ejecuta automáticamente puertas de bajo riesgo, los humanos aprueban en los límites.
- Autonomía gobernada - el flujo de trabajo maneja la mayoría de las rutas, escala las excepciones definidas.
Los recientes incidentes en la cadena de suministro hacen que esta progresión sea aún más importante. Los equipos que saltan directamente a "la automatización sabe qué hacer" suelen descubrir demasiado tarde que la automatización también ejecuta felizmente dependencias envenenadas, etiquetas controladas por atacantes o lanzamientos de mantenedores comprometidos si nadie codificó el límite de confianza en el código fuente.
Lo que construimos en Kolsetu: la gobernanza está compilada, no impuesta por convención. allow_default_branch=false falla la ejecución si alguien activa la orquestación desde main o master - sin excepciones, sin anulaciones verbales. Cada puerta se resuelve en uno de tres estados explícitos: passed, skipped-by-input o failed. strict_full_plan=true falla la ejecución si alguna puerta definida no se resuelve en un estado explícito - sin pases silenciosos. La escalada siempre incluye un paquete estructurado: qué falló, qué puertas están afectadas, enlaces de evidencia, opciones recomendadas. El paquete no es negociable, porque sin él la escalada se convierte en una alarma de incendio sin dirección.
Observabilidad construida para un solo trabajo
Los flujos de trabajo agénticos a menudo se presentan como "automatización más inteligente".
Operacionalmente, se comportan como sistemas distribuidos: múltiples etapas, dependencias asíncronas, fallos parciales, reintentos, tiempos de espera, traspasos humanos.
Si tu modelo de observabilidad asume un solo trabajo lineal, el manejo de incidentes será lento. Y si has construido las puertas 8-11 de la Parte 2 (cobertura de lenguaje, métricas del sistema, integridad de registros, higiene de logs), ya has creado exactamente este tipo de dependencia de estado distribuido. Las evaluaciones de cobertura de lenguaje, por ejemplo, abarcan múltiples llamadas, múltiples lenguajes, contexto a nivel de sesión. No hay una sola línea de log que te diga que pasó.
Observa cuatro capas:
- Capa de orquestación - eventos de despacho, transiciones de puerta, temporización
- Capa de ejecución del trabajador - ejecuciones individuales de puertas, entradas utilizadas, salidas producidas
- Capa de salida/mutación - qué cambió realmente y cuándo
- Capa de decisión de gobernanza - decisiones de aprobación/bloqueo/escalada y su evidencia
Para cada ejecución, captura: identidad de la ejecución e IDs de correlación, transiciones de puerta con marcas de tiempo, eventos de despacho y finalización, referencias y hashes de artefactos, operaciones de salida realizadas, estado de decisión final y razón.
Y para cualquier flujo de trabajo que pueda tocar secretos, compilaciones, paquetes o rutas de despliegue, captura también la evidencia de confianza: qué SHAs de acción se ejecutaron realmente, qué versiones de paquetes se resolvieron, a qué hosts externos se contactó, qué alcances de token se utilizaron y si la ejecución cruzó un límite de aprobación.
Sin esto, los reintentos son ciegos y las auditorías son costosas.
Construye para la reproducción, no solo para el reintento.
El reintento es útil cuando es probable un fallo transitorio. La reproducción es esencial cuando necesitas confianza en el análisis causal: volver a ejecutar un segmento con las mismas entradas, restricciones y contexto de política para entender por qué algo falló, no solo que falló.
"Funciona ahora, se desconoce por qué" no es un estado de recuperación aceptable.
Clasifica los fallos de forma consistente: fallo de entrada, fallo de política, fallo de dependencia, fallo de lógica, fallo de salida. Esta clasificación pertenece a tus resúmenes y alertas.
Ese cubo de fallos de dependencia ya no es teórico. Ahora cubre exactamente los escenarios por los que los equipos siguen quemándose: una etiqueta de acción comprometida, un artefacto de lanzamiento envenenado, acceso sospechoso a la memoria del ejecutor o tráfico saliente inesperado durante un paso de compilación que "normalmente solo instala herramientas".
Las alertas deben ser accionables en menos de un minuto: nombre de la puerta, clase de fallo, ID de correlación, enlace directo de ejecución, primera acción sugerida y cualquier señal de confianza anormal (nuevo destino de red, dependencia no fijada, cambio de alcance de token o ruta de ejecución inesperada). Si una alerta no ayuda a un ingeniero a dar el primer paso en menos de 60 segundos, está incompleta.
Después de cada incidente significativo, pregunta: ¿era esto prevenible por reglas de origen? ¿Se manifestó el fallo en la etapa correcta? ¿Qué único campo de instrumentación habría acortado el diagnóstico? Codifica la respuesta en el código fuente y las pruebas. No en la memoria.
Lo que construimos en Kolsetu: cada puerta en el resumen previo a la fusión incluye el nombre del flujo de trabajo, el ID de ejecución, la URL de ejecución y el estado. Las entradas de respaldo de la puerta se registran para que los revisores vean lo que la orquestación realmente usó, no solo lo que se pasó. Cuando se necesita una reproducción, las entradas exactas, las restricciones y el orden de ejecución de la puerta se fijan en tiempo de compilación en el .md de origen, no se reconstruyen de la memoria. El modo de fallo es explícito: "Detener inmediatamente ante el primer fallo grave y producir un informe de fallo conciso con las URL de ejecución y la siguiente acción".
Operacionalmente, la lección de la última ola de compromisos de la cadena de suministro es simple: si no puedes responder rápidamente "¿qué código ascendente exacto se ejecutó, con qué permisos y con qué intentó comunicarse?" entonces tu observabilidad no está lista para la automatización de producción.
Midiendo la actividad en lugar de los resultados
La mayoría de los equipos miden las cosas equivocadas:
- Número de flujos de trabajo creados
- Número de ejecuciones de agentes
- Reducción de comentarios manuales
Estas son métricas de actividad. La pregunta real es si la velocidad de entrega mejoró mientras la calidad y el control se mantuvieron.
Modelo de métricas de tres capas:
Capa 1 - Rendimiento de entrega:
- Tiempo de entrega de fusión
- Tiempo desde que el PR está listo hasta la decisión final
- Tiempo en cola en los límites de gobernanza
Capa 2 - Calidad y fiabilidad:
- Defectos escapados vinculados a fallos del proceso de fusión
- Tasa de reapertura/reversión para cambios fusionados
- Frecuencia de reejecución de puertas fallidas
Capa 3 - Riesgo y gobernanza:
- Tasa de violación de políticas
- Tasa de bloqueo por detección de amenazas
- Tasa de intervención humana por categoría
- Conteo de aprobaciones de excepciones
Utiliza tanto indicadores adelantados como rezagados. Los adelantados (estabilidad de aprobación de puertas, defectos de ambigüedad de prompts, latencia de alerta a acción) para dirigir rápidamente. Los rezagados (tasa de incidentes, tiempo medio de recuperación, confianza de los stakeholders en la preparación de la fusión automatizada) para validar la dirección.
Establece una línea de base antes del despliegue: tiempo de decisión de fusión de los 30 días anteriores, recuento de puntos de contacto manuales existentes, perfil de incidentes de la versión actual. Mide a los 30/60/90 días después de la adopción. Esto proporciona una comparación justa y evita informes basados en narrativas.
Cuando el rendimiento mejora, pregunta qué lo impulsó. ¿Diseño del flujo de trabajo? ¿Cambio de comportamiento del equipo? ¿Volumen reducido? ¿Estabilización del entorno? No atribuyas todo al flujo de trabajo agéntico.
Después de 90 días, lo "bueno" se ve así:
- Menor latencia en la decisión de fusión
- Menos pasos de traspaso manual
- Perfil de defectos/reversiones estable o mejorado
- Límites claros para la escalada humana
- Mejor auditabilidad de las decisiones de lanzamiento
¿El único problema? Si la velocidad mejora pero las señales de riesgo se degradan, no has resuelto el problema. Lo has hecho más rápido de crear.
Y eso es exactamente lo que expusieron estos incidentes recientes. Muchos equipos tenían pipelines rápidos. No tenían pipelines confiables.
Lo que construimos en Kolsetu: la puerta previa a la fusión termina con un informe de cobertura: 11 puertas, cada una con estado explícito (aprobado / omitido / fallido). Después de 90 días, sabemos exactamente qué puertas fallan más, cuáles son las más lentas y dónde se agrupan los reintentos. La señal no es “cuántos flujos de trabajo se ejecutaron” - es “cuántas ramas superaron las 11 puertas limpiamente sin un reintento”. Eso es lo que se correlaciona con la estabilidad de producción.
La lista de verificación completa de la serie - las 8 bases:
- Grafo de puertas explícito
- Lógica de flujo de trabajo gestionada por código fuente/compilación
- Controles de seguridad nativos, no añadidos a posteriori, incluyendo referencias inmutables, permisos estrictos y límites de confianza explícitos
- Responsabilidades de orquestación y trabajador separadas
- Prompts escritos como protocolos
- Aprobaciones humanas basadas en límites, no en hábitos
- Observabilidad reproducible
- Medición de resultados, no de actividad
¡Boom! Si puedes responder afirmativamente a las ocho, tu programa de flujo de trabajo agéntico está operando como un sistema de ingeniería, no como una demostración.
Lectura adicional:
