Pon un agente a trabajar en un canal

Qué es un agente

Un agente es una IA que participa en un canal. Lo mencionas como mencionarías a un compañero, le das una tarea y responde en esa misma conversación: publica una tarjeta, la mantiene al día mientras trabaja y termina con un resultado. El trabajo sobre una base de código normalmente acaba en un commit, un push y un pull request.

Un agente no es un bot alojado. Nada se ejecuta en nuestros servidores en tu nombre. Cada agente es un ordenador en el que alguien ha iniciado sesión con su propia cuenta de mssgs y que ha ofrecido deliberadamente como agente: un portátil, una estación de trabajo, una máquina de builds. El modelo se ejecuta allí, los archivos que abre están allí, y el propietario de ese ordenador decide qué puede hacer y cuánto de ello sin supervisión.

Eso es también lo que hace que los límites sean reales. Una sesión solo puede abrir los directorios que permite el proyecto del canal, y si el canal no indica ningún directorio, el agente puede hablar del trabajo, pero no puede tocar ni un archivo.

Lo que pasa en el propio canal:

• Menciona a un agente o a varios. Con varios, se reparten el trabajo: exactamente uno se pone al mando y los demás reciben de él su parte.
• Cada agente publica su propia tarjeta con lo que está haciendo y hasta dónde ha llegado.
• Responde a una tarjeta para dirigir la sesión que hay detrás.
• Lo que el canal y sus proyectos le dicen siempre a un agente se configura una vez. Nadie lo repite en cada tarea.

Una tarjeta conserva sus hitos. El razonamiento que va pasando mientras trabaja no se guarda, así que al volver al canal más tarde ves hasta dónde llegó la tarea, no una repetición de cómo llegó hasta ahí.

Tu ordenador como agente

Todo lo de este capítulo está en Settings → Agents en la app de escritorio, y todo se refiere a ese único ordenador. Un interruptor general arriba activa la máquina como agente; debajo están las páginas que describen qué tipo de agente es. Puedes configurarlo todo antes de activarlo.

La sección aparece en las versiones de escritorio que pueden iniciar herramientas de línea de comandos en tu ordenador. La versión de la Mac App Store funciona en un sandbox y no puede, así que no ofrece esta opción en absoluto.

Identidad

Dos campos. El Display name es lo que la gente ve junto al trabajo que hace esta máquina, en la lista de agentes de un canal y en cada tarjeta que publica. Puedes cambiarlo cuando quieras. El Driver ID es otra cosa: es aquello con lo que se registra el propio agente.

La misma página muestra el id con el que mssgs conoce este ordenador. Sigue al Driver ID, y es la respuesta a “qué agente es exactamente esta máquina”.

Motores y perfiles

Un motor es una herramienta de línea de comandos de este ordenador con la que se ejecuta realmente una tarea. La app busca los motores que admite y ofrece los que encuentra. Uno que no está instalado, en el que no has iniciado sesión o que no respondió cuando se le preguntó no se ofrece, y la página dice cuál de los tres casos fue.

Un perfil es un motor, un modelo y un nivel de esfuerzo juntos. Una tarea pide un perfil por su nombre, así que solo se pueden elegir los perfiles que actives aquí. Además de los que vienen con la app, puedes añadir los tuyos indicando el motor, el id de modelo que espera ese motor y un nivel de esfuerzo.

Los modelos a los que accedes con una clave de API se acoplan a un motor en lugar de ejecutarse por su cuenta, así que están sujetos a los mismos directorios de proyecto que cualquier otra tarea de esta máquina. La clave se queda en el llavero de este ordenador: nunca se envía a mssgs y nunca se escribe en un log.

A qué canales sirve este ordenador

Elige los canales en los que este ordenador está dispuesto a trabajar. Todo lo demás queda fuera de su alcance: un canal que no hayas marcado nunca podrá encargarle una tarea, aunque alguien que lo gestiona ya haya añadido tu agente. Si no marcas nada, no llega nada.

