Llevo tiempo corriendo agentes las veinticuatro horas, en tandas de diez a quince días, dentro de sesiones continuas y muy largas. Pasar tanto tiempo dentro de ese tipo de entorno cambió cómo pienso el prompting.
Al principio la pregunta es cómo lograr que un agente complete una tarea. Pero cuando los agentes siguen trabajando después de que el intercambio inmediato terminó, otra pregunta se vuelve más importante: qué mantiene al sistema haciendo trabajo útil cuando ya no dirijo cada paso.
Mantener agentes activos no es lo mismo que mantenerlos productivos. Un proceso puede continuar indefinidamente sin avanzar de verdad. Puede revisitar decisiones ya tomadas, generar trabajo innecesario o producir cambios que parecen terminados hasta que alguien los revisa.
El trabajo, entonces, no es simplemente extender la sesión. Es construir las condiciones bajo las cuales la ejecución continua sigue siendo útil, coordinada y responsable.
Cada vez más, no estoy sólo prompteando a un agente. Estoy dando forma a la arquitectura dentro de la cual trabajan los agentes.
La instrucción se extiende más allá del prompt
En una interacción directa, buena parte de la coordinación pasa por mí. Decido qué importa, doy contexto, reviso el resultado, identifico la siguiente tarea e intervengo cuando algo sale mal. El agente ejecuta, pero yo aporto casi toda la continuidad.
En un entorno persistente, algunas de esas responsabilidades necesitan una casa explícita.
El sistema necesita formas de reconocer eventos relevantes, seleccionar el trabajo adecuado, preservar decisiones, coordinar propiedad, evaluar resultados y determinar cuándo detenerse o pedir ayuda. Un prompt de tarea bien escrito no resuelve nada de eso por sí solo.
Ahí es donde el prompting empieza a cambiar de naturaleza. En lugar de describir únicamente un resultado deseado, estoy definiendo comportamiento operativo: a qué debe poner atención un agente, sobre qué está autorizado a actuar, qué califica como trabajo productivo, qué evidencia debe producir y qué debe pasar cuando se topa con incertidumbre.
Pero esto no significa que la arquitectura esté hecha de prompts. Las instrucciones pueden describir una política; el software que las rodea todavía tiene que sostenerla y hacerla cumplir. La propiedad, los permisos, el estado durable, los límites de recursos y los requisitos de revisión no pueden depender por completo de que un agente se acuerde de respetarlos.
El prompt expresa el comportamiento buscado. La arquitectura hace que ese comportamiento sea posible, observable y acotado.
Reactividad e iniciativa necesitan mecanismos distintos
Una parte de mi setup es reactiva. Las herramientas de monitoreo permiten que un entorno de agentes responda cuando algo relevante cambia. Aparece un ticket, una tarea queda lista, o algún otro entorno produce algo que requiere atención.
Esto significa que no tengo que entregar personalmente cada instrucción siguiente. El trabajo puede llegar a través del sistema.
La otra parte es proactiva. Con loops recurrentes y un prompt que los empuja a buscar tareas productivas, los agentes pueden reevaluar su entorno e identificar trabajo útil sin esperar un mensaje nuevo de mi parte.
Son responsabilidades distintas. La reactividad pregunta: "algo cambió, ¿requiere una respuesta?". La iniciativa pregunta: "dado el objetivo actual y el estado del trabajo, ¿hay algo útil que debería hacer?".
La dificultad está en definir útil. "Siempre encuentra algo que hacer" es una mala política operativa. Puede convertir la capacidad ociosa en cambios innecesarios, mejoras especulativas o más tickets para que otros agentes los procesen.
Una mejor política conecta la iniciativa con un objetivo existente, la evidencia disponible, una autoridad explícita y un costo razonable. A veces la acción correcta es implementar algo. A veces es investigar un bloqueo, cuestionar un supuesto o pedir una decisión. A veces no hay ninguna acción justificada, y el agente debería volver a monitorear.
El objetivo no es la actividad ininterrumpida. Es el avance sostenido sin necesidad de dirección humana ininterrumpida.
Los tickets se están volviendo objetos de coordinación
Uso un sistema de tickets con etiquetas, conectado al monitoreo, para que distintos entornos de agentes puedan reaccionar de formas especializadas.
En ese arreglo, una etiqueta es más que un rótulo para un humano que mira un tablero. Puede convertirse en una señal de ruteo. Un ticket puede hacer que un trabajo sea descubrible para el entorno adecuado, disparar una respuesta especializada o sostener el lanzamiento de varios agentes que contribuyen a un objetivo mayor.
Eso cambia lo que un ticket representa. Ya no es sólo un recordatorio de que algo debería pasar. Se vuelve un objeto compartido a través del cual los entornos coordinan qué tiene que pasar, quién es responsable y en qué estado está el trabajo.
Piensa en un cambio que afecta tanto a una interfaz como al comportamiento que hay debajo. Un entorno podría encargarse de la implementación, otro podría examinar la interacción y otro podría probar si el resultado satisface el requisito original. Sus aportes podrían representarse como tickets relacionados, con dependencias explícitas y una definición compartida de "terminado".
La colaboración no exige que todos los agentes habiten la misma conversación. Exige que trabajen contra un estado compatible.
Esa distinción importa. Varios agentes trabajando a la vez no están necesariamente colaborando. Sin propiedad clara y sin entregas claras, el paralelismo produce esfuerzo duplicado, cambios en conflicto o revisiones de un artefacto que ya quedó viejo.
La arquitectura tiene que hacer posible distinguir el trabajo que está disponible del trabajo que ya está tomado, y un resultado propuesto de uno aceptado. Los prompts ayudan a que los agentes interpreten esas distinciones. El sistema de coordinación tiene que preservarlas.
La actividad necesita evidencia
Conforme estos entornos se vuelven más persistentes, la instrumentación y la revisión de calidad pesan más.
Estoy incorporando un ledger de responsabilidad de agentes porque un flujo de actividad no alcanza para entender si el sistema está cumpliendo sus responsabilidades.
Una transcripción me dice qué dijo un agente. Un log me dice que algo ocurrió. La pregunta de responsabilidad es otra: a qué se comprometió el agente, qué produjo en realidad, y qué respalda la afirmación de que el trabajo está terminado.
El Ledger debería conectar un Compromiso con su historial de ejecución y con la evidencia que lo sostiene. Esa evidencia puede ser un artefacto, un cambio de código, el resultado de una prueba o una revisión atada a la versión que se está evaluando. El registro también debería preservar las objeciones sin resolver, en lugar de permitir que un mensaje seguro de "listo" las borre.
Por eso también estoy moviendo el desarrollo y la revisión en una dirección más adversarial.
No me refiero a darles personalidades discutidoras a los agentes. Me refiero a estructurar la revisión para que su trabajo sea cuestionar el resultado propuesto: identificar supuestos sin sustento, buscar contraejemplos, probar condiciones de falla y verificar si la evidencia realmente sostiene la aceptación.
Que otro agente esté de acuerdo con el primero no es, por sí solo, verificación suficiente. Podrían estar repitiendo el mismo supuesto. La pregunta útil no es si la revisión suena tranquilizadora, sino si introdujo una prueba significativa que el trabajo pudo haber reprobado.
La instrumentación debería sostener esa distinción. Me importa menos el número de acciones ejecutadas que los resultados aceptados, el trabajo reabierto, las fallas repetidas, las dependencias sin resolver y los recursos consumidos para llegar a un resultado verificado.
La responsabilidad convierte "el agente está trabajando" en una afirmación que puedo examinar.
La terminal muestra la ejecución, no la operación completa
Aquí es donde la interfaz empieza a quedarse corta.
La terminal sigue siendo útil para inspeccionar un proceso, leer salida, depurar la ejecución e intervenir de forma directa. Pero cuando varios entornos ya están reaccionando a tickets, seleccionando trabajo, produciendo artefactos y revisándose entre ellos, el estado importante queda distribuido entre todos.
No necesito solamente ver qué está diciendo cada agente. Necesito entender qué está haciendo el sistema en conjunto.
Un agente puede estar produciendo salida constante sin lograr ningún avance aceptado. Otro puede estar callado porque está esperando correctamente una dependencia. Un tercero puede reportar que terminó mientras una revisión sin resolver todavía impide la aceptación.
Esas situaciones deberían verse distintas en la interfaz, sin obligarme a reconstruirlas a partir de varias transcripciones.
El objeto principal de esta interfaz debería ser el trabajo, no la conversación.
Quiero partir de un objetivo y ver sus Compromisos activos, los entornos responsables de ellos, las dependencias entre ellos y la evidencia que sostiene su estado actual. Desde ahí debería poder inspeccionar una corrida específica, un artefacto, una revisión o una sesión de terminal.
La interfaz también necesita exponer relaciones que una terminal no agrega de forma natural: qué disparó la actividad de un agente, por qué tomó un ticket, qué versión revisó otro agente, dónde está bloqueado el trabajo, y si el consumo de recursos está produciendo resultados aceptados o intentos repetidos.
No todo dato pertenece a la pantalla principal. El propósito no es rodear al operador de más telemetría. Es hacer visibles las distinciones consecuentes: avanzando o dando vueltas, esperando o abandonado, tomado o verificado, autónomo o esperando una decisión.
Y esto no puede ser de sólo lectura. Necesito redirigir prioridades, pausar un entorno, ajustar su autoridad, resolver propiedad en conflicto o exigir revisión adicional. Esas intervenciones deberían volverse parte del registro operativo compartido, en lugar de quedarse como instrucciones aisladas en la terminal que me tocó abrir.
La terminal sigue siendo una superficie de ejecución. Deja de ser la interfaz completa de operación.
De dirigir cada paso a dar forma a cómo continúa el trabajo
Lo que estas sesiones largas me aclararon es que la continuidad importante no es simplemente la longitud de una conversación. Es si el objetivo, el estado del trabajo, las responsabilidades y la evidencia siguen siendo coherentes mientras la ejecución continúa.
El prompting sigue importando. Pero su papel se expande: de pedir un resultado a expresar políticas de atención, iniciativa, colaboración, verificación y escalamiento.
Los tickets hacen que el trabajo sea direccionable. Los monitores hacen que los cambios sean accionables. Los loops hacen posible la iniciativa. El Ledger y las revisiones hacen inspeccionable la terminación. La interfaz tiene que traer esas relaciones a una forma que una persona pueda entender y dirigir.
A eso me refiero con promptear la arquitectura: pasar de decirle a un agente qué hacer a continuación, a definir cómo un sistema de agentes determina, coordina y verifica qué pasa a continuación.
La siguiente interfaz que necesito es más que un mejor lugar para hablarle a los agentes. Es un lugar para entender y dirigir el trabajo que están haciendo juntos.