Tu agente arranca cuando
pasa algo de verdad
Un disparador responde a una sola pregunta: ¿cuándo arranca este agente? Una tarea programada responde con una hora. Un disparador webhook responde con un evento venido de fuera. Se abre una pull request, se rompe una build, salta una alerta, y el agente ya está trabajando.
AgentsRoom le da a cada disparador una URL pública y un secreto de firma. Pega la URL en GitHub, GitLab, Slack, Linear, Sentry o cualquier cosa capaz de enviar un POST JSON. Llega la llamada, se verifica la firma, el payload se convierte en variables de tu prompt, y un agente real arranca en tu proyecto, con su terminal y su transcripción.
Un disparador, una URL pública. Llega el evento, se verifica la firma, el payload se convierte en variables del prompt, y un agente arranca en tu proyecto.
Las tareas programadas resolvían la mitad del problema. Ya puedes pedirle a un agente que revise las pull requests todas las mañanas a las 8. Pero casi todo el trabajo que le confiarías a un agente no ocurre a las 8: ocurre cuando alguien abre una pull request, cuando la build se pone en rojo, cuando un cliente reporta un bug a las 2 de la tarde.
Hasta ahora, la única forma de atrapar eso era poner a un agente a vigilar: lanzarlo en un intervalo corto, hacerle consultar la API, preguntar «¿algo nuevo?», y pagar tokens por la respuesta «no» varios cientos de veces al día. Sale caro, reacciona lento y se vuelve inmanejable en cuanto quieres vigilar tres repositorios.
Un disparador webhook le da la vuelta a todo eso. Es el servicio el que te avisa. AgentsRoom te da una URL, la pegas en GitHub, GitLab, Slack, Linear, Sentry o tu CI, y no se ejecuta nada hasta que ese servicio llama. Cuando llama, el agente arranca con el evento ya en su prompt. Cero tokens cuando el día está tranquilo, y un agente encima del asunto en segundos cuando no lo está.
Por qué un evento gana a un bucle de sondeo
Dejas de pagar por el silencio. Un agente que revisa un repositorio cada cinco minutos consume una vuelta de contexto completa cada cinco minutos, y casi todas esas vueltas no encuentran nada. Un disparador no consume absolutamente nada hasta que llega el evento.
La reacción es inmediata. Ningún intervalo que ajustar, ninguna ventana en la que una pull request espere once minutos porque el sondeo acaba de pasar. El agente arranca con la llamada, así que la revisión ya está ahí cuando el autor recarga la página.
El evento llega con sus datos. El payload se convierte en variables que metes directamente en el prompt: el título, el autor, la URL, el número, la rama, o todo el JSON en bruto. El agente no tiene que ir a buscar qué lo despertó.
Es el mismo panel que ya conoces. Los disparadores mantienen la lista, el interruptor de encendido y apagado, el historial por ejecución, la elección del agente y el alcance por máquina de las tareas programadas. Un webhook es solo otra respuesta a «cuándo se dispara esto».
Un disparador, dos formas de dispararse
El panel lleva las dos. Elige la que corresponde a lo que estás esperando.
Programado
El modo original, sin cambios. Cada N minutos, cada hora, cada día, cada semana o cada mes, sin ninguna expresión cron que escribir. Para el trabajo que pertenece a un reloj: la revisión de la mañana, la comprobación de dependencias del lunes, el changelog del viernes.
Webhook
El agente espera un evento en lugar de una hora. AgentsRoom te da una URL pública y un secreto de firma, pegas la URL en el servicio, y el disparador salta cuando ese servicio envía su POST. Para el trabajo que pertenece a algo que ocurre: una pull request, una build en fallo, un nuevo reporte de bug.
Qué disparar
Eventos reales, y el agente que querrías al otro lado.
Revisar cada pull request en cuanto se abre
Apunta un webhook de GitHub o GitLab al disparador, filtra por la apertura de la pull request, y un agente revisor ataca el diff en segundos. El autor recibe su feedback mientras todavía tiene el cambio fresco en la cabeza.
Investigar automáticamente una build en rojo
Tu CI puede enviar un POST cuando un pipeline falla. El disparador lanza un agente con la rama y la URL de la ejecución en su prompt, así que lee el job que se rompió y vuelve con una causa en lugar de con un indicador en rojo.
Triar un crash en cuanto se reporta
Conecta una alerta de Sentry a un disparador. Una nueva excepción en producción lanza un agente backend con el título del error y la URL del ticket, así que el primer vistazo al stack trace ocurre antes de que nadie abra el dashboard.
Lanzar un agente desde Slack
Un slash command o un webhook saliente de Slack pueden llamar a la URL del disparador. Alguien escribe la petición en un canal, el payload aterriza en el prompt, y el agente la recoge en el proyecto correcto.
Encuadrar un ticket nuevo en cuanto se crea
Un ticket creado en GitHub, GitLab o Linear lanza un agente de producto que lee el reporte, hace las preguntas que faltan y lo convierte en algo que un desarrollador puede tomar.
Ejecutar una pasada de QA después de cada despliegue
Tu pipeline de despliegue envía un POST cuando sale una release. El disparador lanza un agente de QA que ejercita la app contra la versión que acaba de publicarse, en lugar de en un horario que no tiene nada que ver con las releases.
Escribir las notas de versión al crear un tag
Un tag empujado, una release publicada, y un agente de documentación convierte los commits en notas legibles. El evento lleva el nombre del tag, así que el agente sabe exactamente qué rango tiene que resumir.
Cualquier cosa capaz de enviar JSON
No hay ninguna lista de integraciones que esperar. Un cron en un servidor, un paso de Zapier, una herramienta de monitorización, tu propio backend: si sabe enviar un POST firmado a una URL, sabe lanzar un agente en tu proyecto.
Cómo funciona un disparador webhook, paso a paso
De un formulario vacío a un agente que reacciona a producción, en un par de minutos.
Crea un disparador
Abre el panel Disparadores en tu proyecto y crea uno nuevo. La misma lista, el mismo interruptor de encendido y apagado, el mismo historial que una tarea programada, porque es el mismo panel.
Pásalo a Webhook
Elige Webhook en lugar de Programado. AgentsRoom genera una URL pública para este disparador y un secreto de firma justo al lado. El secreto se regenera cuando quieras, para cortarle el acceso a quien tuviera el antiguo.
Pega la URL en el servicio
Suéltala en un webhook de GitHub o GitLab, una app de Slack, una integración de Linear o Sentry, o tu CI. Dale también el secreto de firma al servicio, para que sus llamadas se puedan verificar.
Filtra lo que debe dispararse de verdad
Un repositorio envía muchos eventos. Añade una condición opcional sobre el payload, por ejemplo action igual a opened, y todo lo demás se ignora. Pon un límite anti-ráfaga para que un servicio ruidoso no lance veinte agentes en un minuto.
Mete el evento en tu prompt
Escribe el prompt con las variables del evento: el título, el autor, la URL, el número, la rama, o todo el payload. Se resuelven cuando el disparador salta, exactamente como las variables de fecha y hora que ya soportan las tareas programadas.
Reenvía la última llamada y actívalo
El editor muestra la última llamada que recibió el disparador, con el JSON en bruto incluido, y la reenvía con un clic. Un webhook se conecta mirándolo, no adivinando, y en cuanto está bien enciendes el disparador.
La fila de servicios son atajos, no una lista blanca. El editor lo dice justo debajo del selector, y por eso la primera entrada es Any service (JSON): funciona cualquier cosa capaz de enviar un cuerpo JSON por POST. Elegir GitHub, GitLab, Slack, Linear o Sentry añade exactamente dos cosas, su propia cabecera de firma que verificar y los campos de su payload ya asociados a las variables del evento. Nada se rechaza por no estar en la lista.
Los chips de variables no son documentación, son botones: haz clic en uno para insertarlo en el prompt, y los que la última llamada rellenó de verdad aparecen resaltados. Debajo está la última llamada que recibió el disparador, así que escribes el filtro y el prompt contra un payload real que puedes ver, la reenvías, y solo enciendes el disparador cuando la ejecución sale bien.
- El evento llega a la URL de tu disparador
El servicio envía su JSON. AgentsRoom comprueba la firma con tu secreto y rechaza cualquier llamada sin firmar, y después aplica tu filtro si has puesto uno.
- Espera si no hay nadie
Tu máquina puede estar apagada. El evento se guarda durante un máximo de una semana y se reenvía en el siguiente arranque en lugar de perderse: el mismo modelo de recuperación que ya usan las tareas programadas.
- Una máquina lo toma, y solo unaMac de la oficinaMac de casaMáquina de build
Si varios ordenadores tienen el proyecto abierto, el primero que coge el evento lo bloquea. Los demás ven que ya está tomado y siguen adelante, así que un mismo evento nunca produce dos agentes.
- El agente se ejecuta, una vez
Se abre un agente real en el proyecto, con el rol, el proveedor y el modelo que elegiste, su propio terminal, su vista de conversación y una transcripción archivada que puedes releer más tarde.
Una URL pública que no es una puerta abierta
La URL es accesible desde Internet, así que el disparador decide qué acepta antes de que arranque nada.
Cada llamada va firmada
AgentsRoom verifica cada llamada con tu secreto antes de que arranque nada: X-Hub-Signature-256 para GitHub, X-Slack-Signature para Slack, el token compartido X-Gitlab-Token para GitLab, y un HMAC simple del cuerpo en bruto para Linear, Sentry y las fuentes genéricas. Una llamada sin firma se rechaza, así que conocer la URL no basta para lanzar un agente en tu máquina.
Rota el secreto cuando quieras
El secreto de firma se muestra en el editor y se regenera ahí mismo. Las llamadas antiguas dejan de ser válidas de inmediato, que es justo lo que quieres el día en que se desconecta un servicio o un secreto se filtra en un log.
Filtra sobre el payload
Una condición opcional decide si el evento merece un agente. Dispararse solo si action vale opened, solo en una rama, solo para una etiqueta. Todo lo que no encaja se descarta sin lanzar nada.
Protección anti-ráfaga
Como mucho una ejecución por ventana de tiempo. Un servicio que envía treinta eventos en diez segundos no lanza treinta agentes: las llamadas de esa ventana se agrupan y una sola ejecución las cubre.
El payload se convierte en tu prompt
El JSON que envía el servicio se convierte en variables que escribes directamente en el prompt. Se resuelven en el momento del disparo, como las variables de fecha y hora que ya usan las tareas programadas.
Escribes el prompt una vez, y cada ejecución recibe los datos del evento que la disparó.
{{event.title}}El título del evento: el título de la pull request, el del ticket, el nombre de la alerta.{{event.author}}Quién lo provocó: el autor de la pull request, la persona que abrió el ticket.{{event.url}}El enlace al evento, para que el agente pueda abrir la pull request o la alerta.{{event.number}}El número de la pull request o del ticket, cuando el servicio envía uno.{{event.branch}}La rama a la que afecta el evento, para un push, una pull request o una build en fallo.{{payload}}Todo el JSON en bruto, para lo que no cubren las variables con nombre.
Review pull request #{{event.number}} "{{event.title}}" opened by {{event.author}} on branch {{event.branch}}. Read the diff at {{event.url}} and reply with the risky parts first.Los nombres de las variables se escriben entre dobles llaves en el campo del prompt, exactamente como las variables de fecha y hora de una tarea programada.
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.stateevent.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.stateevent.actionevent.titleevent.bodyevent.authorevent.channelevent.urlevent.teamevent.actionevent.numberevent.titleevent.bodyevent.authorevent.assigneeevent.stateevent.priorityevent.urlevent.teamevent.actionevent.titleevent.bodyevent.levelevent.projectevent.urlevent.countevent.actionevent.titleevent.bodyevent.authorevent.urlevent.idQué se ejecuta en realidad, y dónde
El mismo modelo de ejecución honesto que las tareas programadas, extendido a los eventos.
De dónde vienen los eventos
Cualquier cosa capaz de enviar un POST firmado con un cuerpo JSON puede lanzar un agente. Estos son los que la gente conecta primero.
Tu CI, tu backend, lo que sea
Un paso de pipeline, una herramienta de monitorización, un servicio interno, un script de shell con curl. No hay ninguna integración que pedir: un POST con un cuerpo JSON y una firma, ese es todo el contrato.
GitHub y GitLab
Pull requests y merge requests abiertas, revisadas o fusionadas, tickets creados, pushes, releases, workflows en fallo. La fuente clásica, y la que tiene el payload más útil.
Slack
Un slash command o un webhook saliente convierte un mensaje de un canal en una ejecución de agente en el proyecto correcto. Las firmas de Slack se verifican con X-Slack-Signature.
Linear y Sentry
Un ticket movido a otra columna, una nueva excepción en producción, una alerta de regresión. La herramienta de seguimiento se dispara, el agente arranca con el ticket o el error en su prompt.
La otra mitad del mismo panel
Los disparadores y las tareas programadas son una sola funcionalidad con dos respuestas a la misma pregunta. Una tarea programada es un disparador cuyo evento es un reloj. Un disparador webhook es una tarea programada cuyo horario es el mundo exterior. Viven en la misma lista y comparten la misma configuración de agente, el mismo interruptor de activación, el mismo historial de ejecuciones y el mismo alcance por máquina.
Así que eliges por trabajo y no por herramienta. La auditoría de dependencias se queda el lunes por la mañana, porque nada de fuera anuncia que un paquete se ha quedado obsoleto. La revisión de pull requests pasa a webhook, porque GitHub ya sabe el segundo exacto en el que debe ocurrir. La página de tareas programadas cubre el lado del reloj de la familia.
Ver las tareas programadas, el lado del reloj del mismo panelFAQ
¿Qué es un disparador webhook en AgentsRoom?
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.
¿En qué se diferencia de una tarea programada?
Solo cambia la pregunta «cuándo se dispara esto». Una tarea programada se dispara con un reloj: cada N minutos, cada hora, cada día, cada semana o cada mes. Un disparador webhook se dispara con un evento de fuera. 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.
¿Por qué no poner simplemente a un agente a consultar la API?
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.
¿Es prudente exponer la URL del disparador?
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, y un HMAC simple del cuerpo en bruto para Linear, Sentry y las fuentes genéricas. 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.
¿Puedo dispararlo solo con algunos eventos?
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.
¿Qué pasa si AgentsRoom está cerrado cuando llega el evento?
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.
Tengo el proyecto abierto en dos ordenadores. ¿El agente se va a ejecutar dos veces?
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.
¿Qué puedo meter en el prompt desde el evento?
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.
¿Cómo sé si mi webhook está bien conectado?
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.
¿Qué servicios son compatibles?
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.
¿Es un editor visual de escenarios en varios pasos?
No, y no pretende serlo. Un disparador tiene un solo trabajo: decidir cuándo arranca un agente y entregarle el evento. La parte de varios pasos es el agente en sí, que lee el código, ejecuta las herramientas y hace el trabajo. Si quieres que varios agentes se pasen el trabajo entre ellos, eso son los equipos de agentes, no un lienzo de escenarios.
¿Puede AgentsRoom enviar webhooks hacia otros servicios?
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.
Combina bien con
Tareas programadas
El lado del reloj del mismo panel. Cada N minutos, cada hora, cada día, cada semana o cada mes, sin ninguna expresión cron que escribir.
Tablero de backlog
Arrastras un ticket a una columna y un agente lo toma. Un disparador hace lo mismo, salvo que es un evento externo el que arrastra.
Equipos de agentes
Agentes Dev, QA y PM que se pasan el trabajo. Apunta un disparador a un equipo y un evento lanza toda la rutina.
AgentsRoom MCP
Las herramientas con las que un agente lee el backlog, la memoria y la biblioteca de prompts. Un agente disparado las tiene como cualquier otro.
Notificaciones de agentes
Entérate en el segundo en que salta un disparador, en el escritorio y en tu teléfono, con un toque para abrir el agente que ha lanzado.
Flota remota
Varias máquinas en una sola cuenta. Fija un disparador a la que debe responderlo, y solo esa máquina ejecuta el agente.
Deja de sondear. Empieza a reaccionar.
Descarga AgentsRoom, pega una URL en GitHub, GitLab, Slack, Linear o Sentry, y deja que el evento lance el agente. No se ejecuta nada mientras no pasa nada.
App complementaria: supervisa tus agentes en movimiento
Usa Claude, Codex, Antigravity CLI u otro proveedor de IA.
Envía bugs y peticiones directamente a tu backlog público.
Un vistazo a AgentsRoom en acción.