Herramienta de trabajo para operaciones y agencias
Un asistente de operaciones que puede pausarse y reanudarse
De una solicitud interna a una tarea aprobada: conservar el estado, controlar los permisos y comprobar qué ocurrió antes de repetir una acción.
Por Sergio Sallavera, 8 de septiembre de 2026. Versión 1.0
Demostración interactiva con ejemplos editables
Prueba una interrupción y su recuperación
Aprueba una tarea y pulsa «Simular respuesta perdida». Después recarga esta pestaña y reconcilia: el destino de prueba debe conservar una sola tarea.
El destino es un registro simulado en esta pestaña. El estado se conserva en sessionStorage si está disponible; puedes borrarlo con «Reiniciar ejemplo». No se conecta a herramientas ni demuestra persistencia de servidor, concurrencia entre procesos o garantías de una API real.
El proceso que vamos a resolver
Una solicitud llega por un formulario interno. El asistente comprueba si tiene contexto suficiente, propone una tarea y espera la aprobación del responsable. Solo entonces crea esa tarea en la herramienta del equipo. Si el proceso se interrumpe, debe poder continuar sin perder la decisión ni crear otra tarea por error.
Es útil para responsables de operaciones y agencias con peticiones dispersas, traspasos manuales y dudas sobre qué se ha ejecutado. El primer piloto se limita a un tipo de solicitud y un destino.
Alcance: diseño de referencia basado en patrones de colas, estados, permisos y recuperación de mi entorno propio de agentes. Esta adaptación a solicitudes internas está preparada para probarse; no se presenta como una implantación de cliente ni como software listo para conectar.
Arquitectura mínima
- Registrar la solicitud. Guardar identificador de origen, contenido y versión en un registro persistente. Si vuelve a llegar el mismo evento, recuperar su expediente.
- Preparar la tarea. La IA propone título, descripción y dudas a partir de las fuentes autorizadas. Las reglas comprueban campos y destino; una persona resuelve la información ausente.
- Aprobar una versión. Mostrar al responsable el contenido exacto, el destino y la acción. Registrar quién aprueba, hasta cuándo y sobre qué versión.
- Ejecutar una sola intención. Un ejecutor reclama la tarea de forma atómica, vuelve a comprobar la aprobación y registra la intención antes de llamar a la herramienta.
- Confirmar o reconciliar. Guardar el identificador recibido del destino. Si hay un corte y no sabemos si se creó, consultar el destino antes de decidir si procede reintentar.
Para empezar basta un formulario, una base de datos, un proceso ejecutor y una llamada al modelo para preparar el texto. El registro conserva estado, versiones, intentos, aprobaciones y referencias al destino. La memoria de una conversación no sustituye ese registro.
Estados y recuperación
Recibida → Falta contexto / Pendiente de aprobación Pendiente de aprobación → Aprobada → En ejecución → Completada En ejecución → Resultado incierto → Reconciliación Reconciliación → Completada / Reintento autorizado / Pausada Cambio de contenido o aprobación caducada → Pendiente de aprobación
Una pausa conserva el expediente y el motivo. Al reanudar, el sistema revisa la versión, la vigencia de la aprobación y los intentos anteriores. Un estado «en ejecución» tras un reinicio exige reconciliación, no una segunda llamada automática.
La clave de idempotencia identifica una misma intención, no cada intento. Si el destino la soporta, se reutiliza en los reintentos. Si no la soporta ni permite comprobar con fiabilidad el resultado, se pausa y se solicita revisión humana. Este diseño no promete ejecución «exactamente una vez» en cualquier API.
Quién puede hacer qué
Las instrucciones que aparezcan en una solicitud se tratan como contenido. No pueden cambiar la lista de herramientas o destinos autorizados. En el piloto, usar un espacio de prueba y limitar la integración a crear tareas; enviar mensajes o modificar otros sistemas requiere otro alcance.
Material para preparar el piloto
El contrato de tarea define campos, reglas de aprobación y protocolo de recuperación. El expediente de ejemplo (JSON) muestra una tarea pendiente de aprobación, sin ejecución ni recibo inventados.
Los seis escenarios de prueba (CSV) cubren duplicados, caducidad, cambios, respuesta perdida, reinicio y dos ejecutores concurrentes. Son situaciones diseñadas para validar controles: el resultado observado queda vacío y ninguna figura como superada.
Antes de conectar herramientas, elegir una solicitud real saneada, acordar quién puede aprobar y comprobar si el destino ofrece idempotencia o consulta por referencia. Ejecutar los fallos en un entorno de prueba y conservar las respuestas.
Cómo decidir si merece operarse
Medir solicitudes completadas, duplicados observados en el destino, pausas justificadas, acciones sin aprobación válida y tiempo humano para recuperar incidencias. Registrar también el trabajo que tuvo que resolver una persona.
Una acción no autorizada o un duplicado bloquean el avance hasta corregir y repetir la prueba. El tiempo aceptable de resolución se acuerda con el equipo antes del piloto. Aquí no se atribuyen ahorros ni resultados a un sistema todavía por validar.
Experiencia y referencias
El caso de mi laboratorio de agentes (PDF) recoge trabajo propio con OpenClaw y Hermes, colas, controles y recuperación. Esta guía convierte esos patrones en un proceso acotado para operaciones.
La documentación de persistencia de LangGraph sirve como referencia sobre conservación de estado; la de revisión humana de LangChain, sobre interrupciones antes de acciones. Son referencias conceptuales: el piloto no exige estos frameworks.
¿Qué solicitud se atasca en tu equipo?
Podemos recorrer una petición de principio a fin, localizar dónde se pierde el estado y diseñar un piloto con una única acción aprobable.