Diseñando rutas de escalación para agentes bloqueados
Cómo diseñar rutas de escalación cuando los agentes de código se bloquean—identificando tipos de bloqueo, asignando respondedores, configurando timeouts y construyendo ciclos de retroalimentación.
Un agente de código bloqueado es cómputo desperdiciado y momentum perdido. Sin una ruta clara de escalación, los agentes bloqueados o giran indefinidamente o disparan alertas ruidosas que nadie se adueña. Un diseño efectivo de escalación empareja cada tipo de bloqueo con el respondedor humano correcto, aplica timeouts apropiados y crea ciclos de retroalimentación para que los mismos problemas dejen de recurrir.
Identificar tipos de bloqueo
No todos los bloqueos son iguales. Categorizarlos permite enrutar cada uno al respondedor correcto y establecer niveles de urgencia apropiados.
Bloqueos por dependencias
El agente necesita algo de otro equipo o servicio—una API que no está desplegada, una migración de base de datos que no se ha ejecutado, o una actualización de librería pendiente de revisión. Los bloqueos por dependencias suelen ser los más lentos de resolver porque cruzan fronteras entre equipos.
Bloqueos por permisos
El agente carece de acceso a un recurso que necesita—un repositorio, un vault de secretos, un entorno de staging o una API key de terceros. Los bloqueos por permisos generalmente se resuelven rápido una vez que la persona correcta es notificada, pero pueden quedar horas si la solicitud va a una cola genérica.
Bloqueos por ambigüedad
El agente no puede proceder porque la especificación de la tarea es poco clara, contradictoria o incompleta. Estos bloqueos requieren juicio humano—un product owner o tech lead debe clarificar la intención antes de que el agente pueda continuar.
Bloqueos por infraestructura
El entorno mismo tiene un problema—CI está caído, un contenedor falla al construirse, los tests fallan por límites de recursos, o una partición de red aísla al agente de servicios requeridos. Los bloqueos por infraestructura frecuentemente afectan a múltiples agentes simultáneamente.
Emparejar bloqueos con respondedores
Cada tipo de bloqueo debería mapearse a un rol o persona específica, documentado en una referencia única que el equipo pueda encontrar sin buscar.
Bloqueos por dependencias se enrutan al equipo dueño del servicio bloqueante. Si ese equipo usa Dailybot, publica la escalación en su canal con contexto para que puedan priorizar.
Bloqueos por permisos se enrutan al líder del equipo o administrador de seguridad que pueda otorgar acceso. Incluye el recurso específico y la razón del acceso para que el aprobador pueda actuar sin ida y vuelta.
Bloqueos por ambigüedad se enrutan al product owner, tech lead o quien escribió la especificación original. Incluye la interpretación del agente y la pregunta específica que no puede resolver.
Bloqueos por infraestructura se enrutan al equipo de plataforma o DevOps. Incluye logs de error, identificadores de entorno y si otros agentes también están afectados.
Configurar escalación basada en timeouts
Los timeouts previenen que los bloqueos queden silenciosos. El timeout correcto depende de la criticidad de la tarea y el tipo de bloqueo.
Establecer ventanas de timeout
Un marco de partida razonable:
- Tareas críticas (bloquean el sprint, relacionadas con producción): escalar después de 30 minutos
- Tareas estándar (trabajo de funcionalidades, refactorización): escalar después de 1-2 horas
- Tareas de baja prioridad (mejoras deseables, documentación): escalar después de 4 horas
Dentro de estas bandas, ajusta por tipo de bloqueo. Los bloqueos por permisos suelen tener rutas de resolución más rápidas que los de dependencias, así que podrías configurar un timeout más corto para permisos (30 minutos) y uno más largo para dependencias (2 horas) incluso al mismo nivel de prioridad.
Niveles de escalación
Diseña al menos dos niveles. El primer nivel notifica al respondedor designado vía DM o mención en canal. Si no hay respuesta dentro de una ventana adicional de timeout, el segundo nivel notifica a un grupo más amplio—un gerente, un canal de ops o una rotación de guardia.
Evita pasar de tres niveles. Si un bloqueo requiere tres escalaciones para recibir atención, el problema no es el sistema de escalación—es la cultura de respuesta.
Construir ciclos de retroalimentación
Escalación sin aprendizaje es solo apagar incendios. Cada bloqueo resuelto es data para prevenir el siguiente.
Documentación post-resolución
Después de resolver un bloqueo, el respondedor o el agente debería registrar: qué causó el bloqueo, cómo se resolvió, y si la solución es permanente o temporal. Estos datos alimentan una base de conocimiento que agentes y humanos pueden consultar.
Rastreo de recurrencia
Rastrea qué tipos de bloqueo recurren con más frecuencia. Si los bloqueos por permisos se activan tres veces al mes para el mismo recurso, invierte en un otorgamiento de permiso permanente en lugar de resolver cada uno individualmente. Si los bloqueos por ambigüedad se agrupan alrededor de un área de producto específica, las especificaciones de esa área necesitan mejora.
Aprendizaje del agente
Algunos bloqueos pueden prevenirse dándole a los agentes mejor contexto desde el inicio. Si un agente consistentemente se bloquea en el mismo tipo de configuración de entorno, agrega esa configuración al checklist de inicialización del agente. Si los bloqueos por ambigüedad surgen de la misma información faltante, incluye esa información en el template de tareas.
Diseñar el documento de escalación
Crea una referencia de una página que el equipo pueda consultar en treinta segundos:
- Tipo de bloqueo (dependencia, permiso, ambigüedad, infraestructura)
- Primer respondedor (rol o persona nombrada)
- Timeout hasta primera escalación (minutos)
- Segundo respondedor (rol o grupo)
- Timeout hasta segunda escalación (minutos)
- Método de notificación (DM, canal, pager)
Publica este documento en tu canal de ops, enlázalo desde la configuración de tus agentes, y revísalo trimestralmente. Cuando la estructura del equipo cambie—nuevas contrataciones, rotaciones de rol, divisiones de equipo—actualiza el documento de escalación la misma semana.
Hacer la escalación invisible
El mejor sistema de escalación es uno que rara vez se activa porque las causas subyacentes han sido sistemáticamente eliminadas. Usa los datos de escalación no como métrica de rendimiento sino como señal de dónde invertir en prevención. Con el tiempo, el objetivo no es escalación más rápida—es que se necesiten menos escalaciones desde el inicio.
FAQ
- ¿Cuáles son los principales tipos de bloqueos de agentes?
- Bloqueos por dependencias (esperando otro servicio o equipo), bloqueos por permisos (falta de acceso a un recurso), bloqueos por ambigüedad (requerimientos poco claros o especificaciones conflictivas), y bloqueos por infraestructura (fallos del entorno, agotamiento de recursos).
- ¿Cómo se deben configurar los timeouts de escalación?
- Establecer timeouts según la criticidad de la tarea y el tipo de bloqueo. Las tareas críticas podrían escalar después de 30 minutos, mientras que el trabajo de menor prioridad tolera una o dos horas. Cada tipo de bloqueo puede tener su propio timeout según la velocidad de resolución esperada.
- ¿Cómo los ciclos de retroalimentación previenen escalaciones repetidas?
- Después de resolver un bloqueo, documentar la causa raíz y la solución. Si el mismo tipo de bloqueo recurre tres o más veces, invertir en una solución sistémica—actualizar permisos, mejorar especificaciones o agregar verificaciones de entorno—para que los agentes dejen de toparse con la misma pared.