Transferencia de agentes de IA: controla las sesiones activas durante la noche

Una transferencia de un agente de IA falla cuando el ingeniero saliente transmite una historia en lugar de la custodia. «El agente sigue trabajando en el despliegue» no le dice casi nada a la siguiente persona. Necesita saber qué proceso conserva la autoridad, a qué puede acceder, qué solicitud espera a un humano, dónde está la evidencia y cómo detener o recuperar el trabajo.

La parte incómoda es que un agente puede actuar mientras nadie observa el terminal. Puede tener una conexión SSH activa, una tarea persistente en segundo plano, un token en su entorno, un aviso de aprobación esperando en un portátil o un cambio remoto parcial que solo será visible más tarde. Una buena transferencia convierte todo eso en un estado operativo acotado. Una mala transfiere incertidumbre y la llama continuidad.

Una transferencia necesita un registro de custodia, no un resumen del chat

Una transferencia útil registra por separado la autoridad y el estado, porque fallan de maneras distintas. El estado indica qué ha hecho y qué planea hacer el agente. La autoridad indica qué puede seguir haciendo. Los equipos suelen documentar lo primero y omitir lo segundo. Así es como una continuación que parece inofensiva se convierte en una escritura en producción sin revisar.

Escribe el registro mientras el ingeniero saliente todavía puede inspeccionar la máquina y explicar sus decisiones. No lo reconstruyas de memoria después de que una alerta despierte a alguien. Un documento breve con identificadores exactos vale más que una narración larga llena de confianza.

Para cada ejecución activa, registra estos datos:

• El ID del proceso del agente, el ID de sesión, el directorio de trabajo y la hora de inicio.
• El responsable humano que deja el turno, el que lo asume y la hora en que cambia la responsabilidad.
• La tarea prevista, la última acción externa completada y la siguiente acción externa propuesta.
• Cada objetivo accesible, como un alias de host, una URL base de API, un repositorio, un ticket o un entorno de despliegue.
• El comando para detener, el comando de recuperación y la ubicación de la evidencia.

No escribas «tiene acceso a staging» cuando puedes escribir «el proceso 4182 puede llamar a la API de despliegue de staging mediante la sesión aprobada S-204». Las etiquetas generales ocultan el detalle que determina si el sucesor puede continuar de forma segura.

El registro de custodia también necesita una disposición clara para cada ejecución: continuar, pausar, cancelar o inspeccionar antes de actuar. «Supervisar» no es una disposición. Obliga al siguiente ingeniero a deducir si tiene permiso para intervenir.

La transferencia solo está completa cuando el ingeniero entrante confirma el registro y puede encontrar el proceso activo por sí mismo. Enviar un mensaje a un canal lleno es entrega, no transferencia. Si nadie acepta la custodia, el ingeniero saliente debe pausar o revocar la autoridad externa cuando el trabajo lo permita.

Encuentra la autoridad activa antes de cambiar al responsable

No puedes transferir el control de una sesión que no has localizado. Empieza por el árbol de procesos local y después inspecciona las conexiones, la exposición del entorno y los trabajos creados fuera del terminal inmediato. La interfaz del agente puede indicar que una tarea ha terminado mientras un proceso hijo, una ventana de un multiplexor de shell o una conexión maestra SSH siguen activos.

En macOS o Linux, empieza con comandos sencillos y guarda su salida en la evidencia de la transferencia. Sustituye los identificadores de ejemplo por el proceso o la cuenta reales del agente.

ps -axo pid,ppid,user,lstart,command | grep -E '[a]gent|[c]laude|[m]cp'
pgrep -P 4182 -alf
lsof -nP -p 4182

El primer comando produce una fila de proceso con este formato:

4182  901 alex  Tue Mar 18 22:14:07 2025  agent-runner --task deploy-api

El segundo muestra los procesos hijos. El tercero muestra los archivos abiertos y los extremos de red. Busca shells heredados, sockets Unix abiertos, conexiones TCP, archivos de credenciales locales y tuberías hacia asistentes de aprobación. No pegues en un ticket la salida de comandos que contenga secretos. Consérvala en el registro de incidentes aprobado o redacta el valor sensible, manteniendo la ruta del archivo y los detalles de conexión.