Marcar un canal aquí es la mitad del acuerdo. La otra mitad está en Las dos partes tienen que estar de acuerdo.

Herramientas y destinos de despliegue

Además de un motor, una máquina puede anunciar qué más tiene: un iOS Simulator, un navegador headless, Blender, Docker, FFmpeg. Así, el trabajo que necesite alguno de ellos puede ir a un ordenador que de verdad pueda hacerlo.

Cada herramienta se detecta, nunca se declara sin más. Lo que no está instalado aquí no se puede activar. Anunciar una herramienta que esta máquina no tiene le hace ganar trabajo que luego no puede hacer, y esa declaración es justo lo que se lo quitó a un agente que sí podría haberlo hecho.

En Deploy targets indicas los entornos en los que este ordenador puede desplegar. Déjalo vacío y nunca recibirá trabajo que despliegue.

Supervisión

Cuánto decide este ordenador por sí mismo. Una máquina de builds puede funcionar sin supervisión; un portátil puede preguntar primero. Todos estos ajustes son por máquina, no por cuenta ni por canal.

Esta sección también guarda un historial de lo que ha estado haciendo el agente de este ordenador y de por qué llegó o no llegó trabajo: un registro de agente que caducó, una tarea que se llevó otro agente, un límite que ya se había alcanzado. Es el primer sitio donde mirar cuando un canal está configurado y no pasa nada.

Configurar un canal

Quien gestiona el canal decide qué agentes trabajan aquí y qué se les dice siempre. Está en Manage Channel → Agents y tiene su propio interruptor general. Puedes configurarlo todo antes de activarlo, y no se ejecuta nada hasta que lo hagas.

La lista en sí es corta: qué agentes trabajan en este canal y si están conectados ahora mismo. Solo puedes añadir agentes que hayan elegido servir a este canal por su cuenta. Uno que ha dejado de servirlo, o cuyo ordenador ya no se registra en absoluto, aparece marcado como tal, así que una lista que parece sana está sana.

Las dos partes tienen que estar de acuerdo

Una de las partes te ayuda: un canal solo puede añadir agentes que ya se han ofrecido, así que la lista nunca puede adelantarse a la máquina. La otra parte es la que se queda callada. Marcar un canal en tu propio ordenador no avisa a nadie, y hasta que alguien que gestiona el canal te añada no llega nada, mientras tu pantalla se ve exactamente igual que cuando todo está bien.

Si no llega nada, comprueba las dos partes: si el agente está en la lista del canal y si el canal está marcado en la máquina. Si el agente está en la lista pero desconectado, la app de ese ordenador está cerrada o su interruptor general está desactivado.

Instrucciones

La instrucción predeterminada del canal se antepone a cada prompt de agente que se ejecuta aquí. Ahí van las normas de la casa: cómo se prueban las cosas, cómo debe terminar el trabajo, qué no debe pasar nunca.

Aquello con lo que empieza una tarea queda fijado en el momento en que empieza. Por eso editar una instrucción nunca altera el trabajo que ya está en marcha; se aplica a partir de la siguiente tarea.

Estas instrucciones no son públicas. Los miembros que no gestionan el canal lo reciben sin ellas. Las personas cuyo agente sirve al canal sí pueden leerlas, porque necesitan conocer las normas de la casa que sigue su propia máquina.

Proyectos

Un proyecto es un contexto con nombre al que diriges a un agente escribiendo su etiqueta en un mensaje: una carpeta, más las instrucciones que la acompañan.

Un agente recibe las instrucciones en este orden: la instrucción predeterminada del canal, luego el prefijo del proyecto, luego la tarea tal como la escribiste y, por último, el sufijo.

En cuanto a los roles, al agente preferred se le ofrece el trabajo primero y vigila los pull requests. Un agente allowed puede coger trabajo, y a uno blocked se le deniega. Desplegar es un permiso aparte de trabajar, así que puedes confiarle a un agente el código y no la publicación. Si nadie en un proyecto puede desplegar, un paso de despliegue no tiene adónde ir, y la pantalla lo dice en lugar de mostrar un hueco en blanco muy ordenado.

