El humano en el loop no es una red de seguridad. Es una decisión de arquitectura.

El agente prepara. El humano aprueba. El agente ejecuta.

Ese loop de tres pasos suena simple. En la práctica, la mayoría de los equipos lo implementan mal de una de dos formas. O eliminan al humano completamente y descubren que su agente envío un contrato alucinado a un cliente, o insertan al humano en cada paso y descubren que nadie lee la notificación número 47 del día en Slack. Ambos modos de falla producen el mismo resultado: la supervisión humana no esta funcionando.

Estamos construyendo sistemas de agentes en las seis unidades de negocio de Odisea en este momento. 90+ roles de agentes, 10 sistemas distintos, tareas reales con consecuencias reales. Alrededor de la tercera semana operando nuestro daemon de investigación legal, nos dimos cuenta de que el humano-en-el-loop no es una feature que se añade al final. Es una decisión estructural que determina si todo el sistema funciona o genera ruido caro.

Este es el framework que estamos usando.

Tres Niveles de Autoridad

Cada acción de agente en nuestros sistemas cae en uno de tres niveles. La asignación de nivel ocurre en tiempo de diseño, no en tiempo de ejecución. El agente no decide cuanta supervisión necesita. El arquitecto lo decide.

T1: Autónomo. El agente ejecuta y registra. Ningún humano ve el output antes de que surta efecto. El agente registra lo que hizo, y alguien puede revisar el log después si quiere. La mayoría de los agentes pasan la mayor parte de su tiempo aquí.

Ejemplos de nuestros sistemas en producción: un agente de investigación extrayendo datos de mercado de fuentes publicas. Un ingeniero de corpus indexando documentos legales. Un job de consolidación de memoria fusionando los hallazgos de la semana en archivos por categoría. Un agente de métricas calculando gasto diario contra topes de presupuesto.

Los criterios para clasificación T1: la acción es reversible, el radio de impacto se limita a estado interno, y el costo de un error se mide en compute desperdiciado en lugar de relaciones dañadas o dinero perdido.

T2: Notificar. El agente ejecuta e informa. La acción ocurre inmediatamente, pero un humano recibe una notificación estructurada mostrando que paso y por que. El humano puede intervenir después del hecho si algo se ve mal.

Ejemplos: un agente de outreach enviando un email de primer contacto a un prospecto desde una plantilla pre-aprobada. Un agente de ventas actualizando una etapa del pipeline de CRM. Un agente de contenido publicando un borrador en una cola de revisión interna. Un agente de monitoreo flaggeando que se supero un umbral de presupuesto.

Los criterios para T2: la acción tiene visibilidad externa o afecta un flujo de trabajo compartido, pero el costo de una sola ejecución mala es bajo y corregible en horas.

T3: Esperar. El agente redacta y espera aprobación humana explícita antes de que algo ocurra. Este es el único nivel donde el agente esta bloqueado por una decisión humana.

Ejemplos: enviar una propuesta a un cliente. Registrarse en un servicio de pago. Publicar contenido en el sitio web de la empresa. Modificar un schema de base de datos de producción. Responder un email de un prospecto que hizo una pregunta que el agente no ha encontrado antes.

Los criterios para T3: la acción es irreversible o de alto impacto, el radio de impacto se extiende a stakeholders externos, o el costo de un error se mide en confianza en lugar de tiempo.

Por que tres niveles en lugar de dos

El instinto de la mayoría de los equipos es binario: o el agente actua solo, o un humano aprueba cada acción. El problema con la clasificación binaria es que te fuerza a elegir entre dos malas opciones para una gran categoría de acciones que caen en el medio.

Toma las actualizaciones de CRM. Si las clasificas como T1 (totalmente autónomo), obtienes un agente que silenciosamente mueve un deal de “Calificado” a “Propuesta Enviada” sin que nadie se entere hasta que el reporte del pipeline se ve mal. Si las clasificas como T3 (aprobación humana requerida), obtienes una cola de aprobación que se atasca con 30 cambios de etapa de pipeline por día, cada uno trivial, cada uno entrenando al humano para hacer click en “Aprobar” sin leer.

T2 resuelve esto. El agente mueve la etapa del deal inmediatamente (porque la velocidad importa en operaciones de ventas) y postea un resumen en el canal de ventas. Si el movimiento fue incorrecto, alguien lo detecta en horas. La acción es visible sin estar bloqueada.

El modelo de tres niveles también hace concreta la conversación de diseño. En lugar de debatir si un agente “debería tener supervisión humana” (una pregunta sin respuesta útil a ese nivel de abstracción), el equipo pregunta: “Es reversible esta acción? Cual es el radio de impacto? Cual es el costo de una ejecución incorrecta?” Esas preguntas tienen respuestas especificas que mapean directamente a T1, T2 o T3.

El flujo de aprobación de Penélope

Penélope es nuestro agente de producción de podcasts. Monitorea email, investiga invitados potenciales, redacta respuestas y gestiona la agenda via Notion. El sistema maneja docenas de interacciones por día en múltiples hilos de email.