SSH requiere una inspección independiente porque su modelo de conexión puede sobrevivir a un solo comando. El manual de ssh_config de OpenSSH indica que ControlPersist puede mantener abierta una conexión maestra después de que termine el cliente inicial. Ese comportamiento ahorra tiempo en comandos repetidos. Durante una transferencia también significa que «el comando terminó» no demuestra que el acceso remoto haya finalizado.

Comprueba los sockets maestros y los procesos de reenvío:

ps -axo pid,ppid,command | grep '[s]sh'
find ~/.ssh -type s -name '*control*' -print
lsof -nP -iTCP -sTCP:ESTABLISHED | grep '[s]sh'

Después formula una pregunta más importante que «¿está conectado?»: ¿qué sigue ejecutando el lado remoto? Una compilación remota puede continuar después de que desaparezca el cliente local. Un comando de despliegue puede haber aplicado un cambio y haber fallado antes de informar del siguiente. Captura el identificador del trabajo remoto, el registro del despliegue o el estado del servicio antes de decidir si reanudarlo.

No equipares un puerto abierto con actividad maliciosa. Considera todo canal abierto sin explicación como una autoridad no resuelta. El ingeniero entrante debe entenderlo, cerrarlo o escalarlo.

Las aprobaciones pendientes necesitan un destino y una caducidad

Una aprobación pendiente es una acción propuesta, no una reserva hecha por el ingeniero saliente. La persona que asume el turno nunca debería heredar un aviso de aprobación acompañado solo de un mensaje como «haz clic aquí si aparece». Esa frase le pide aprobar una decisión sin contexto.

Añade cinco datos a cada solicitud pendiente:

1. La acción exacta, incluido el método y el objetivo. «Actualizar el servicio» no basta. «Hacer POST al endpoint de despliegue de production-api» ofrece un punto de partida.
2. El motivo de la acción y la condición que la hizo necesaria.
3. El resultado esperado y la evidencia observable que lo confirma.
4. El plazo tras el cual la solicitud debe caducar y volver a generarse.
5. La persona identificada que puede aprobarla o rechazarla.

Una aprobación sin estos datos debe caducar. Volver a emitir una solicitud cuesta menos que recuperarse de una escritura a ciegas. Esta regla puede parecer excesiva durante un turno tranquilo. Resulta evidente después de que una tarjeta de aprobación sobrevive al bloqueo de un portátil, una reconexión y un cambio en el alcance del incidente.

No uses una transferencia para ampliar la autoridad de aprobación. Si el ingeniero saliente podía aprobar un cambio en staging, eso no autoriza al entrante a aprobar su versión para producción. El alcance puede haber cambiado mientras la solicitud esperaba. Vuelve a comprobar el objetivo, la carga útil y el estado actual del incidente antes de que actúe un humano.

También hay un problema de tiempo. Si una herramienta puede solicitar una acción mucho después de que un agente haya creado la petición, incluye la caducidad en el diseño de la solicitud. Una aprobación obsoleta puede actuar sobre un sistema que se ha recuperado, ha hecho failover o ha sido modificado manualmente. El aviso puede describir una operación técnicamente válida que ya no sea la decisión operativa adecuada.

Prefiero una nota de aprobación breve a adjuntar una transcripción interminable. El siguiente ingeniero debería poder responder en menos de un minuto a tres preguntas: ¿qué ocurrirá?, ¿dónde ocurrirá? y ¿por qué sigue siendo necesario ahora? Si no puede, debe rechazarla y pedir al agente que inspeccione el estado actual antes de proponer otra acción.

La propiedad de la sesión y la de los secretos deben mantenerse separadas

La persona que supervisa una sesión no necesita una copia de cada credencial que la sesión pueda utilizar. Confundir ambos papeles crea un problema conocido y costoso: alguien exporta un token en el perfil del shell «solo para la transferencia» y el token sobrevive al incidente, al rol del ingeniero y al recuerdo de por qué existía.

Una transferencia correcta cambia quién puede supervisar, aprobar, pausar o revocar una acción. No entrega tokens de API, claves privadas SSH, cookies del navegador ni credenciales temporales de la nube por chat, notas o un prompt del agente. El sucesor recibe la referencia de la sesión y la evidencia necesaria para operar con ella. El ejecutor de la acción conserva el secreto.

