Un agente personal siempre activo no debería comportarse como un canal de notificaciones con mejor gramática. Su trabajo no es reaccionar de forma visible a cada correo nuevo, incidencia, cambio de precio, edición de un documento o actualización del calendario. Su trabajo es vigilar mientras tú estás en otra cosa, reconocer la pequeña fracción de cambios que alteran lo que debería pasar a continuación y volver a poner el trabajo adecuado en primer plano en el momento y al nivel adecuados.
Eso convierte «¿cuándo debe despertarse el agente?» en una cuestión de diseño, no solo de rendimiento. Si se despierta demasiado a menudo, el agente se convierte en otra fuente de ruido. Si se calla con demasiada insistencia, se pierde justo aquello por lo que le pediste que vigilara. Si actúa sin un límite claro, un sistema en segundo plano útil se convierte en un problema de autoridad.
La respuesta correcta es una secuencia de decisiones. Un evento nuevo puede no merecer ninguna respuesta, una revisión posterior, un turno del agente principal o tu propio criterio. Son resultados distintos, y un agente fiable no debería reducirlos a uno solo.
Siempre activo debería significar continuidad, no interrupción
«Siempre activo» tiene valor porque el mundo no se organiza en sesiones de chat. Una pull request puede fallar después de cerrar el portátil. Un proveedor puede cambiar una fecha de entrega mientras estás en una reunión. Un contrato puede firmarse tres días después de la última vez que hablasteis de él. El agente necesita continuidad a través de esos huecos si va a encargarse de una responsabilidad que sigue en curso.
La continuidad no exige razonar sin parar. La mayoría de los eventos son duplicados, confirmaciones rutinarias, cambios irrelevantes o información que seguirá siendo útil más tarde. Despertar a un modelo grande por cada evento desperdicia cómputo, pero el coste mayor es de comportamiento: si cada despertar se convierte en un mensaje, el agente gasta la atención del usuario como si fuera gratis.
La investigación sobre notificaciones en el trabajo lleva tiempo encontrando la misma tensión. La gente valora estar al tanto de forma pasiva, pero las notificaciones interrumpen la tarea en la que está concentrada. La investigación sobre el aplazamiento acotado también muestra por qué «ahora o nunca» es la elección equivocada: un aviso puede retrasarse dentro de un límite conocido, de modo que se conserva la información sin tratar cada llegada como urgente.
Por eso, un agente siempre activo debería mantener separados tres relojes:
el momento en que llega un evento;
el momento en que el agente necesita razonar sobre él;
el momento en que el usuario necesita saberlo o decidir.
A veces los tres son inmediatos. Normalmente no lo son.
Despertar no es notificar, y notificar no es dar permiso
El límite más importante es fácil de pasar por alto. Detectar un evento, despertar al agente principal, avisar al usuario y realizar una acción externa son cuatro pasos distintos.
Supón que Comma está siguiendo una pull request. Llega un nuevo comentario de revisión. El proceso de vigilancia puede decidir primero si el comentario cambia algo relevante. Si lo cambia, el agente principal puede despertarse y revisar la pull request, la conversación alrededor y la Task a la que pertenece. Puede que el agente actualice un borrador o prepare una corrección sin interrumpirte. Puede que tenga que avisarte de que la ventana para fusionar corre peligro. O puede llegar a una decisión, como aceptar una concesión de seguridad, que te corresponde a ti.
Ninguna de esas conclusiones se deduce solo de la llegada del comentario.
La arquitectura de Comma está pensada para funcionar con esta separación. Un Loop ligero vigila y despierta al agente principal solo cuando hace falta; después, el agente principal hace el trabajo que requiere contexto. Los detalles técnicos, como la forma en que los Loops filtran eventos, eliminan despertares duplicados y funcionan dentro de cuotas, se explican en Bucles de eventos programables para nuestro arnés distribuido de agentes. El principio para el lector es más sencillo: un evento es una prueba, no una instrucción, y un despertar es una petición para investigar, no un permiso para actuar.
Las cuatro pruebas para despertar al agente principal
Una política de despertar útil puede expresarse en cuatro pruebas. No son una tabla de puntuación en la que un total alto gana automáticamente. Cada prueba elimina un tipo distinto de falsa alarma.
1. ¿Ha cambiado algo de verdad?
La primera prueba trata del estado, no de la actividad. Un mensaje nuevo es actividad. Que un plazo se adelante, que aparezca un bloqueo, que llegue una aprobación o que se cumpla una condición prometida es un cambio de estado.
El agente debería quedarse callado cuando el evento nuevo repite lo que ya sabe, confirma la recepción de un mensaje sin cambiar el plan o queda fuera de la responsabilidad que se le pidió vigilar. Los identificadores estables y la eliminación de duplicados ayudan a nivel de sistema, pero la repetición semántica sigue necesitando criterio: dos mensajes distintos pueden comunicar el mismo «no ha cambiado nada».
Esta prueba evita que el movimiento se haga pasar por progreso.
2. ¿Afecta el cambio a un objetivo o una restricción activos?
Lo que es relevante depende de cada persona. Que baje el precio de un vuelo no es importante en sí; importa si baja del presupuesto que el usuario fijó para un viaje que todavía piensa hacer. Una compilación fallida importa de forma distinta en una rama abandonada, en una rama experimental y en una versión candidata.
El agente necesita el objetivo, el plan actual, las restricciones pertinentes y suficiente información de procedencia para saber de dónde salen esos datos. Sin ese contexto, «importante» tiende a significar llamativo en general en lugar de útil en concreto.
Aquí es también donde el ámbito protege la confianza. Un Loop que sigue un repositorio no debería convertir una mención de pasada a otro proyecto en un nuevo encargo. El contenido que llega puede informar la responsabilidad vigilada; no puede ampliarla en silencio.
3. ¿Hay una ventana para actuar?
Algunos cambios importan, pero no requieren razonar ahora. Un informe que se revisará el viernes puede esperar en un resumen. Un envío retrasado puede volverse relevante solo si amenaza a algo que depende de él. En cambio, la cancelación de una reunión que libera un hueco de reserva escaso, o una regresión en producción que se extiende a más usuarios, puede perder valor con cada minuto de retraso.
La pregunta no es simplemente «¿es urgente?». Es: ¿razonar ahora crearía una opción mejor que razonar más tarde?
Si la respuesta es sí, despierta al agente principal. Si la información seguirá siendo igual de útil para actuar, aplázala hasta un punto de control natural o agrúpala con actualizaciones relacionadas. Si no hay ninguna acción posible y no cambia ningún plan, regístrala y quédate callado.
4. ¿A quién corresponde la siguiente decisión?
Cuando el agente principal ha reunido el contexto, debe decidir quién tiene autoridad para el siguiente paso.
El trabajo rutinario y reversible dentro de las instrucciones del usuario a menudo puede seguir sin interrupciones. El agente puede actualizar sus notas de la Task, preparar una comparación o redactar una respuesta. Una decisión con consecuencias, ambigua o que depende de preferencias debería volver al usuario. En Comma, el trabajo que necesita una decisión humana puede esperar en Por revisar en lugar de resolverse a ciegas o marcarse como terminado.
Una buena escalada es concreta. Debe decir qué ha cambiado, por qué eso cambia el plan, qué ha comprobado ya el agente, qué decisión hace falta y cuándo deja de ser útil esa decisión. «¿Qué quieres hacer?» no es un traspaso; es un análisis sin terminar.
Cuatro resultados legítimos, no solo despertar o dormir
Una vez aplicadas las pruebas, el agente tiene cuatro respuestas útiles.
Quedarse callado. No ha cambiado nada relevante, el evento es un duplicado o queda fuera de la vigilancia. El silencio debería ser una conclusión deliberada, con suficiente rastro interno para diagnosticar errores, y no la ausencia de procesamiento.
Aplazar o agrupar. El cambio es relevante, pero su valor sobrevive a un retraso. Añádelo al siguiente punto de control de la Task, a un resumen o a un informe breve. El aplazamiento necesita un límite: «más tarde» debería significar un momento o una condición conocidos, no una lista de pendientes sin dueño.
Despertar al agente principal. El evento puede cambiar el plan, requiere un contexto más amplio o es demasiado incierto para el filtro ligero. Despertar es apropiado incluso cuando el resultado final es el silencio; el agente principal puede investigar y concluir que no hace falta ningún mensaje para el usuario.
Devolver el control al usuario. El agente ha llegado a una decisión que implica autoridad, riesgo, gusto o una concesión que solo el usuario puede hacer. Debería conservar el trabajo ya hecho y plantear la decisión más pequeña que desbloquee el avance.
Este modelo de cuatro salidas hace manejable la incertidumbre. Un proceso de vigilancia no tiene que fingir seguridad cuando las pruebas son débiles. Puede despertar al agente principal para que compruebe más a fondo. El agente principal, a su vez, no tiene que fabricar autonomía cuando una decisión pertenece al usuario.
La confianza debería cambiar la ruta, no ocultar el evento
Un sistema siempre activo se equivocará a veces. El fallo peligroso no es solo una falsa alarma; es un evento suprimido con total seguridad que el usuario nunca tiene ocasión de recuperar.
La postura por defecto de Comma refleja esa asimetría. Cuando los Loops usan Jev para filtrar una pull request, una incidencia o un hilo que siguen, «callar» exige una confianza alta. La incertidumbre y los errores pasan al agente principal, que tiene instrucciones de verificar la fuente antes de escribir al usuario. Jev puede clasificar; no puede enviar mensajes, cambiar el estado externo ni darse más acceso. El comportamiento y los límites actuales están documentados en Conoce Salix, el arnés de agentes de Comma y en la documentación de los Loops.
Ese diseño no elimina los errores. Una decisión de callar equivocada y tomada con seguridad todavía puede ocultar una actualización. Sin embargo, sí pone la incertidumbre en la ruta más segura: una inspección más profunda en lugar de un descarte silencioso. Los usuarios también deberían poder pausar o eliminar una vigilancia, reducir su ámbito y retirar el acceso operativo. Un agente se gana el derecho a estar presente en segundo plano haciendo que esa presencia pueda inspeccionarse y revertirse.
Una buena interrupción llega con el trabajo ya hecho
El valor de un agente personal siempre activo no está en que se entere antes que tú. Las herramientas de monitorización ya hacen eso. El valor está en que puede conectar el cambio con una responsabilidad activa y reducir el trabajo que te toca a ti.
Una interrupción útil podría decir, en esencia, algo así:
El revisor ha pedido un cambio en el flujo de autenticación. Bloquea el criterio de lanzamiento que fijaste para el jueves. He revisado la rama actual y he reproducido el problema. He preparado un parche y pruebas; aprobar la concesión de compatibilidad es la única decisión que necesito de ti antes de aplicarlo.
Ese mensaje lleva contexto, consecuencias, la investigación terminada, un siguiente paso propuesto y un límite de decisión claro. No pide al usuario que reconstruya por qué importa el evento. Tampoco confunde una siguiente acción plausible con la autorización para llevarla a cabo.
El mismo criterio se aplica cuando el agente decide no interrumpir. Una actualización aplazada debería reaparecer en el punto de control prometido. Una decisión de callar debería poder auditarse. Una Task que necesita criterio debería esperar a la vista, no desaparecer dentro de una conversación interminable.
El objetivo es una continuidad tranquila
Un agente siempre activo debería crear continuidad sin exigir atención continua. El sistema exterior vigila de forma barata y acotada. El agente principal se despierta cuando un cambio puede alterar el plan. Investiga antes de interrumpir. Continúa el trabajo rutinario y reversible cuando el usuario ya le ha dado la autoridad, y devuelve las elecciones con consecuencias con el trabajo pertinente adjunto.
La experiencia resultante no es un agente que habla más. Es un agente que puede seguir siendo responsable mientras guarda silencio, y que sabe exactamente cuándo el silencio ha dejado de ser útil.
Preguntas frecuentes
¿Qué se ejecuta antes de que se despierte el agente principal?
En Comma, un Loop ligero vigila la bandeja de entrada, el repositorio, el canal, la API o el webhook elegidos. Su programa puede aplicar reglas deterministas y puede pedir a Jev una decisión tipada y rápida. El agente principal y su contexto más amplio solo se ejecutan cuando el Loop envía un despertar para una investigación o una acción más profunda.
¿Cada despertar del agente debería convertirse en una notificación para el usuario?
No. Un despertar permite al agente principal revisar el contexto y decidir qué cambia el evento. Puede continuar el trabajo en segundo plano, aplazar una actualización o concluir que no hace falta interrumpir al usuario. Solo debería pedirse la atención del usuario cuando estar al tanto o decidir sea urgente.
¿Qué debería pasar cuando el agente no está seguro?
La incertidumbre debería llevar el evento a quien pueda decidir mejor. Un filtro ligero puede despertar al agente principal; el agente principal puede verificar la fuente, reunir contexto y avanzar dentro de su autoridad o preguntar al usuario. La incertidumbre no debería convertirse en una decisión segura de callar ni en una acción no autorizada.
¿Cómo puede un usuario detener una vigilancia siempre activa?
Comma permite pedirle que pause o elimine un Loop. El acceso a los ordenadores conectados también puede volver a solo lectura desactivando las operaciones. Una responsabilidad siempre activa debería tener siempre un ámbito comprensible, un estado visible y un interruptor de apagado práctico.
Convierte una señal en un siguiente paso útil
Empieza con una sola fuente de eventos y apunta qué cambiaría de verdad tu plan, cuánto tiempo sigue abierta la ventana para actuar y qué decisión debe seguir siendo tuya. Explora el Agent de Comma para ver cómo la atención proactiva se conecta con las Tasks y la revisión, o lee la documentación de los Loops para conocer el modelo de monitorización actual y sus límites.