Su flujo de respuesta de email es una implementación limpia de T3. Cuando Penélope redacta un email, postea el borrador en un canal de Slack con tres botones: Aprobar, Rechazar, Editar. El humano lee el borrador, toma una decisión, y el agente o envia, descarta o espera una versión editada.

Esto funciona por una razón específica: la solicitud de aprobación contiene exactamente el contexto suficiente para una decisión y nada más. El mensaje de Slack muestra el destinatario, el asunto y el texto completo del borrador. El humano no necesita entender como Penélope encontro este email, que queries de búsqueda ejecuto, que borradores alternativos considero o cual era su score de confianza. Solo necesita responder una pregunta: “Debe salir este email tal como esta?”

También estamos probando un mecanismo de timeout. Si una solicitud de aprobación esta en Slack por más de 4 horas, el sistema la marca como obsoleta y envia un recordatorio. Después de 24 horas, pasa a estado “expirado” y el agente reevalua si la respuesta sigue siendo relevante. El timeout existe porque una solicitud de aprobación olvidada es peor que ninguna solicitud de aprobación. Crea una falsa sensación de seguridad: el humano piensa que el agente esta esperando, el agente piensa que el humano esta revisando, y el email nunca se envia.

El verificador de aprobaciones corre cada 15 minutos. Es uno de los 6 jobs programados del sistema, y existe porque aprendimos que los flujos de aprobación sin enforcement de timeout se convierten en colas de mensajes muertos.

La falla de los 200 mensajes

Nuestro daemon de investigación legal ejecuta 10 agentes especializados realizando sprints de investigación contra un backlog de 37 tareas. Temprano en el desarrollo, probamos una versión donde el orquestador posteaba el output de cada agente en un canal de Slack antes de pasarlo al siguiente agente en el pipeline.

La lógica era solida: los humanos deberian revisar outputs intermedios para detectar problemas de calidad temprano. En la práctica, el canal de revisión acumulo 200+ mensajes en dos días. Cada mensaje era un output de investigación de 500-2,000 palabras. Nadie los leía. El canal se convirtio en un muro de texto que la gente silencio el primer día.

Lo que paso después era predecible. El sistema produjo tres outputs con estadísticas fabricadas que llegaron a un documento de resumen. La “supervisión” humana habia estado corriendo por 48 horas y no detecto nada, porque los humanos dejaron de mirar después de la hora 4.

Reemplazamos la revisión por output con un sistema de scoring de calidad: 50+ patrones de detección de basura, scoring automatizado de contenido en escala 0-1, y un tope de 3 reintentos que bloquea tareas en lugar de regenerar indefinidamente. La revisión humana paso de “leer cada output” a “revisar tareas bloqueadas y reportes semanales de calidad.” La superficie de revisión bajo de 200+ mensajes por día a 3-5 items por semana. Los humanos realmente leen esos 3-5 items.

La lección: la supervisión humana se degrada en proporción directa a su volumen. Cada solicitud de revisión que no requiere genuinamente juicio humano hace más difícil que el humano se involucre con las que si lo requieren. La fatiga de alertas no es solo un problema de monitoreo. Es el modo de falla central de los sistemas de humano-en-el-loop mal disenados.

Disenando puntos de escalación

La pregunta no es “debería un humano estar involucrado?” La pregunta es “en que punto específico del flujo de trabajo el juicio humano agrega información que el agente no tiene?”

Para las respuestas de email de Penélope, ese punto es claro: el agente no puede evaluar completamente si un tono o fraseo particular va a caer bien con una persona específica. La calibración social humana es genuinamente superior aquí.

Para los outputs de investigación del daemon legal, la respuesta es diferente. Un revisor humano agrega poco valor leyendo un análisis de dimensionamiento de mercado que el agente produjo a partir de datos publicos. El agente es más rápido y más exhaustivo en síntesis. Donde el humano agrega valor es en los criterios de calidad: decidir si los patrones de detección de basura están atrapando las cosas correctas, revisar los umbrales de scoring, y evaluar tareas bloqueadas donde el agente explícitamente fallo.

Estamos desarrollando un principio a partir de esto: la escalación debería ocurrir en el punto de máximo apalancamiento humano, no en el punto de maxima comodidad humana. La mayoría de las personas se sienten más cómodas revisando cada output. Pero esa comodidad tiene como costo la calidad real de la supervisión.

Así mapea esto a nuestros sistemas:

Sistema	Acciones T1	Acciones T2	Acciones T3
Legal Daemon	Síntesis de investigación, consolidación de memoria, tracking de presupuesto	Resúmenes de sprint, alertas de calidad, notificaciones de tareas bloqueadas	Decisiones GO/NO-GO de kill criteria
Penélope	Monitoreo de email, investigación de invitados, parsing de calendario	Actualizaciones de etapa de pipeline, confirmaciones de agenda	Respuestas de email, invitaciones a reuniones
Sales Pipeline	Enriquecimiento de datos de prospectos, recolección de inteligencia competitiva	Actualizaciones de pipeline, creación de action items	Borradores de propuestas, discusiones de precios
Research Systems	Recolección de fuentes, indexación de citas	Borradores de análisis, reportes de verificación de fuentes	Aprobación de publicación