Esta distinción importa especialmente cuando el ingeniero saliente deja un terminal abierto. Un shell desbloqueado no es un mecanismo legítimo de transferencia. Entrega al siguiente una colección de estado heredado: variables exportadas, historial de comandos, credenciales almacenadas en caché, funciones del shell, reenvíos de puertos y comandos a medio terminar. Parte de ese estado puede ser útil. Nada de ello constituye una custodia clara.

Usa uno de estos dos enfoques:

• Continúa la sesión existente solo cuando la operación activa esté comprendida, el alcance sea limitado, el ingeniero entrante la haya aceptado y detenerla produjera un resultado operativo peor.
• Detén la sesión anterior y lanza una nueva bajo el ingeniero entrante cuando la tarea sea investigativa, la autoridad sea amplia, el historial del prompt sea importante o el agente haya quedado inactivo.

El segundo enfoque suele ser más seguro de lo que los equipos admiten. La gente se resiste porque teme perder contexto. Conserva el contexto en el paquete de transferencia, no dentro de un proceso que nadie ha inspeccionado. Un proceso nuevo tiene un límite de aprobación limpio y deja clara la responsabilidad del nuevo propietario.

En los equipos que usan Sallyport, el agente puede realizar acciones HTTP y SSH sin recibir los secretos subyacentes, de modo que un cambio de turno puede transferir la supervisión en lugar del material de credenciales. Su puerta de la bóveda deniega las acciones mientras está bloqueada, lo que ofrece al ingeniero entrante un punto de pausa deliberado antes de autorizar cualquier continuación.

No confundas la separación con inmunidad. Si un sucesor puede aprobar acciones en una sesión, sigue necesitando la misma disciplina con el alcance y la evidencia. Mantener un secreto fuera de un prompt evita una clase de fallos. No convierte una solicitud insegura en segura.

La recuperación debe comenzar por la contención, no por la continuación

Cuando una ejecución del agente queda en silencio o el ingeniero saliente deja de estar disponible, el entrante debe impedir primero nuevos cambios externos. No debería pasar diez minutos intentando recuperar el contexto exacto de la conversación mientras un proceso en segundo plano sigue escribiendo.

La recuperación tiene dos líneas: conservar la evidencia y establecer el estado actual. Ejecútalas en ese orden cuando exista alguna posibilidad de que el proceso o el host desaparezcan. Copia los identificadores de sesión, la salida del terminal, las definiciones de tareas, las aprobaciones, los listados de procesos y las referencias de auditoría en el registro del incidente. Después detén, revoca o bloquea la ruta de acción según los controles habituales del sistema.

Tras contener la situación, inspecciona el sistema objetivo. La afirmación del agente de que una llamada falló pesa menos que un registro del lado objetivo. Un tiempo de espera HTTP puede significar que el servidor rechazó la solicitud, la aceptó una vez o la aceptó y perdió la respuesta. Reintentar sin un mecanismo de idempotencia puede duplicar la acción.

Usa la evidencia natural del objetivo:

• Para una escritura en una API, inspecciona el objeto, el registro del cambio, el ID de solicitud o el registro de idempotencia.
• Para trabajo mediante SSH, inspecciona el proceso remoto, el estado del servicio, el historial del gestor de paquetes o el marcador de despliegue.
• Para un cambio de código, inspecciona por separado el diff del repositorio, el commit, la ejecución de CI y el estado del despliegue.
• Para una operación en cola, inspecciona la cola y el estado del worker antes de enviar otro trabajo.

La diferencia entre reintentar una solicitud y recuperar una operación importa. Reintentar repite un intento de transporte. Recuperar establece si cambió el estado subyacente y después elige la siguiente acción. Los equipos mezclan ambos términos cuando un agente presenta un tiempo de espera como una invitación a pulsar «ejecutar de nuevo». No lo es.

Una nota de recuperación debe nombrar la última observación fiable, no lo último que dijo el agente. Por ejemplo: «El agente agotó el tiempo de espera después de solicitar el despliegue D42. El servicio de despliegue registra D42 como activo en dos instancias. Las nuevas solicitudes están pausadas desde las 02:17». Eso ofrece al siguiente operador un punto factual desde el que continuar.

