Un agente siempre activo también necesita una condición para detenerse

El 29 de septiembre, OpenAI presentó dots: agentes que pueden seguir trabajando en sus propios ordenadores en la nube. El anuncio concreta una pregunta de diseño: si un agente continúa después de que termine la conversación, ¿cómo sabe que el encargo ya no está vigente? [1]

Pensemos en un equipo de contenidos que pide a un agente preparar materiales para un lanzamiento. Después se aplaza el lanzamiento, cambia el vídeo original o la persona responsable abandona el proyecto. Seguir con diligencia las instrucciones anteriores podría producir un resultado equivocado. Sostenemos que un encargo recurrente necesita un ciclo de vida: un objetivo vigente, un alcance definido, una persona responsable y condiciones para detenerse. Son recomendaciones para desplegar agentes de este tipo, no funciones de dots que hayamos comprobado.

OpenAI distingue la investigación proactiva de dots de las acciones posteriores. Su explicación de seguridad indica que la investigación en segundo plano utiliza herramientas de solo lectura; las acciones posteriores siguen sujetas a las reglas y comprobaciones habituales. Este modo concreto de investigación no debe confundirse con todas las tareas autorizadas que continúan en segundo plano. [2]

Para un equipo, la decisión de diseño correspondiente es separar detectar, preparar y publicar. La llegada de un nuevo archivo de entrevista puede justificar la preparación de un borrador de vídeo, pero por sí sola no autoriza a publicarlo en una cuenta de la marca. El encargo debe precisar qué materiales se pueden usar, adónde irá el resultado, de quién se necesita aprobación si procede y qué cambios invalidan esa aprobación. Si el usuario ya autorizó una acción recurrente y acotada, debe ejecutarse dentro de ese alcance; no se trata de pedir permiso de nuevo en cada paso inocuo.

La documentación de MCP Events de OpenAI describe el procesamiento asíncrono, los reintentos y la posible llegada de eventos fuera de orden. Pide conservar un identificador de evento estable entre reintentos y utilizar herramientas de escritura idempotentes. Por tanto, acusar recibo de una entrega y completar el trabajo solicitado son hitos distintos. Se trata de reglas de integración documentadas, no de pruebas de que hayamos evaluado un plugin concreto. [3]

En un flujo de vídeo, recibir dos veces el aviso de una carga no debería generar dos publicaciones. Tampoco debería un comentario de revisión antiguo sobrescribir una versión posterior ya aprobada. Una solución práctica es registrar juntos el elemento de origen, su versión y la acción prevista, y comprobar esa identidad antes de repetir una escritura. Quien supervisa el trabajo debe poder distinguir entre recibido, en preparación, pendiente de decisión, completado y detenido. Una etiqueta genérica de «en ejecución» oculta justo la diferencia que necesita para decidir si debe intervenir.

La misma guía de MCP Events exige gestionar la caducidad de las suscripciones a eventos y detener la entrega cuando se revoca el acceso. La duración de la suscripción regula la entrega; por sí sola no determina cuándo ha caducado un objetivo del negocio. Ese segundo límite aún debe diseñarse. [3]

Proponemos registrar una persona responsable, una fecha de revisión, el alcance permitido y las condiciones de parada de cada encargo recurrente. El fin de una campaña, la retirada de una fuente o la salida de quien la supervisa pueden desencadenar una revisión. Antes de efectuar un cambio externo, hay que comprobar que el encargo y la versión pertinente de la fuente siguen vigentes. Si el agente delega, el trabajo delegado debe heredar los límites aplicables; también conviene probar qué ocurre cuando se detiene la tarea principal. Una orden de parada debe producir un resultado observable, incluidos los pasos ya completados o todavía en curso.

Las preguntas frecuentes de dots de OpenAI indican que desconectar un plugin impide nuevos accesos, pero no borra el contexto que ya se haya conservado. También distinguen entre eliminar un dot y eliminar archivos o conversaciones guardados por separado. Son hechos específicos del producto; la lección operativa más amplia es precisar qué estado cambia. [4]

Cancelar un proyecto puede significar detener el trabajo futuro, revocar una conexión, archivar el material de trabajo o eliminar el contexto conservado. Son resultados distintos. Quien opera el sistema debe saber cuáles se han producido y cuáles requieren otra acción. No hay que mostrar «cancelado» como si eso también retirase un mensaje ya enviado. Tampoco se debe suponer que quitar una integración elimina todas las copias del material obtenido antes. Defina el resultado deseado y compruébelo en los sistemas que conservan el estado pertinente.

Una primera prueba útil es un flujo limitado y reversible: vigilar una fuente aprobada y preparar un borrador para una persona revisora identificada. Después, provoque a propósito un evento duplicado, actualice la fuente mientras se prepara el borrador, retire el acceso, cancele la tarea principal y agote un presupuesto de tiempo o coste elegido. Compruebe si hay cambios duplicados, borradores obsoletos o trabajos delegados que siguen activos, y si se explica con claridad por qué se detuvo el progreso. El presupuesto debe imponerse en el sistema de ejecución real: una frase en una instrucción no demuestra que exista un límite estricto.

Hay un equilibrio real: pedir demasiadas confirmaciones puede convertir al agente en otra bandeja de entrada que gestionar. Conviene definir expresamente la autoridad para las acciones rutinarias y reservar la intervención para un cambio de alcance, un paso importante o una condición sin resolver. La documentación pública no demuestra con qué fiabilidad gestiona cada integración estos casos, y no hemos hecho una evaluación en producción. Este lanzamiento hace oportuna una pregunta de evaluación: ¿puede el sistema detener el trabajo que ya no debe continuar con la misma fiabilidad con que inicia trabajo útil?