Observa el patrón. T1 es todo lo que toca estado interno. T2 es todo lo que toca flujos de trabajo compartidos. T3 es todo lo que toca relaciones externas o compromisos irreversibles. La clasificación se deriva del radio de impacto, y se mantiene consistente entre sistemas incluso cuando el dominio cambia completamente.

La separación Ulises/Penélope

Operamos dos agentes conectados a Slack: Penélope (agente personal, orientado al exterior) y Ulises (operaciones internas, gestión de pipeline, inteligencia cross-unidad). Comparten el mismo workspace de Slack pero tienen frameworks de autoridad completamente separados.

Penélope opera mayormente en T2 y T3. Sus acciones frecuentemente involucran comunicación externa, así que casi todo lo que hace es notificado o aprobado. Ulises opera mayormente en T1 y T2. Sus acciones son internas: actualizar trackers de pipeline, postear resúmenes de investigación, rutear información entre unidades de negocio. Rara vez necesita aprobación humana porque su radio de impacto esta contenido dentro de la organización.

Esta separación existe porque los niveles de autoridad deben reflejar el alcance de impacto del agente, no su sofisticación técnica. Ulises es posiblemente el sistema más complejo. Coordina entre 6 unidades de negocio, gestiona un CRM de Notion con 92+ prospectos y ejecuta flujos de inteligencia competitiva. Pero sus acciones no llegan fuera de la organización, así que opera con más autonomía que Penélope, cuyas acciones individuales son más simples pero aterrizan en la bandeja de entrada de alguien más.

Mezclar los dos en un solo agente con un solo framework de autoridad forzaria una elección: o Ulises obtiene demasiada autonomía de cara al exterior, o Penélope se frena con requisitos de aprobación en operaciones internas que no lo ameritan.

Detalles de implementación

Algunos específicos sobre como funciona el framework de autoridad en la práctica.

La clasificación ocurre en la definición del agente, no en el código. Cada agente tiene un archivo markdown especificando su rol, herramientas y nivel de autoridad por tipo de acción. Cuando incorporamos un nuevo cliente, el mapeo de autoridad es una de las primeras decisiones de diseño. Va al ARCHITECTURE.md del cliente antes de que se escriba cualquier código.

Las acciones T3 requieren payloads de aprobación estructurados. El agente no solo pregunta “puedo hacer esto?” Presenta: la acción propuesta, el razonamiento, el contexto relevante y las alternativas especificas que considero. Esto le da al humano suficiente información para tomar una decisión real en lugar de pattern-matching en “esto se ve bien.”

Cada nivel de autoridad tiene logging. Las acciones T1 se registran silenciosamente. Las acciones T2 se registran y notifican. Las acciones T3 se registran, notifican y bloquean. Pero los tres producen trails de auditoría. Si algo sale mal en T1, el log existe. Si una notificación T2 fue ignorada, la línea de tiempo es reconstruible. El logging es la red de seguridad. El nivel de autoridad es la restricción operativa.

Las asignaciones de nivel pueden cambiar. Cuando un agente ha ejecutado una acción T3 específica exitosamente 20+ veces con una tasa de aprobación del 100%, eso es evidencia de que la acción debería reclasificarse a T2. Cuando una acción T1 produce un error que causa impacto externo, se reclasifica a T2 o T3. El framework esta diseñado para evolucionar a medida que el sistema acumula historial operativo.

El problema del checkbox

La razón por la que la mayoría de los deployments de agentes de IA tratan la supervisión humana como un checkbox es que los compradores lo exigen. Equipos de procurement, departamentos de compliance y comites de riesgo quieren escuchar “un humano revisa cada output.” Esa frase aparece en RFPs. Aparece en evaluaciones de proveedores. Aparece en presentaciones de directorio sobre gobernanza de IA.

El problema es que “un humano revisa cada output” describe un sistema que no funciona. A 5 outputs por día, quiza. A 50, improbable. A 200, el humano esta aprobando automáticamente o ignorando. La supervisión existe en papel y falla en la práctica.

Niveles de autoridad disenados producen mejores resultados. Menos puntos de revisión, cada uno posicionado donde el juicio humano genuinamente cambia el resultado. Agentes que operan más rápido porque no esperan aprobaciones en acciones que no las necesitan. Humanos que se involucran con solicitudes de aprobación porque reciben 3 por día en lugar de 30.

Estamos probando esto en cada sistema que construimos. Los resultados tempranos confirman la tesis central: supervisión concentrada en puntos de decisión de alto impacto supera a la supervisión distribuida en todos los puntos de decisión. La primera produce revisión genuina. La segunda produce una ficción cómoda.

El agente prepara. El humano aprueba en exactamente el momento correcto. El agente ejecuta. Acertar ese paso del medio es la decisión de arquitectura que determina si el sistema realmente funciona.

Synaptic convierte empresas en organizaciones AI-native. Empezamos donde termina el demo. synaptic.so