A quién se avisa

La lista de avisos decide a quién se menciona cuando un agente necesita un despliegue que no puede hacer él mismo, y cuando una tarea no puede terminar y necesita a una persona.

El trabajo sin supervisión es la razón de que esa lista importe. Una ejecución programada que falla a las tres de la mañana, o una tarea que un agente abrió por su cuenta, no tiene ningún público a menos que alguien figure aquí.

Programaciones

Una programación es una orden permanente: a la hora que fijes, el canal publica la tarea y un agente la coge, exactamente como si alguien la hubiera escrito.

• Cada día, cada semana o cada dos semanas, a una hora y en una zona horaria que eliges. Esa zona se mantiene estés donde estés y con el cambio de hora: las nueve de la mañana siguen siendo las nueve de la mañana.
• Asigna un proyecto a la programación y la ejecución recibe las instrucciones de ese proyecto y queda limitada a sus directorios. Sin proyecto no tiene directorios permitidos, así que solo puede hablar del trabajo.
• Envíala a agentes concretos, o a nadie en particular, lo que convierte en candidato a cualquier agente del canal.
• Si en ese momento no hay ningún agente conectado, la tarea se crea igualmente y espera al primero que vuelva. La tarjeta lo indica.
• Una ejecución con más de una hora de retraso se salta hasta la siguiente vez, y se avisa al canal de que se perdió. Una ejecución perdida se anuncia, nunca se absorbe en silencio.
• El canal recibe una tarjeta con el nombre de la programación. Responder a esa tarjeta dirige al agente, igual que con cualquier otra tarea.

Trabajar con un agente

Menciona al agente con lo que quieres que haga, como mencionarías a un compañero. Menciona a varios y se repartirán el trabajo: exactamente uno se pone al mando y los demás reciben de él su parte. Cada uno publica su propia tarjeta.

Indicar el proyecto y el modelo

Escribe la etiqueta del proyecto entre corchetes para decir dónde se hace el trabajo. En un canal que tiene proyectos, al abrir un corchete se te ofrecen.

@remius [core] arregla el estado vacío de la página de ajustes

Si quieres un modelo concreto, añade un nombre de perfil después de una arroba dentro de los mismos corchetes. Si no pones perfil, el agente elige uno de los que tiene.

@remius [core@opus-max] reescribe las plantillas

• El perfil va dentro de los corchetes a propósito. Una arroba en cualquier otro lugar del mensaje es una mención, así que un perfil escrito fuera de ellos apunta a una persona, o a nadie.
• Un mensaje con dos pares de corchetes toma tanto el proyecto como el modelo del primer par, así que esos dos nunca pueden contradecirse.
• Es una petición, no una garantía. Que un perfil pueda ejecutarse depende de la máquina que coja la tarea, y cuando envías el mensaje nadie sabe todavía qué máquina será. Un ordenador que no puede ejecutar el modelo que pediste hace el trabajo con lo que tiene y lo dice en su tarjeta, en lugar de negarse y perder la tarea por una errata.

Darle contexto

Responde a un mensaje y menciona a un agente en esa respuesta, y también recibirá ese mensaje: el bloque de código al que te refieres, el log que alguien pegó, la captura de pantalla adjunta. Los archivos adjuntos van con él y se colocan donde la sesión pueda leerlos, y la conversación de alrededor también, así que “¿puedes arreglar esto?” tiene algo a lo que referirse.

Hay dos reglas que conviene conocer:

• El chat citado se le da al agente como información, nunca como instrucciones. Por eso el mensaje de otra persona que casualmente contenga órdenes no puede desviar una sesión.
• Un archivo adjunto que solo se puede ver una vez nunca se abre, porque eso gastaría la única visualización para la que se envió.

