Pásale trabajo a un agente desde Slack y Teams

Un hilo en #payments, a media mañana. Alguien le pregunta a @Archyl qué llama al webhook sender, y el bot responde: los containers Checkout y Billing, ambos a través de la Payments API. Dos mensajes después llega la frase con la que terminan todos estos hilos: «deberíamos añadirle reintentos a eso, ¿alguien se lo puede quedar?»

Luego el hilo se queda en silencio. Alguien tiene que abrir Archyl, buscar el proyecto, elegir un perfil de agente y volver a escribir una tarea que ya existe, palabra por palabra, tres mensajes más arriba.

Desde junio, el bot de Archyl responde preguntas en Slack y Microsoft Teams. Desde hoy también puede actuar. El mismo hilo puede pasarle el trabajo a un agente gestionado:

@Archyl run [Payments API] add retries with backoff to the webhook sender

El agente se ejecuta como la persona que escribió eso, y el bot sigue la ejecución en el hilo hasta que hay una pull request.

Un hilo, de principio a fin

Este es el resto de ese intercambio. Los mensajes de Archyl son los formatos que el bot publica de verdad. Los nombres, la pregunta y la pull request son ejemplos.

Marie:   @Archyl run [Payments API] add retries with backoff to the webhook sender

Archyl:  🚀 Agent `backend-fixer` started on Payments API. Follow it in Archyl
         — I'll post here when it needs you or when it's done.

«Follow it in Archyl» enlaza a la página de la ejecución, donde el plan se va rellenando como una checklist y cada llamada a una tool aparece en el feed de actividad. Nadie tiene que tenerla abierta.

Veinte minutos después, el agente se topa con una decisión que no debería tomar solo:

Archyl:  @Marie ❓ The agent has a question:
         > Should retries also cover 4xx responses from receivers, or only
         > 5xx and timeouts?
         Answer in Archyl.

Marie entra, elige «only 5xx and timeouts» entre las respuestas sugeridas y vuelve a lo que estaba haciendo. Cuando la ejecución termina:

Archyl:  @Marie ✅ The agent finished and opened a pull request:
         https://github.com/acme/payments-api/pull/412
         See the run.

Si el perfil tiene activado Revisar el plan primero, hay una parada más antes de cualquier cambio en el código: «📋 The agent proposed a plan and is waiting for your review», con un enlace. Si la ejecución falla o alcanza su límite de tiempo o de coste, el último mensaje dice por qué y enlaza la pull request en borrador que contiene el trabajo hecho hasta ese momento.

En Slack, cada una de esas actualizaciones @menciona a la persona que lanzó la ejecución, para que le llegue a sus notificaciones. En Teams, las actualizaciones llegan como respuestas en el mismo hilo, sin mención.

Qué pasó entre esos mensajes

El hilo muestra tres mensajes. La ejecución hizo bastante más, y esa parte es la razón de ser de esta release.

Antes de tocar un archivo, la ejecución abrió una sesión de trabajo sobre los elementos de arquitectura que toca la tarea, en este caso el component webhook sender dentro de la Payments API. Tomó reservas sobre ellos, así que a un desarrollador que más tarde arranque Claude Code sobre el mismo component se le avisa de que alguien ya está trabajando ahí. Su briefing incluía los ADR, las reglas de conformidad y los contratos de API vinculados a esos elementos, además de todo lo que sesiones anteriores recordaban sobre ellos. Cada archivo que escribió pasó por el Guard, que rechaza una escritura que rompe una regla de conformidad crítica. Al terminar, su resumen se convirtió en memoria sobre los elementos a los que pertenecen de verdad los archivos modificados, y cada decisión que registró abrió un Architecture Change Request en borrador para que alguien lo revise.

Nada de eso es específico del chat. Es lo que hace cualquier ejecución de Archyl. Lo que cambia es de dónde viene la petición.

Esa es la apuesta detrás de esta funcionalidad. Un sitio alojado donde ejecutar un agente se está convirtiendo en algo que eliges de una lista: como señalamos hace dos semanas, Anthropic, OpenAI y Cursor ofrecen uno cada uno. Lo que un runtime no conoce es tu sistema: a qué container pertenece el webhook sender, quién es su responsable, qué regla dice que el HTTP saliente pasa por el cliente compartido y qué otro agente está ahí ahora mismo. Ese conocimiento vive en el modelo de arquitectura. El chat es donde se pide el trabajo. Esta release conecta ambos, para que una petición hecha en un hilo llegue con el contexto que un agente necesita para hacerla bien.

Por qué la ejecución se crea como tú

Cuando el bot responde una pregunta, usa los permisos del administrador que conectó el espacio de trabajo. Para leer, funciona. Todo el mundo en el canal obtiene la misma vista de la arquitectura, acotada por canal si lo has limitado.

Actuar es distinto. Una ejecución escribe código y abre una pull request. Si @Archyl run tomara prestados los permisos de quien instaló el bot, cualquiera en un canal de Slack podría hacer que un agente cambiara un proyecto que él mismo no puede editar, y el historial de ejecuciones pondría el nombre del administrador en cada una de ellas.