Si no puedes establecer el estado, eleva el incidente y mantén restringida la autoridad. Un despliegue detenido suele ser tolerable. Una migración de esquema duplicada, un pago repetido o un borrado accidental en producción pueden no serlo.

Contrasta el registro con la evidencia antes de aceptarlo

Un documento de transferencia es la interpretación de un operador. Un registro de auditoría es la evidencia de lo que registró el sistema. Necesitas ambos, pero no los trates como equivalentes.

Antes de que un ingeniero entrante acepte una sesión activa, compara el registro de custodia con evidencia que el saliente no haya editado manualmente. Comprueba las horas de inicio y fin de la sesión, los nombres de los objetivos, la secuencia de acciones y la disposición indicada para cada aprobación. Investiga las discrepancias antes de que alguien continúe la ejecución.

Una cadena de hashes ayuda porque hace detectables la eliminación y la reordenación de registros. No demuestra la intención, la corrección ni la conveniencia de una aprobación. Conviene expresar ese límite con claridad. La continuidad criptográfica responde a «¿la secuencia registrada permaneció intacta?». No responde a «¿deberíamos haber enviado esa solicitud?».

Con Sallyport, los equipos pueden verificar sin conexión la cadena de auditoría cifrada con este comando:

sp audit verify

Guarda el resultado del verificador junto al registro de transferencia, con la hora a la que lo ejecutaste y el intervalo de registros revisado. La verificación no necesita acceso a la bóveda, algo útil cuando un ingeniero entrante necesita comprobar la continuidad antes de desbloquear cualquier autoridad de acción.

No conviertas en costumbre copiar grandes fragmentos de auditoría en el chat. Los registros suelen contener metadatos operativos sensibles aunque no incluyan secretos. Guarda una referencia al registro aprobado, cita solo la pequeña parte necesaria para explicar la transferencia y proporciona al ingeniero entrante acceso mediante la ruta normal del incidente.

La revisión de auditoría también detecta un problema común pero serio: un ingeniero puede haber iniciado dos agentes con tareas parecidas y olvidarse de uno. Una lista de procesos muestra lo que existe ahora. La secuencia de auditoría muestra lo que cada ejecución ya intentó. Lee ambas antes de aceptar la responsabilidad.

Un paquete de transferencia debe funcionar aunque nadie recuerde el incidente

Un paquete útil permite que un ingeniero que estaba dormido hace cinco minutos tome una decisión segura. No debería obligarlo a recorrer cientos de mensajes de chat ni a volver a abrir una transcripción de prompt sin límites. Mantén el paquete junto al registro del incidente, usa siempre el mismo orden de campos y actualízalo cuando cambie la autoridad.

Usa esta plantilla como punto de partida:

Incidente o cambio:
Responsable saliente / responsable entrante / hora de transferencia:

Ejecución del agente:
- ID de sesión y PID local:
- Espacio de trabajo y referencia de la tarea:
- Estado actual: continuar | pausar | cancelar | inspeccionar
- Última acción externa confirmada:
- Siguiente acción propuesta:

Autoridad:
- Objetivos accesibles para esta ejecución:
- Estado y caducidad de la aprobación:
- Método para revocar o detener la sesión:
- Las credenciales siguen en poder de:

Evidencia:
- Referencia del registro de actividad o auditoría:
- Evidencia del lado objetivo comprobada:
- Captura de procesos y conexiones:

Recuperación:
- Estado parcial conocido:
- Primera acción segura para el responsable entrante:
- Responsable y condición de escalada:

La línea «primera acción segura» merece su espacio. Escribe una acción que recopile estado sin aumentar el impacto, como comprobar un registro de despliegue, leer la profundidad de una cola o comparar la versión de un servicio. No escribas «continuar la investigación». Esa frase no tiene ningún límite operativo.

El paquete también debe indicar qué ha cambiado desde que comenzó el agente. Tal vez se inició un bloqueo de versiones, una réplica de base de datos empezó a quedarse atrás, un cliente informó de un síntoma o un ingeniero distinto hizo una corrección manual. Los agentes actúan según el contexto que reciben. El humano entrante necesita el contexto que apareció después de comenzar el prompt.