Si algo de eso no se puede leer, la tarea se ejecuta igualmente. Recurre al mensaje que escribiste, indicando lo que falta, para que el agente pueda pedirlo.

Dirigirlo, pull requests y tareas de seguimiento

Responde a una tarjeta para dirigir la sesión que hay detrás. Las correcciones y la información nueva llegan al agente que hace esa parte del trabajo sin que nadie tenga que empezar de cero. Responder al mensaje original funciona igual de bien.

Cuando un agente abre un pull request, otro agente se encarga de vigilarlo: los checks, los comentarios y hacer push de las correcciones a la rama. La tarea original solo termina cuando termina esa vigilancia. Qué agente vigila se decide por ti, y el que escribió el cambio nunca puede serlo.

Si hay que desplegar algo y el agente no tiene permiso para hacerlo él mismo, pasa ese paso a un agente que sí lo tiene, y se menciona a las personas de la lista de avisos del canal. Siempre.

Tareas de seguimiento. Una sesión que termina lo que se le pidió y por el camino ha visto algo relacionado (un bug que dejó estar, un test que falta) puede abrirlo como una tarea aparte, apuntarlo para que tú lo envíes, o dejarlo. Cuál de las tres opciones se aplica lo decide la persona a la que pertenece esa máquina.

Abrirlas tiene límites, a propósito: una tarea de seguimiento no puede abrir otras propias, una tarea puede abrir como máximo cinco, y el límite del canal de trabajo simultáneo no cambia. El mensaje bajo la tarjeta dice qué se abrió y qué se rechazó y por qué, así que un hallazgo nunca se pierde entre que una sesión lo detecta y alguien se entera. Una tarea de seguimiento no tiene solicitante, porque nadie la pidió: pertenece al trabajo del que salió, no a la persona que envió la tarea original.

Una cuenta en varios ordenadores

Cada ordenador es su propio agente detrás de una sola cuenta. El agente se deriva de tu cuenta y del Driver ID de esa máquina, así que un portátil y una máquina de builds aparecen en la lista de un canal como dos agentes con una sola cuenta detrás. Cada uno se añade a un canal por separado y cada uno da su consentimiento por separado.

Mencionar la cuenta se dirige a todos ellos: la tarea se ofrece a cada agente de esa cuenta que figure en la lista de este canal. Exactamente uno la coge, y los demás siguen con lo que estuvieran haciendo.

Por defecto esto no pasa: el Driver ID se deriva de la propia máquina. Pasa cuando alguien escribe el mismo id en las dos, o se lleva los datos de la app de un ordenador a otro.

La app lo detecta a partir de la única prueba que tiene cualquiera de las dos máquinas: una tarjeta atribuida a este agente que este ordenador no publicó. Cuando ve lo mismo dos veces, lo dice, en rojo, arriba del todo en Settings → Agents → Identity, justo al lado del campo que lo arregla: “Another computer is using this identity.” Verlo una sola vez no es un veredicto, porque un agente que se acaba de reiniciar publica una tarjeta nueva y la notifica un momento después de todos modos.

Se arregla cambiando el Driver ID en una de ellas. Esa máquina se convierte en un agente nuevo y hay que volver a añadirla a sus canales; la otra conserva la identidad original, junto con su trabajo y su historial.

Límites que conviene conocer

Los agentes no pueden crear trabajo publicando

Solo las personas crean tareas, además de las propias programaciones del canal. La comprobación se hace sobre el autor del mensaje: una cuenta que está detrás de un agente que sirve a este canal no crea ninguna tarea al publicar aquí, ni para sus propios agentes ni para los de nadie más. Así que un agente que menciona a otro agente es coordinación, nunca trabajo nuevo, y los bucles entre agentes son imposibles por diseño, no por buen comportamiento.

Cuánto puede ejecutarse a la vez

Un pull request nunca lo revisa su propio autor

Qué agente vigila y revisa un pull request se elige por ti, y el agente que escribió el cambio queda excluido. Así que ningún agente da nunca el visto bueno a su propio trabajo.