Muchas tareas importantes no fallan mientras alguien está trabajando en ellas. Fallan en los huecos.
Un proveedor todavía no ha respondido. Un informe depende de cifras que llegan mañana. Hay una sesión del navegador abierta en una computadora, mientras que la persona que puede aprobar el siguiente paso está en otra zona horaria. Para cuando se resuelve la dependencia, la conversación original ha quedado enterrada y nadie recuerda exactamente dónde se detuvo el trabajo.
Un agente personal siempre activo debería manejar bien esos huecos. No necesita pensar sin parar ni mantener una computadora funcionando a toda potencia. Necesita conservar la responsabilidad: qué resultado aceptó, qué se ha hecho ya, qué está esperando, dónde están los materiales de trabajo y qué evento o decisión permite que la tarea continúe.
Esa es la diferencia entre un chat largo y un trabajo a largo plazo. Un chat largo guarda mensajes. El trabajo a largo plazo requiere un estado operativo duradero.
El trabajo a largo plazo necesita una Task duradera, no un chat más largo
Una conversación sirve para fijar la intención. Como unidad de responsabilidad, se queda corta.
Supón que le pides a un agente que prepare un informe para el consejo cuando finanzas cierre el mes. El estado útil no es solo tu petición inicial. Incluye el borrador ya montado, los documentos de origen revisados, las cifras que faltan, la persona o el sistema que debe proporcionarlas, la fecha límite de la reunión y el nivel que debe alcanzar el informe final.
En Comma, el trabajo que necesita algo más que una respuesta rápida se convierte en una Task. Según la documentación de Tasks de Comma, la Task puede pasar por el trabajo activo, esperar en Por revisar cuando hace falta una decisión humana y llegar a Hecha cuando el trabajo termina. Lo importante no es la etiqueta en sí. Es que la responsabilidad sobrevive cuando el chat ya no está abierto.
Una Task duradera debería poder responder siempre a seis preguntas:
Sin esas respuestas, «ya seguiré más tarde» es optimismo. Con ellas, se convierte en un plan.
Esperar es un estado, no un fallo
La mayor parte del trabajo útil incluye esperas legítimas. El error es tratar cada pausa como un fallo o como una invitación a seguir consultando sin fin.
Un agente debería identificar qué tipo de espera ha empezado y asociarle una condición de salida clara:
Estas distinciones importan porque cada espera pide un comportamiento distinto. Una tarea que espera por tiempo puede dormir hasta su punto de control. Una que espera un evento puede vigilar un cambio bien acotado. Una que espera un entorno debería decir qué dispositivo o herramienta no está disponible, en lugar de intentar el trabajo en otro sitio sin avisar. Una que espera una decisión debería devolver una elección bien planteada a la persona a quien corresponde.
La pausa también debería tener un límite. Si la respuesta esperada nunca llega, el agente necesita un plan alternativo: recordárselo a la persona responsable, preguntar al usuario si debe continuar con supuestos o cerrar la Task como bloqueada. Si no, una responsabilidad en segundo plano puede seguir abierta en teoría mientras en la práctica queda abandonada.
Por eso, siempre activo tampoco debería significar que interrumpe siempre. La cuestión aparte de qué eventos justifican despertar al agente, y cuáles de ellos justifican interrumpir al usuario, se trata en ¿Cuándo debe despertarse un agente personal siempre activo?. Aquí el principio relevante es más concreto: cada pausa necesita un motivo observable y un camino definido de vuelta al trabajo.
Reanudar desde un punto de control, no desde una nueva explicación
Cuando termina la espera, el agente no debería reconstruir el encargo a partir de mensajes dispersos ni pedir al usuario que se lo explique otra vez. Debería reanudar desde un punto de control.
Un punto de control útil es un registro compacto de la situación de trabajo:
el resultado original y el criterio de finalización actual;
la última acción significativa y su resultado;
los artefactos ya creados o modificados;
los supuestos que siguen vigentes;
el bloqueo que causó la pausa;
la siguiente acción prevista cuando se resuelva ese bloqueo;
el entorno en el que debe realizarse esa acción.
Esto es estado de trabajo, no memoria personal. La memoria puede ayudar a un agente a recordar las preferencias de una persona a lo largo de muchas tareas. Un punto de control existe para que una responsabilidad concreta pueda continuar con precisión después de un tiempo de inactividad, un reinicio o un traspaso.
La distinción evita dos fallos habituales. Primero, el agente no debería arrastrar cada detalle de una conversación larga a cada paso futuro. Segundo, no debería comprimir la tarea con tanta agresividad que desaparezca una restricción crítica. El punto de control es selectivo: conserva aquello de lo que depende la siguiente acción.
El sistema que hay debajo de Comma refleja este patrón en más de un nivel. Los Loops de Salix pueden guardar puntos de control de su estado para que un proceso acotado en segundo plano se reanude después de un reinicio. Esa infraestructura no sustituye a una Task bien definida, pero ilustra la misma regla de continuidad: la recuperación debería empezar desde un estado conocido, no desde conjeturas.
Mantén el trabajo en el entorno que de verdad necesita
El trabajo a largo plazo rara vez ocurre en un «espacio de trabajo de IA» abstracto. Ocurre en el correo, los documentos, las herramientas de proyectos, los navegadores, los archivos locales y el software especializado. Por eso, la continuidad incluye el lugar donde está el trabajo.
Comma puede trabajar con aplicaciones y archivos conectados, en la computadora de una persona o en su propia computadora en la nube. La documentación de Salix explica que el almacenamiento de la computadora en la nube se conserva entre usos, aunque la máquina virtual pueda dormir cuando está inactiva. Los archivos y las herramientas pueden quedarse donde el agente los dejó, y la computadora puede volver a despertarse cuando la Task lo necesite.
Parte del trabajo debe quedarse en un dispositivo concreto. Un archivo de diseño local, una aplicación de escritorio con sesión iniciada o un entorno de desarrollo pueden existir solo en una Mac o una computadora Linux vinculada. La documentación de los entornos de ejecución de agentes de Comma es explícita sobre ese límite: si el dispositivo externo designado está desconectado, el trabajo espera o falla; Salix no lo traslada en silencio a otra máquina.
Esa limitación es una propiedad útil para la confianza. La migración automática podría parecer cómoda, pero puede cambiar los archivos disponibles, los permisos, las credenciales y las condiciones de ejecución. Un agente fiable debería hacer visible ese límite:
El siguiente paso necesita la Mac llamada «Studio». Está desconectada. La Task está esperando ahí; no se trasladó ningún trabajo a la computadora en la nube.
Ahora el usuario sabe por qué se ha detenido el avance y qué lo desbloqueará. El agente puede volver a intentarlo cuando regrese el dispositivo o preguntar si otro entorno es aceptable. No debería fingir que todos los entornos de ejecución son intercambiables.
Devuelve solo la decisión que corresponde a la persona
Pasar el testigo a una persona no es un fallo de la autonomía. Es la forma en que un agente personal mantiene la diferencia entre hacer el trabajo y responder de las consecuencias.
El agente debería continuar los pasos rutinarios y reversibles que entran en el encargo. Debería devolver el control cuando llega a una ambigüedad importante, a un límite de permisos, a una acción externa irreversible o a una elección que depende de las preferencias del usuario y no de las pruebas disponibles.
El traspaso en sí debería ser pequeño. Un mal traspaso dice: «Estoy bloqueado, ¿qué hago?». Uno útil contiene:
Qué ha cambiado: la nueva información o condición que acabó con el plan anterior.
Qué está ya hecho: el trabajo que el agente terminó antes de preguntar.
Qué decisión queda: una elección precisa, no una petición para volver a gestionar toda la Task.
Qué cambian las opciones: la consecuencia relevante de cada camino.
Cuándo importa la elección: una fecha límite o el efecto de esperar.
Qué pasa después: la acción que el agente reanudará tras la respuesta.
Por ejemplo: «El local solo puede reservar la fecha hasta el jueves. Comprobé las condiciones de cancelación y preparé los datos de la reserva. Aprobar ahora compromete la señal; esperar mantiene la flexibilidad, pero puede hacer que perdamos el hueco. ¿Envío la reserva?».
Comma usa Por revisar para el trabajo que necesita este tipo de decisión humana. La Task se mantiene intacta alrededor de la pregunta, así que una respuesta puede liberar la siguiente acción en lugar de iniciar una nueva sesión de planificación.
«Hecha» necesita pruebas y un cierre
Una Task de larga duración no está terminada solo porque el agente haya dejado de actuar. Puede que se haya agotado el tiempo, que haya consumido su política de reintentos, que haya producido un borrador que todavía necesita revisión o que haya llegado al límite de sus permisos.
El cierre debería indicar:
el resultado pedido;
el resultado realmente producido;
los artefactos creados o modificados;
las comprobaciones realizadas;
cualquier limitación, supuesto o seguimiento pendiente;
si una acción externa se ejecutó o solo se preparó.
Este registro permite al usuario revisar el trabajo sin repasar toda su historia. También evita una ambigüedad peligrosa entre «la Task ya no se está ejecutando» y «se ha conseguido el resultado».
Hecha es un estado del flujo de trabajo, no un certificado de verdad. Un agente puede verificar que se creó un archivo, que un comando tuvo éxito o que se envió un mensaje. No puede convertir material de origen incierto en certeza cambiando un estado. Las afirmaciones siguen necesitando pruebas adecuadas, y el trabajo con consecuencias puede seguir mereciendo una revisión humana.
Un protocolo práctico para trabajos que duran días
No hace falta diseñar un sistema de orquestación antes de delegar una responsabilidad de varios días. Una buena petición puede fijar el acuerdo esencial en pocas líneas.
Empieza por nombrar el resultado y qué significa «suficientemente bueno». Indica la fecha límite inamovible y cualquier ventana de decisión anterior. Di qué acciones puede realizar el agente sin preguntar y cuáles requieren aprobación. Indícale el entorno en el que deben estar el material de origen y los archivos de trabajo.
Después, haz explícita la espera. Dile al agente qué dependencia se espera, cuándo volver a comprobar y qué hacer si nunca llega. Pídele que guarde un punto de control antes de cada pausa y que solo te devuelva las decisiones que de verdad te corresponden. Por último, exige una nota de cierre con el resultado, las comprobaciones y la incertidumbre que quede.
Una delegación compacta podría ser así:
Prepara el informe final para el consejo cuando finanzas publique las cifras de cierre de mes. Usa el borrador y el libro de cálculo que ya están en la computadora en la nube. Puedes actualizar el borrador y validar los totales, pero pregúntame antes de enviar nada fuera. Si las cifras no han llegado el martes a mediodía, dime qué secciones están bloqueadas y propón la alternativa menos arriesgada. Cuando termines, devuélveme el documento, las fuentes comprobadas y los supuestos que sigan en pie.
El valor no viene de complicar el prompt. Viene de dar a la Task estados claros por los que pasar: aceptada, en curso, en espera, lista para revisar, reanudada y cerrada.
Preguntas frecuentes
¿Qué sigue activo mientras una Task de larga duración espera?
La Task conserva el resultado, el trabajo completado, la dependencia actual, el punto de control y la condición para reanudarse. El entorno de ejecución puede dormir, y ningún modelo necesita razonar de forma continua. Si un Loop de ámbito reducido vigila la condición que falta, sigue estando separado del estado duradero de la Task, que le dice al agente qué hacer cuando la condición se cumpla.
¿Qué pasa si la computadora que necesita una Task está desconectado?
Si la Task está asignada a un entorno de ejecución externo en ese dispositivo, el trabajo espera o falla hasta que el dispositivo esté disponible. Salix no lo traslada automáticamente a otra computadora. La Task debería dejar claros el entorno bloqueado y la condición de recuperación.
¿El estado de una Task es lo mismo que la memoria de un agente?
No. El estado de una Task describe una responsabilidad: su resultado, su progreso, sus artefactos, su bloqueo y su siguiente acción. La memoria personal puede abarcar varias responsabilidades e incluir preferencias duraderas. Una Task de larga duración debería poder reanudarse sin convertir cada detalle de trabajo en memoria permanente.
¿Cómo debería esperar un agente a otra persona?
Debería registrar qué se pidió, a quién, cuándo se considera que la respuesta llega tarde y qué alternativa se aplica. Si un evento puede vigilarse, debería vigilar ese evento en lugar de interrumpir al usuario una y otra vez. Una espera indefinida sin regla de escalada no es un plan completo.
¿Qué debería ir en Por revisar?
Úsalo para decisiones o permisos que de verdad corresponden al usuario: concesiones con consecuencias, intenciones ambiguas, acciones externas irreversibles, compromisos delicados o nueva autoridad. El agente debería adjuntar el trabajo completado y pedir la decisión más pequeña que desbloquee el avance.
¿Hecha significa que el resultado es correcto?
Hecha significa que la Task ha alcanzado la condición de finalización declarada. La confianza sigue dependiendo de la calidad de sus fuentes, sus comprobaciones y su revisión. Una nota de cierre útil separa los hechos verificados, los supuestos y los riesgos sin resolver.
La continuidad es el producto
La razón de más peso para usar un agente personal siempre activo no es que pueda hacer un maratón de razonamiento sin interrupciones. Es que puede llevar una responsabilidad a través de las discontinuidades normales del trabajo real: computadoras que duermen, respuestas que se retrasan, datos programados, condiciones que cambian y momentos en los que una persona debe decidir.
Esa continuidad se construye con un estado visible. La Task sabe lo que debe, la espera tiene un motivo, el entorno tiene nombre, el traspaso está acotado y la finalización llega con pruebas. Cuando esas piezas sobreviven a los huecos, puedes dejar el trabajo sin abandonarlo y volver sin reconstruirlo desde el principio.