Mantén un lenguaje factual. «El agente parece confundido» indica al sucesor que desconfíe, pero no le da nada que verificar. «El agente propuso el mismo POST después de que el servicio mostrara el ID de solicitud 7f3 como aceptado» identifica un riesgo de duplicación y sugiere la comprobación correcta.

Los cambios de turno crean una brecha de autorización si ignoras el tiempo

La brecha aparece cuando el ingeniero saliente ya se ha desvinculado mentalmente del turno, pero su sesión todavía puede actuar. Se amplía cuando el entrante aún no ha aceptado la responsabilidad, no puede ver el estado de la aprobación o supone que el agente solo está leyendo datos. Durante esa brecha, el proceso tiene autoridad sin que haya un humano atento responsable de usarla.

Un fallo habitual ocurre así. Al final del turno, un ingeniero pide a un agente que repare un despliegue fallido. El agente abre una conexión SSH, edita un archivo de configuración y espera aprobación para reiniciar un servicio. El ingeniero escribe «reinicio pendiente, debería estar bien» en el chat y se desconecta.

El siguiente ingeniero ve el prompt una hora después. Durante esa hora, una mitigación manual cambió la topología del servicio. El reinicio pendiente ahora afecta a un nodo que recibe tráfico y que el ingeniero anterior desconocía. La aprobación todavía describe un comando válido, pero la situación que lo justificaba ha cambiado.

Este fallo no requiere una herramienta comprometida ni una persona descuidada. Surge de tratar la autorización como permanente mientras el contexto operativo cambia. Una aprobación debe estar vinculada a una solicitud de corta duración y a un responsable actual. Una sesión debe perder autoridad cuando no se cumple ninguna de esas condiciones.

Establece un plazo de transferencia explícito. Si el ingeniero entrante no ha aceptado la sesión para entonces, pausa el agente e invalida las aprobaciones pendientes. Si una tarea no puede pausarse sin riesgo, deja constancia de ello en el runbook antes del incidente, define quién puede aceptarla y establece una ruta directa de escalada. No descubras la excepción durante un cambio de turno.

A veces los equipos mantienen todas las sesiones activas porque reiniciar agentes cuesta tiempo. La recomendación resulta popular porque conserva el contexto local y evita volver a explicar la tarea. Es incorrecta cuando la autoridad es amplia o incierta. Los pocos minutos de lanzar una sesión limpia cuestan poco frente a intentar explicar por qué un proceso abandonado modificó un sistema después de que su responsable se desconectara.

El ingeniero entrante debe aceptar la responsabilidad en un orden fijo

El ingeniero entrante necesita una secuencia de aceptación repetible porque las transferencias ocurren cuando la atención está fragmentada. No es burocracia para un día tranquilo. Evita que quien se despierta por una alerta apruebe una acción antes de saber qué autoridad sigue activa.

Sigue este orden:

1. Lee el estado actual del incidente y el registro de custodia, y confirma el ingeniero saliente y la hora de transferencia.
2. Localiza el proceso o la sesión indicados e inspecciona las conexiones activas, los procesos hijos y las solicitudes pendientes.
3. Compara el registro con la evidencia de auditoría y el estado del lado objetivo.
4. Elige continuar, pausar o cancelar. Rechaza toda aprobación pendiente que ya no tenga una justificación clara y vigente.
5. Registra la aceptación, la primera acción segura y la hora de la siguiente revisión.

El orden importa. Si apruebas primero e inspeccionas después, ya has aceptado el mayor riesgo. Si inspeccionas el objetivo antes de conservar el registro de la sesión, puedes perder evidencia cuando termine un proceso o se reinicie una máquina. Una secuencia fija protege frente al impulso natural de «ponerlo en marcha».

El ingeniero saliente también tiene una obligación fija: seguir disponible hasta que el sucesor acepte la custodia o la sesión se detenga. Si la cobertura termina antes, escala el asunto en lugar de dejar silenciosamente un agente en ejecución. Un calendario de guardias asigna una persona, no una esperanza vaga de que alguien vea un prompt.

Integra estas reglas en tu práctica de incidentes antes de que un fallo nocturno te obligue a hacerlo. Empieza añadiendo los campos de custodia a una nota de transferencia existente y exige una disposición para cada ejecución del agente. La primera vez que encuentres una conexión SSH sin explicación o una aprobación sin responsable, habrás encontrado una brecha real y no una teórica.