Un agente de IA siempre activo es un agente que puede seguir siendo responsable de un trabajo cuando no hay ninguna conversación abierta. Puede conservar el estado de un encargo, esperar a que pase el tiempo o cambie el mundo exterior, reanudar en un entorno adecuado y devolver el control cuando la siguiente decisión corresponde a una persona.
«Siempre activo» no significa que un modelo de lenguaje grande piense sin parar. No significa que un ordenador tenga que consumir recursos a plena potencia día y noche. Y no debería significar que un agente envíe mensajes constantemente o actúe sin permiso. La promesa útil es la continuidad: la responsabilidad sigue viva aunque la mayor parte del sistema esté dormida.
Programar un prompt o guardar el historial del chat no resuelve las preguntas prácticas: ¿qué sobrevive a un reinicio?, ¿qué despierta al agente?, ¿dónde sigue trabajando?, ¿cómo puede detenerlo un usuario? Las respuestas a esas preguntas convierten «24/7» de un eslogan en una propiedad del sistema.
Estar siempre activo trata de continuidad, no de tiempo de actividad
El tiempo de actividad describe si un proceso se está ejecutando. La continuidad describe si el trabajo todavía tiene un responsable y un siguiente paso válido.
Imagina que pides a un agente que esté pendiente de un contrato firmado, que actualice una lista de comprobación de lanzamiento cuando llegue y que te prepare la siguiente decisión. El contrato puede volver mañana o la semana que viene. Durante esa espera no está ocurriendo ningún razonamiento útil. El agente no necesita un chat abierto, una sesión del modelo en caliente ni un navegador que actualice la bandeja de entrada cada minuto. Necesita un registro duradero de la responsabilidad y una forma fiable de que el evento relevante vuelva a ponerla en marcha.
La diferencia salta a la vista cuando algo falla. Un proceso puede ejecutarse sin parar y aun así perder el encargo tras un fallo. Otro sistema puede escalar a cero durante horas, reconstruir su estado y reanudarse correctamente cuando llega un evento. El segundo sistema está siempre activo en un sentido más significativo.
Por eso la infraestructura de agentes duraderos separa la espera del cómputo. La actual Durable Extension de Agent Framework de Microsoft, por ejemplo, describe agentes que conservan el estado entre ejecuciones de workers, se pausan sin consumir cómputo ni tokens del modelo y se reanudan a partir de eventos externos. La guía de Google sobre agentes de larga duración con reanudación guiada por eventos muestra el mismo principio con checkpoints persistentes y webhooks. Los detalles de implementación cambian, pero la lección de arquitectura se mantiene: una responsabilidad siempre activa no requiere un modelo que esté siempre en ejecución.
Las seis condiciones detrás de un agente siempre activo creíble
No existe una única función que haga que un agente esté siempre activo. La propiedad surge cuando seis condiciones funcionan juntas.
Una identidad continua se hace cargo de la responsabilidad
El sistema necesita una identidad estable a la que puedan asociarse mensajes, eventos, permisos, tareas y expectativas del usuario. Si cada conversación crea un agente sin relación con los demás y sin contexto operativo compartido, no hay nadie a quien los eventos posteriores puedan despertar ni nadie que responda de continuar el trabajo.
Una identidad continua no exige una memoria ilimitada. Significa que el usuario puede volver al mismo agente y que el sistema sabe qué responsabilidades le pertenecen. Los datos personales, el historial de conversaciones y el estado de las tareas pueden seguir teniendo duraciones y controles distintos.
El estado de trabajo sobrevive al tiempo inactivo
Un encargo tiene que conservar algo más que su prompt inicial. El estado necesario para reanudar puede incluir el resultado buscado, las acciones completadas, los materiales de trabajo, las restricciones, el bloqueo actual y el siguiente paso válido.
Ese estado debería ser lo bastante duradero como para sobrevivir a las interrupciones habituales: un navegador cerrado, un ordenador en reposo, una actualización desplegada, el reinicio de un worker o el paso de varios días. Una transcripción puede ayudar a reconstruir lo que pasó, pero reconstruir no es lo mismo que recuperar. Un sistema creíble sabe qué estado es el de referencia en lugar de pedirle a un modelo que deduzca la verdad a partir de una larga conversación cada vez que se despierta.
El mecanismo más profundo para llevar un encargo a través de sus dependencias es una cuestión aparte de la definición de la categoría. En este nivel, la prueba es más sencilla: ¿puede el sistema conservar suficiente estado válido como para continuar sin una nueva explicación?
El tiempo y los eventos pueden volver a entrar en el sistema
El trabajo en el mundo exterior no avanza solo cuando un usuario envía un mensaje. Llegan los plazos. Cambian los archivos. Llegan respuestas. Un dispositivo vuelve a estar en línea. Una aprobación queda registrada en otra aplicación.
Por eso un agente siempre activo necesita algo más que un cuadro de entrada interactivo. Necesita una vía para que un temporizador o un evento externo llegue a la responsabilidad a la que afecta. Esa vía puede ser un webhook, una cola de mensajes, una programación, un conector o un proceso de vigilancia con un alcance estrecho. Lo importante es que el evento pueda asociarse con el agente correcto y el estado correcto.
Esto no implica que cada evento merezca una ejecución completa de razonamiento. El funcionamiento guiado por eventos es valioso precisamente porque la mayor parte del sistema puede permanecer en silencio hasta que haya trabajo que evaluar. Decidir si un evento concreto debe despertar al agente principal, y si ese despertar debe interrumpir a una persona, es un problema de política distinto de definir el propio sistema siempre activo.
Hay un entorno de ejecución disponible cuando se reanuda el trabajo
Recordar el siguiente paso no basta si el agente no tiene dónde llevarlo a cabo. Parte del trabajo puede hacerse mediante una API. Otra parte necesita un navegador, un ordenador en la nube, una máquina local o un runtime de agente especializado. El entorno tiene que estar disponible cuando la responsabilidad vuelve a activarse, con los archivos, herramientas y permisos que requiere el siguiente paso.
«Disponible» no significa permanentemente en marcha. Un ordenador en la nube puede dormir mientras conserva su almacenamiento y despertarse cuando haga falta. Una máquina local puede seguir desconectada hasta que una tarea la necesite. Lo importante es que el agente pueda identificar el entorno necesario y gestionar su ausencia con honestidad.
Los límites del entorno también forman parte de la corrección. La documentación sobre dispositivos de Comma indica que Salix no traslada en silencio el trabajo de un dispositivo desconectado a otro ordenador. La petición puede fallar y reintentarse cuando ese dispositivo vuelva. Es menos mágico que fingir que todos los ordenadores son intercambiables, pero preserva la ubicación, el acceso y las condiciones de ejecución de las que depende el trabajo.
La recuperación forma parte del funcionamiento normal
Un sistema siempre activo acabará encontrándose con un reinicio, un evento duplicado, un servicio no disponible, una credencial caducada o una conexión rota. Por eso la fiabilidad no puede depender de que un proceso siga siendo perfecto para siempre.
El sistema necesita una vía de recuperación: estado persistente, checkpoints o una fuente de verdad equivalente; reintentos con límite; una forma de no repetir una acción externa; y un estado de fallo visible cuando la recuperación automática ya no es segura. Un reinicio que olvida en silencio lo que ya se había confirmado no es recuperación. Tampoco lo es un bucle de reintentos infinito que consume recursos sin cambiar el resultado.
La documentación de Loops de Comma ofrece un ejemplo concreto. Un Loop puede guardar un checkpoint y recibirlo cuando vuelve a arrancar. Tras un fallo, Salix lo reinicia desde ese checkpoint dentro de una política de reintentos con límite; si los fallos se repiten, el Loop se detiene y se avisa al agente. La implementación completa, con eventos duraderos, deduplicación, ubicación y límites de capacidades, se explica en Bucles de eventos programables para nuestro arnés de agentes distribuido. Al evaluar un producto, comprueba si la interrupción y la recuperación son estados previstos y no sorpresas.
El usuario puede ver y acotar la continuidad
La persistencia aumenta la importancia del control. Un chat puntual termina de forma natural. Una responsabilidad en segundo plano necesita un alcance comprensible, un estado visible y un interruptor de apagado que funcione de verdad.
Los usuarios deberían poder saber de qué es responsable el agente, qué fuentes vigila, qué entorno puede usar y qué autoridad tiene allí. Deberían poder pausar o terminar la responsabilidad, revocar el acceso y recuperar el trabajo ya producido. El sistema debería mostrar los fallos y las decisiones con consecuencias en lugar de tratar el silencio como prueba de que todo va bien.
Por eso estar siempre activo y ser autónomo no son sinónimos. La persistencia dice que el sistema puede seguir disponible. La autonomía describe qué decisiones o acciones puede tomar sin preguntar. Un agente puede ser muy persistente y deliberadamente prudente: puede preparar, verificar, organizar y esperar mientras devuelve al usuario los compromisos externos o las decisiones irreversibles.
Cuatro modos de funcionamiento, no una ejecución interminable
La expresión «siempre activo» sugiere una única actividad continua. En la práctica, un agente útil pasa por modos distintos.
Puede estar trabajando, con un modelo y herramientas que hacen avanzar un encargo. Puede estar esperando, porque aún no ha llegado un momento, un evento, un entorno o una decisión humana. Un vigilante ligero puede estar monitorizando una condición estrecha sin despertar al agente principal. O la responsabilidad puede estar detenida, porque el usuario la terminó o un fallo superó la política de recuperación segura.
Estos modos importan tanto para el coste y la atención como para la fiabilidad. La inferencia del modelo, el cómputo en la nube, la recepción de eventos, el almacenamiento y las API de terceros pueden facturarse de formas distintas. Un producto no debería mezclarlos en una afirmación sin matices de que «el agente funciona 24/7». Una responsabilidad tranquila en segundo plano puede usar almacenamiento y recursos de monitorización sin gastar tokens de un modelo grande; una tarea activa puede consumir tanto modelo como cómputo; una responsabilidad detenida no debería consumir ninguno de los dos más allá del estado que se conserva.
Comma refleja esta separación en su propio runtime. Salix ejecuta el agente fuera de un sandbox permanentemente en caliente. Cuando hace falta trabajar con un ordenador, puede despertar una máquina virtual en la nube cuyo almacenamiento se conserva entre usos. Para la atención continua, pequeños Loops pueden vigilar eventos sin mantener activo el bucle principal del agente. Solo cuando un Loop determina que se necesita al agente se ejecuta el bucle principal.
Esa arquitectura es la implementación de Comma, no la definición universal. Otro producto puede usar flujos de trabajo duraderos, colas, funciones serverless o workers de larga duración. La prueba es si el sistema completo preserva la responsabilidad durante los periodos de inactividad, no si usa un runtime concreto.
Siempre activo, programado y de larga duración son promesas distintas
Una automatización programada ejecuta una instrucción en un momento conocido. Puede ser muy útil sin mantener una identidad de agente continua ni responder a cambios no previstos. Si una tarea diaria genera un informe a partir de datos fijos, puede que una programación sea todo lo que el sistema necesita.
Un flujo de trabajo de larga duración puede conservar el estado a lo largo de varios pasos y esperar una señal. Se vuelve propio de un agente cuando los modelos participan en interpretar información, elegir herramientas o adaptar el plan. Está siempre activo en un sentido significativo cuando ese flujo duradero pertenece a un agente continuo que puede recibir nuevos eventos relevantes y actuar dentro de límites que gobierna el usuario.
Un chatbot también puede recordar conversaciones anteriores y ofrecer recordatorios. Esas funciones mejoran la continuidad para el usuario, pero por sí solas no demuestran que el trabajo persista fuera del chat. La pregunta decisiva no es si el sistema recuerda algo sobre ti. Es si una responsabilidad activa puede esperar, reanudarse, recuperarse y llegar a un entorno autorizado sin que haya que recrearla a mano.
Esta distinción también evita construir de más. No todas las peticiones necesitan un agente siempre activo. Una explicación puntual, una reescritura, un cálculo o una lluvia de ideas suelen resolverse mejor con un modelo interactivo. El funcionamiento siempre activo justifica su complejidad cuando el resultado depende del tiempo, de cambios externos, de varios entornos de trabajo o de una responsabilidad que sigue abierta cuando termina la conversación actual.
Una prueba práctica de continuidad
Para evaluar un producto «siempre activo», dale una responsabilidad realista que contenga una espera. Pídele que vigile una condición definida, que prepare el siguiente paso y que se detenga antes de una acción con consecuencias.
Después examina lo que el producto puede mostrarte. ¿Dónde se guarda el encargo cuando cierras la interfaz? ¿Qué condición exacta lo vuelve a poner en marcha? ¿Sabe qué entorno contiene el material de trabajo? ¿Puede reanudarse tras un reinicio sin repetir acciones ya completadas? ¿Qué pasa si el evento llega duplicado o el dispositivo necesario está desconectado? ¿Puedes pausar la vigilancia, revocar el acceso o terminar el encargo sin borrar todo tu historial?
Por último, mira qué te llega a ti. Un sistema que reenvía cada evento ha construido una canalización de notificaciones, no necesariamente un agente. Un sistema que actúa ante cada evento ha confundido disponibilidad con autoridad. Un agente siempre activo útil conecta un cambio con una responsabilidad existente, hace el trabajo ya permitido y solo pide atención cuando esa atención cambia el resultado.
Cómo Comma sigue disponible sin hacer ruido
Comma es un agente personal gratuito y de código abierto, diseñado en torno a un único agente continuo a través de conversaciones y dispositivos. Las preguntas rápidas pueden quedarse en el chat, mientras que las responsabilidades más grandes se convierten en Tasks. Comma puede trabajar en apps y archivos conectados, en un Mac o dispositivo Linux vinculado o en un ordenador en la nube que se despierta cuando hace falta.
Su capa siempre activa es Salix. Un agente de Comma puede crear un Loop para vigilar una fuente acotada, como una bandeja de entrada, un repositorio, un feed, una API o un webhook. El Loop se ejecuta aparte del bucle principal de razonamiento, puede mantener un pequeño checkpoint y puede avisar al agente cuando el trabajo lo requiere. Como el agente principal no necesita revisar cada intervalo tranquilo, «siempre disponible» no se convierte en «siempre gastando tokens del modelo». Un Loop todavía puede llamar a un modelo de decisión rápido o a otro servicio, así que el trabajo en segundo plano no es automáticamente gratuito; el coste depende de lo que el Loop haga en realidad.
Esa misma continuidad sigue sujeta al control del usuario. Los ordenadores vinculados empiezan en solo lectura hasta que el usuario permite las operaciones, y el acceso a los dispositivos puede revocarse. Los Loops tienen límites de capacidades y de despertares. Una Task más grande puede volver a Por revisar cuando una decisión corresponde a la persona. Comma también puede autoalojarse, aunque entonces el operador asume la disponibilidad, las actualizaciones, las copias de seguridad, la configuración del modelo y el resto de la infraestructura necesaria para mantener esa instancia en marcha.
El enfoque de Comma es una respuesta al problema central de la categoría: dejar que la responsabilidad persista mientras el cómputo caro, los modelos y la atención del usuario permanecen inactivos hasta que de verdad hacen falta.
Preguntas frecuentes
¿Un agente de IA siempre activo ejecuta un modelo 24/7?
No. Un sistema bien diseñado puede conservar el estado y estar pendiente de temporizadores o eventos mientras el modelo principal está inactivo. El modelo se ejecuta cuando el sistema necesita razonar o generar. La monitorización ligera, el almacenamiento y los servicios externos pueden seguir consumiendo recursos mientras el agente espera.
¿Un agente siempre activo es lo mismo que un agente autónomo?
No. Estar siempre activo describe la continuidad y la disponibilidad a lo largo del tiempo. La autonomía describe qué puede decidir o hacer el agente sin aprobación humana. Un agente siempre activo puede funcionar con una autoridad estrecha y devolver al usuario las decisiones con consecuencias.
¿Una tarea de IA programada es un agente siempre activo?
No necesariamente. Una programación puede lanzar un prompt sin estado a una hora fija. Un agente siempre activo, además, conserva la responsabilidad y el estado relevante, puede responder a eventos externos adecuados, se recupera de las interrupciones y continúa dentro de controles persistentes del usuario.
¿El ordenador del agente tiene que seguir encendido?
Depende del entorno necesario. El trabajo en la nube o en el servidor puede continuar con un portátil personal cerrado. El trabajo que depende de archivos o aplicaciones disponibles solo en un dispositivo local concreto tiene que esperar a ese dispositivo. Algunos entornos en la nube pueden dormir entre acciones y conservar su almacenamiento.
¿Qué pasa cuando un agente siempre activo falla?
El sistema debería recuperarse desde un checkpoint conocido o un estado duradero, evitar repetir acciones externas ya completadas y usar reintentos con límite. Si no puede recuperarse con seguridad, debería detenerse de forma visible e indicar al agente o al usuario qué ha fallado, en lugar de reintentar indefinidamente o abandonar la responsabilidad en silencio.
¿Puedo apagar un agente siempre activo?
Deberías poder pausar o terminar una responsabilidad en segundo plano y revocar el acceso que usa. «Siempre activo» debería significar disponible cuando está autorizado, no imposible de detener. En Comma, los Loops se pueden pausar o eliminar y el acceso a los dispositivos conectados se puede revocar.
El agente puede dormir; la responsabilidad no puede desaparecer
Un agente de IA siempre activo no se define por una actividad continua del modelo. Se define por una cadena continua de responsabilidad: un responsable estable, un estado duradero, una vía para que el tiempo y los eventos importen, un entorno de ejecución disponible, un funcionamiento recuperable y unos controles que siguen en manos del usuario.
Cuando esas piezas existen, la mayor parte del sistema puede estar en silencio la mayor parte del tiempo. El modelo puede detenerse. El ordenador en la nube puede dormir. El usuario puede cerrar la app. El trabajo se reanuda porque la responsabilidad sigue intacta, no porque alguien se acordara de escribir «continúa».