Por eso las ejecuciones se crean como la persona que escribió el comando, con el límite de su acceso de edición al proyecto. El bot no puede saber quién es un usuario de chat en Archyl hasta que este se lo dice, lo que supone un paso por persona, una sola vez:

1. En Archyl, ve a Perfil → Cuentas de chat y haz clic en Vincular mi cuenta de Slack o Vincular mi cuenta de Microsoft Teams.
2. Envía el comando que aparece, @Archyl connect <code>, en cualquier sitio donde el bot esté presente en esa plataforma.

El código es de un solo uso y válido durante 15 minutos, y lo generaste tú con tu sesión iniciada, que es lo que demuestra que la cuenta de chat es tuya. Slack y Teams se vinculan por separado. @Archyl disconnect elimina el vínculo; el bot sigue respondiendo tus preguntas y deja de lanzar agentes por ti.

Si te saltas esto y escribes run de todos modos, el bot te dice qué falta en lugar de adivinar:

I don't know who you are on Archyl yet, and agents run as the person who asks.
Generate a code in Profile → Chat accounts, then send @Archyl connect <code>.

Cómo se interpreta el comando

@Archyl run [Project name] <task>, con dos partes opcionales.

El proyecto va entre corchetes. Por ahora los corchetes son obligatorios, para que el bot nunca tenga que adivinar dónde acaba el nombre de tu proyecto y dónde empieza la tarea. En un canal limitado a un solo proyecto puedes omitir el proyecto: @Archyl run fix the flaky login test. Un canal limitado a varios proyectos solo acepta proyectos dentro de su alcance. Si pides cualquier otro, el bot responde que no encuentra ese proyecto en el alcance de este canal.

El perfil va antes de la tarea. Sin perfil, la ejecución usa el perfil por defecto de tu organización. Para elegir otro, pon profile:<name> al principio:

@Archyl run [Web] profile:frontend-fixer align the pricing cards

Un nombre de perfil que no existe recibe una respuesta con la lista de los que sí existen.

Todo lo demás se comporta igual que en la app. Necesitas acceso de edición al proyecto. La ejecución cuenta para las ejecuciones de agentes mensuales de tu organización, como una ejecución lanzada desde Hub de Agentes → Ejecuciones (y, como en la app, las organizaciones con su propio proveedor de IA no computan). Si el perfil tiene activado Respetar el trabajo de otros agentes y otro agente tiene una reserva sobre los mismos elementos, el bot responde que el gate de preflight rechazó la ejecución. Si el gate solo avisa, la ejecución queda retenida a la espera de aprobación y el bot te enlaza a ella.

Dos detalles con los que tuvimos cuidado

Un texto no fiable no puede avisar a todo el canal. La tarea, el nombre del proyecto y las preguntas del agente acaban todos citados de vuelta en el canal. Cada uno se escapa para su plataforma antes de publicarse, así que una tarea o una pregunta que contenga <!channel> en Slack, o una mención <at> en Teams, llega como texto plano en lugar de notificar a todo el mundo.

El hilo al que informa una ejecución no es algo que un cliente pueda cambiar. El canal y el hilo en los que publica una ejecución se guardan en el servidor cuando se crea la ejecución, no en sus metadatos, que los clientes de la API pueden escribir. Además, las actualizaciones solo van a un espacio de trabajo conectado a la organización propietaria de la ejecución.

Lo que todavía no hace

La revisión del plan y las respuestas se hacen en Archyl, no en el hilo. El bot te dice que el agente está esperando y enlaza la página de la ejecución. No puedes aprobar un plan ni responder una pregunta desde Slack o Teams. Eso importa más de lo que parece: una pregunta que nadie responde en una hora deja que el agente siga con su propio criterio, y un plan que nadie revisa en una hora hace fallar la ejecución. La @mención está ahí para que esa hora no pase desapercibida.

Los nombres de proyecto tienen que coincidir con exactamente un proyecto. No hay coincidencia aproximada, y si dos proyectos comparten nombre, el bot te pide que renombres uno o que lances la ejecución desde la app.

Las actualizaciones de Teams no te mencionan. Son respuestas en el hilo, así que su visibilidad depende de cómo sigas ese hilo.

Una pull request necesita un host compatible. Las ejecuciones abren pull requests en github.com, gitlab.com y bitbucket.org. Bitbucket no tiene pull requests en borrador, así que una ejecución que falla allí hace push de su rama sin abrir ninguna. Un repositorio en un servidor Git autoalojado no recibe pull request, así que el mensaje final dice que el agente terminó y enlaza la ejecución.

Pruébalo

Lanzar ejecuciones desde el chat requiere agentes gestionados, disponibles en los planes Scale y Custom, y un espacio de trabajo de Slack o Teams conectado. Vincula tu cuenta de chat en Perfil → Cuentas de chat, elige un hilo en el que alguien acabe de pedir algo pequeño y bien definido, y escribe @Archyl run.

La referencia completa, incluido cómo se aplican los permisos y los alcances de canal, está en la documentación, en Lanzar ejecuciones de agentes desde Slack o Teams.

Lecturas relacionadas: el lanzamiento del bot de Slack y Teams, limitar el bot por canal, los agentes gestionados ahora responden ante el harness y seguir y dirigir una ejecución en directo.