Tu agente arranca cuando
pasa algo de verdad

Es un disparador que lanza un agente de IA cuando un servicio externo le envía un evento, en lugar de hacerlo a una hora fija. AgentsRoom le da al disparador una URL pública y un secreto de firma; pegas la URL en GitHub, GitLab, Slack, Linear, Sentry o cualquier herramienta capaz de enviar un POST JSON. Cuando ese servicio llama, se verifica la firma, se aplica tu filtro opcional, y un agente arranca en tu proyecto con el payload ya disponible como variables del prompt.

Solo cambia la pregunta «cuándo se dispara esto». Una tarea programada se dispara con un reloj (cada N minutos, cada hora, diaria a una o varias horas del día, semanal o mensual) o según la ventana de cuota de tu suscripción de IA (cuando vuelve la cuota, o antes de que se reinicie). Un disparador webhook se dispara con un evento de fuera. Un disparador a petición no se dispara con nada: espera a que pulses su botón. Todo lo demás es común: la misma lista, el mismo interruptor de encendido y apagado, la misma configuración de agente, el mismo historial por ejecución, el mismo alcance por máquina.

Porque el sondeo en bucle gasta tokens en cada vuelta, y casi ninguna vuelta encuentra nada. Un agente que revisa un repositorio cada cinco minutos ejecuta una vuelta completa cada cinco minutos para responder «no». Un disparador webhook no consume nada mientras no pasa nada, y reacciona en segundos cuando pasa algo. Ese es todo el argumento económico de la funcionalidad.

La URL por sí sola no basta para lanzar nada. Cada llamada tiene que demostrar que viene del servicio que tiene tu secreto: X-Hub-Signature-256 para GitHub, X-Slack-Signature para Slack, el token compartido X-Gitlab-Token para GitLab, un HMAC simple del cuerpo en bruto para Linear y Sentry, y una firma que también cubre una marca de tiempo y un identificador de entrega para las fuentes genéricas, de modo que una llamada interceptada no puede volver a enviarse. Una llamada sin cabecera de firma se rechaza, nunca se deja pasar. El secreto se muestra en el editor y se puede regenerar en cualquier momento, lo que invalida de inmediato lo que estuviera usando el antiguo.

Sí. Un repositorio envía muchos más eventos de los que merecen un agente, así que un disparador acepta una condición opcional sobre el payload, por ejemplo action igual a opened. Los eventos que no encajan se ignoran y no se lanza nada. También hay un límite anti-ráfaga: como mucho una ejecución por ventana de tiempo, agrupando las llamadas que llegan dentro de esa ventana.

El evento se pone en cola en el servidor y se reenvía la próxima vez que arrancas la app, así que se ejecuta tarde en lugar de nunca. Los eventos en cola se guardan una semana, lo que cubre un portátil cerrado durante un fin de semana largo sin reenviarte un mes de trabajo obsoleto cuando vuelves. Es el mismo modelo de «en la app más recuperación» que usan las tareas programadas. Los disparadores webhook no ejecutan tu agente en la nube: el agente siempre se ejecuta en tu máquina, en tu proyecto.

No. Un evento se consume una sola vez. La primera máquina que lo coge lo bloquea, y las demás ven que ya está tomado y lo saltan. También puedes fijar un disparador a máquinas concretas, exactamente como una tarea programada, si quieres que un ordenador en particular se encargue de él.

El payload se convierte en variables que escribes directamente en el campo del prompt, entre dobles llaves: event.title, event.author, event.url, event.number, event.branch, y payload para todo el JSON en bruto. Se resuelven en el momento en que el disparador salta, igual que las variables de fecha y hora de una tarea programada.

El editor muestra la última llamada que recibió el disparador, incluido el cuerpo JSON en bruto, y te deja reenviarla con un clic. Así ajustas el filtro y el prompt contra un payload real que puedes ver, y la reenvías hasta que la ejecución sale bien, en lugar de empujar commits de prueba para averiguarlo.

Cualquier servicio capaz de enviar un POST firmado con un cuerpo JSON. GitHub, GitLab, Slack, Linear y Sentry son los que la gente conecta primero porque sus payloads son ricos, pero no hay ninguna lista cerrada: un job de CI, una herramienta de monitorización, tu propio backend o un curl en un script de shell funcionan exactamente igual.

No, y no pretende serlo. Un disparador tiene un solo trabajo: decidir cuándo arranca una ejecución y entregarle el evento. La parte de varios pasos pertenece a aquello a lo que apunta. Suele ser un agente solo, que lee el código, ejecuta las herramientas y hace el trabajo; cuando quieres que varios agentes se pasen el trabajo entre ellos, apunta el disparador a un equipo de agentes y el evento lanza todo el pipeline, puertas de calidad y bucles de feedback incluidos. Lo que aquí nunca dibujas es un lienzo de escenarios hecho de cajas y flechas alrededor de una API.

Los disparadores son solo entrantes: AgentsRoom recibe eventos, no los emite. Si quieres que un agente llame a un servicio externo al final de una ejecución, ese es el trabajo del propio agente, con las herramientas y los servidores MCP que le hayas dado.

Sí, con una ejecución restringida. Un payload escrito por un desconocido puede esconder instrucciones dirigidas al agente, así que AgentsRoom no confía en el prompt para contenerlas: en una ejecución restringida, la propia CLI del agente deniega el acceso al shell, a la web y a todas las herramientas de AgentsRoom, mantiene los archivos del proyecto en solo lectura y solo llama a las herramientas MCP que hayas permitido. Dale al disparador su propia credencial a través del servidor MCP que la necesita, y el agente puede publicar su revisión sin ver nunca el token. Claude Code y Codex la admiten; las demás CLI se niegan a arrancar una ejecución así.

Sí. Además de un agente o un equipo, un disparador puede ejecutar una acción del tablero: Iniciar el siguiente ticket de Por hacer. Hace exactamente lo mismo que el botón del tablero, toma el primer ticket de Por hacer saltándose los que siguen bloqueados por otro, y lo inicia con su propio agente o equipo. El disparador en sí no tiene prompt ni hace ninguna llamada a la IA, así que una pull request fusionada, una ejecución de CI en verde o un horario pueden mantener en marcha un pipeline de un ticket, un agente sin pagar un turno de agente cuyo único trabajo sería pulsar ese botón.