Seu agente inicia quando
algo realmente acontece
Um gatilho responde a uma única pergunta: quando este agente inicia? Uma tarefa agendada responde com um horário. Um gatilho webhook responde com um evento do mundo exterior. Uma pull request é aberta, um build quebra, um alerta dispara, e o agente já está rodando.
O AgentsRoom dá a cada gatilho uma URL pública e um segredo de assinatura. Cole a URL no GitHub, GitLab, Slack, Linear, Sentry ou em qualquer coisa capaz de enviar um POST JSON. A chamada chega, a assinatura é verificada, o payload vira variáveis do seu prompt, e um agente de verdade inicia no seu projeto, com seu terminal e sua transcrição.
Um gatilho, uma URL pública. O evento chega, a assinatura é verificada, o payload vira variáveis do prompt, e um agente inicia no seu projeto.
As tarefas agendadas resolveram metade do problema. Você já consegue pedir a um agente que revise as pull requests toda manhã às 8. Mas a maior parte do trabalho que você entregaria a um agente não acontece às 8: acontece quando alguém abre uma pull request, quando o build fica vermelho, quando um cliente relata um bug às 2 da tarde.
Até agora, a única forma de pegar isso era colocar um agente de vigia: rodá-lo em um agendamento curto, fazer com que ele consulte a API, pergunte 'tem algo novo?' e pagar tokens pela resposta 'não' várias centenas de vezes por dia. Isso é caro, demora a reagir e escala mal no instante em que você quer vigiar três repositórios.
Um gatilho webhook inverte a lógica. O serviço avisa você. O AgentsRoom te entrega uma URL, você a cola no GitHub, GitLab, Slack, Linear, Sentry ou no seu CI, e nada roda até esse serviço chamar. Quando ele chama, o agente inicia com o evento já no prompt. Zero tokens enquanto o dia está calmo, e um agente no caso em poucos segundos quando não está.
Por que um evento vence um loop de consulta
Você para de pagar pelo silêncio. Um agente que verifica um repositório a cada cinco minutos queima um turno inteiro de contexto a cada cinco minutos, e quase todos esses turnos não encontram nada. Um gatilho não consome absolutamente nada até o evento chegar.
A reação é imediata. Nenhum intervalo para ajustar, nenhuma janela em que uma pull request fica onze minutos parada porque a consulta acabou de rodar. O agente inicia na chamada, então a revisão já está lá quando o autor atualiza a página.
O evento vem com os dados dele. O payload é convertido em variáveis que você coloca direto no prompt: o título, o autor, a URL, o número, a branch ou todo o JSON bruto. O agente não precisa sair buscando o que o disparou.
É o mesmo painel que você já conhece. Os gatilhos mantêm a lista, o interruptor de ligar e desligar, o histórico por execução, o seletor de agente e o escopo por máquina das tarefas agendadas. Um webhook é só mais uma resposta para 'quando isso dispara'.
Um gatilho, duas formas de disparar
O painel comporta as duas. Escolha a que corresponde ao que você está esperando.
Agendado
O modo original, sem mudanças. A cada N minutos, horária, diária, semanal ou mensal, sem nenhuma expressão cron para escrever. Para o trabalho que pertence a um relógio: a revisão da manhã, a verificação de dependências de segunda, o changelog de sexta.
Webhook
O agente espera um evento em vez de um horário. O AgentsRoom te dá uma URL pública e um segredo de assinatura, você cola a URL no serviço, e o gatilho dispara quando esse serviço envia um POST. Para o trabalho que pertence a algo que aconteceu: uma pull request, um build que falhou, um novo relato de bug.
O que disparar
Eventos reais, e o agente que você quer do outro lado.
Revise cada pull request assim que ela abre
Aponte um webhook do GitHub ou do GitLab para o gatilho, filtre pela abertura da pull request, e um agente revisor começa a analisar o diff em poucos segundos. O autor recebe o retorno enquanto a mudança ainda está fresca na cabeça dele.
Investigue um build vermelho automaticamente
Seu CI pode enviar um POST quando um pipeline falha. O gatilho inicia um agente com a branch e a URL da execução no prompt, então ele lê o job que falhou e volta com uma causa, em vez de um selo vermelho.
Faça a triagem de um crash no instante em que ele é relatado
Ligue um alerta do Sentry a um gatilho. Uma nova exceção em produção inicia um agente de backend com o título do erro e a URL da issue, então a primeira olhada no stack trace acontece antes de alguém abrir o dashboard.
Inicie um agente a partir do Slack
Um slash command do Slack ou um webhook de saída pode bater na URL do gatilho. Alguém escreve o pedido em um canal, o payload cai no prompt, e o agente assume no projeto certo.
Enquadre uma nova issue assim que ela é aberta
Uma issue criada no GitHub, GitLab ou Linear inicia um agente de produto que lê o relato, faz as perguntas que estão faltando e a transforma em algo que um desenvolvedor consegue assumir.
Rode uma passagem de QA depois de cada deploy
Seu pipeline de deploy envia um POST quando uma versão sai. O gatilho inicia um agente de QA que exercita o app contra a versão que acabou de subir, em vez de em um agendamento que não tem nada a ver com os lançamentos.
Escreva as notas de versão na tag
Uma tag enviada, uma release publicada, e um agente de documentação transforma os commits em notas legíveis. O evento carrega o nome da tag, então o agente sabe exatamente qual intervalo resumir.
Qualquer coisa capaz de enviar um POST JSON
Não existe lista de integrações para esperar. Um cron em um servidor, um passo do Zapier, uma ferramenta de monitoramento, o seu próprio backend: se consegue mandar um POST assinado para uma URL, consegue iniciar um agente no seu projeto.
Como um gatilho webhook funciona, passo a passo
De um formulário vazio a um agente que reage à produção, em alguns minutos.
Crie um gatilho
Abra o painel Gatilhos do seu projeto e crie um novo. Mesma lista, mesmo interruptor de ligar e desligar, mesmo histórico de uma tarefa agendada, porque é o mesmo painel.
Mude para Webhook
Escolha Webhook em vez de Agendado. O AgentsRoom gera uma URL pública para esse gatilho e um segredo de assinatura ao lado dela. O segredo pode ser gerado de novo quando você quiser cortar o acesso de quem tinha o antigo.
Cole a URL no serviço
Coloque-a em um webhook do GitHub ou do GitLab, em um app do Slack, em uma integração do Linear ou do Sentry, ou no seu CI. Dê o segredo de assinatura ao serviço também, para que as chamadas que ele envia possam ser verificadas.
Filtre o que deve mesmo disparar
Um repositório envia muitos eventos. Adicione uma condição opcional sobre o payload, por exemplo action igual a opened, e todo o resto é ignorado. Defina um limite de rajada para que um serviço barulhento não inicie vinte agentes em um minuto.
Coloque o evento no seu prompt
Escreva o prompt com as variáveis do evento: o título, o autor, a URL, o número, a branch ou o payload inteiro. Elas são resolvidas quando o gatilho dispara, exatamente como as variáveis de data e hora que as tarefas agendadas já suportam.
Reenvie a última chamada e coloque no ar
O editor mostra a última chamada que o gatilho recebeu, com o JSON bruto incluído, e a reenvia com um clique. Você liga um webhook olhando para ele, e não no chute, e quando está certo você ativa o gatilho.
A fileira de serviços é um conjunto de atalhos, não uma lista de permitidos. O editor diz isso embaixo do seletor, e a primeira entrada é Any service (JSON) exatamente por isso: qualquer coisa capaz de enviar um corpo JSON por POST funciona. Escolher GitHub, GitLab, Slack, Linear ou Sentry acrescenta exatamente duas coisas: o cabeçalho de assinatura próprio do serviço, a ser verificado, e os campos do payload dele já mapeados para as variáveis do evento. Nada é recusado por não estar na lista.
Os chips de variáveis não são documentação, são botões: clique em um para inseri-lo no prompt, e os que a última chamada realmente preencheu ficam destacados. Embaixo deles fica a última chamada que o gatilho recebeu, então você escreve o filtro e o prompt contra um payload real que você enxerga, reenvia essa chamada e só liga o gatilho quando a execução sai certa.
- O evento chega na URL do seu gatilho
O serviço envia seu JSON por POST. O AgentsRoom confere a assinatura com o seu segredo e rejeita qualquer chamada sem assinatura, depois aplica o seu filtro, se você definiu um.
- Ele espera se não houver ninguém
Sua máquina pode estar desligada. O evento fica guardado por até uma semana e é reenviado no próximo arranque em vez de ser descartado, o mesmo modelo de recuperação que as tarefas agendadas já usam.
- Uma máquina o assume, e apenas umaMac do escritórioMac de casaMáquina de build
Se vários computadores estiverem com o projeto aberto, o primeiro que pegar o evento o trava. Os outros veem que ele já foi tomado e seguem em frente, então um mesmo evento nunca produz dois agentes.
- O agente roda, uma vez
Um agente de verdade abre no projeto, com o papel, o provider e o modelo que você escolheu, seu próprio terminal, sua vista de conversa e uma transcrição arquivada que você relê depois.
Uma URL pública que não é uma porta aberta
A URL é acessível pela internet, então o gatilho decide o que aceita antes de qualquer coisa começar.
Toda chamada é assinada
O AgentsRoom verifica cada chamada com o seu segredo antes de qualquer coisa começar: X-Hub-Signature-256 para o GitHub, X-Slack-Signature para o Slack, o token compartilhado X-Gitlab-Token para o GitLab, e um HMAC simples do corpo bruto para o Linear, o Sentry e as fontes genéricas. Uma chamada sem assinatura é rejeitada, então conhecer a URL não basta para iniciar um agente na sua máquina.
Troque o segredo quando quiser
O segredo de assinatura aparece no editor e pode ser gerado de novo na hora. As chamadas antigas param de ser validadas imediatamente, que é exatamente o que você quer no dia em que um serviço é desativado ou um segredo vaza em um log.
Filtre pelo payload
Uma condição opcional decide se o evento merece um agente. Dispare só quando action for igual a opened, só em uma branch, só para um label. Tudo que não corresponde é descartado sem criar nada.
Proteção contra rajadas
No máximo uma execução por janela de tempo. Um serviço que envia trinta eventos em dez segundos não inicia trinta agentes: as chamadas dentro da janela são agrupadas e uma única execução cobre todas.
O payload vira o seu prompt
O JSON que o serviço envia é convertido em variáveis que você escreve direto no prompt. Elas são resolvidas na hora do disparo, como as variáveis de data e hora que as tarefas agendadas já usam.
Escreva o prompt uma vez, e cada execução recebe os dados do evento que a disparou.
{{event.title}}O título do evento: o título da pull request, o título da issue, o nome do alerta.{{event.author}}Quem causou: o autor da pull request, a pessoa que abriu a issue.{{event.url}}O link de volta para o evento, para que o agente possa abrir a pull request ou o alerta.{{event.number}}O número da pull request ou da issue, quando o serviço envia um.{{event.branch}}A branch que o evento envolve, para um push, uma pull request ou um build que falhou.{{payload}}Todo o JSON bruto, para o que as variáveis nomeadas não cobrem.
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.Os nomes das variáveis são escritos entre chaves duplas no campo do prompt, exatamente como as variáveis de data e hora de uma tarefa agendada.
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.idO que roda de verdade, e onde
O mesmo modelo de execução honesto das tarefas agendadas, estendido aos eventos.
De onde vêm os eventos
Qualquer coisa capaz de enviar um POST assinado com um corpo JSON pode iniciar um agente. Estes são os que as pessoas ligam primeiro.
Seu CI, seu backend, qualquer coisa
Um passo de pipeline, uma ferramenta de monitoramento, um serviço interno, um script shell com curl. Não há integração para pedir: um POST com um corpo JSON e uma assinatura é todo o contrato.
GitHub e GitLab
Pull requests e merge requests abertas, revisadas ou mescladas, issues criadas, pushes, releases, workflows que falham. A fonte clássica, e a que tem o payload mais útil.
Slack
Um slash command ou um webhook de saída transforma uma mensagem em um canal em uma execução de agente no projeto certo. As assinaturas do Slack são verificadas com X-Slack-Signature.
Linear e Sentry
Uma issue movida para uma coluna, uma nova exceção em produção, um alerta de regressão. O rastreador dispara, o agente inicia com o ticket ou o erro no prompt.
A outra metade do mesmo painel
Os gatilhos e as tarefas agendadas são uma só funcionalidade com duas respostas para a mesma pergunta. Uma tarefa agendada é um gatilho cujo evento é um relógio. Um gatilho webhook é uma tarefa agendada cujo agendamento é o mundo exterior. Eles vivem na mesma lista, compartilham a mesma configuração de agente, o mesmo interruptor de ativação, o mesmo histórico de execuções e o mesmo escopo por máquina.
Então você escolhe por trabalho, e não por ferramenta. A auditoria de dependências continua na segunda de manhã, porque nada lá fora anuncia que um pacote ficou desatualizado. A revisão de pull requests migra para um webhook, porque o GitHub já sabe o segundo exato em que ela deve acontecer. Leia a página do Scheduled Tasks para o lado relógio da família.
Veja o Scheduled Tasks, o lado relógio do mesmo painelFAQ
O que é um gatilho webhook no AgentsRoom?
É um gatilho que inicia um agente de IA quando um serviço externo lhe envia um evento, em vez de em um horário definido. O AgentsRoom dá ao gatilho uma URL pública e um segredo de assinatura; você cola a URL no GitHub, GitLab, Slack, Linear, Sentry ou em qualquer ferramenta capaz de enviar um POST JSON. Quando esse serviço chama, a assinatura é verificada, o seu filtro opcional é aplicado, e um agente inicia no seu projeto com o payload já disponível como variáveis do prompt.
Qual é a diferença para uma tarefa agendada?
Só muda a pergunta 'quando isso dispara'. Uma tarefa agendada dispara em um relógio: a cada N minutos, horária, diária, semanal ou mensal. Um gatilho webhook dispara em um evento vindo de fora. Todo o resto é compartilhado: a mesma lista, o mesmo interruptor de ligar e desligar, a mesma configuração de agente, o mesmo histórico por execução, o mesmo escopo por máquina.
Por que não deixar simplesmente um agente consultando a API?
Porque consultar custa tokens a cada volta, e quase toda volta não encontra nada. Um agente que verifica um repositório a cada cinco minutos roda um turno inteiro a cada cinco minutos para responder 'não'. Um gatilho webhook não consome nada enquanto nada acontece, e reage em poucos segundos quando algo acontece. Esse é todo o argumento econômico da funcionalidade.
É seguro expor a URL do gatilho?
A URL sozinha não basta para iniciar nada. Toda chamada precisa provar que vem do serviço que tem o seu segredo: X-Hub-Signature-256 para o GitHub, X-Slack-Signature para o Slack, o token compartilhado X-Gitlab-Token para o GitLab, um HMAC simples do corpo bruto para o Linear, o Sentry e as fontes genéricas. Uma chamada sem cabeçalho de assinatura é rejeitada, nunca liberada. O segredo aparece no editor e pode ser gerado de novo a qualquer momento, o que invalida na hora tudo o que usava o antigo.
Posso disparar só em alguns eventos?
Sim. Um repositório envia muito mais eventos do que você quer agentes, então um gatilho aceita uma condição opcional sobre o payload, por exemplo action igual a opened. Os eventos que não correspondem são ignorados e nada é criado. Também existe um limite de rajada: no máximo uma execução por janela de tempo, com as chamadas que chegam dentro dessa janela agrupadas.
O que acontece se o AgentsRoom estiver fechado quando o evento chega?
O evento fica na fila no servidor e é reenviado na próxima vez que você abrir o app, então ele roda atrasado em vez de nunca rodar. Os eventos na fila são guardados por uma semana, o que cobre um laptop fechado durante um feriado prolongado sem reenviar um mês de trabalho velho quando você volta. É o mesmo modelo in-app com recuperação que as tarefas agendadas usam. Os gatilhos webhook não rodam o seu agente na nuvem: o agente sempre roda na sua máquina, no seu projeto.
Tenho o projeto aberto em dois computadores. O agente vai rodar duas vezes?
Não. Um evento é consumido uma única vez. A primeira máquina que o pegar o trava, e as outras veem que ele já foi tomado e o pulam. Você também pode fixar um gatilho em máquinas específicas, exatamente como em uma tarefa agendada, se quiser que um computador em particular seja o dono dele.
O que posso colocar no prompt a partir do evento?
O payload é convertido em variáveis que você escreve direto no campo do prompt, entre chaves duplas: event.title, event.author, event.url, event.number, event.branch, e payload para todo o JSON bruto. Elas são resolvidas quando o gatilho dispara, do mesmo jeito que as variáveis de data e hora de uma tarefa agendada.
Como sei que meu webhook está ligado corretamente?
O editor mostra a última chamada que o gatilho recebeu, incluindo o corpo JSON bruto, e permite reenviá-la com um clique. Assim você configura o filtro e o prompt contra um payload real que você enxerga, e reenvia até a execução ficar certa, em vez de empurrar commits de teste para descobrir.
Quais serviços são suportados?
Qualquer serviço capaz de enviar um POST assinado com um corpo JSON. GitHub, GitLab, Slack, Linear e Sentry são os que as pessoas ligam primeiro porque seus payloads são ricos, mas não existe lista de permitidos: um job de CI, uma ferramenta de monitoramento, o seu próprio backend ou um curl em um script shell funcionam exatamente da mesma forma.
Isso é um construtor visual de automações com cenários de várias etapas?
Não, e não é isso que ele quer ser. Um gatilho tem uma única função: decidir quando um agente inicia e entregar o evento a ele. A parte de várias etapas é o próprio agente, que lê o código, roda as ferramentas e faz o trabalho. Se você quer que vários agentes passem trabalho uns para os outros, isso é o Agent Teams, e não um quadro de cenários.
O AgentsRoom pode enviar webhooks para outros serviços?
Os gatilhos são apenas de entrada: o AgentsRoom recebe eventos, ele não os emite. Se você quer que um agente chame um serviço externo no fim de uma execução, isso é trabalho do próprio agente, com as ferramentas e os servidores MCP que você deu a ele.
Combina bem com
Scheduled Tasks
O lado relógio do mesmo painel. A cada N minutos, horária, diária, semanal ou mensal, sem nenhuma expressão cron para escrever.
Backlog Task Board
Arraste uma tarefa para uma coluna e um agente a assume. Um gatilho faz a mesma coisa, com um evento externo fazendo o arrastar.
Agent Teams
Agentes de Dev, QA e PM que passam trabalho uns para os outros. Aponte um gatilho para uma equipe e um evento inicia toda a rotina.
AgentsRoom MCP
As ferramentas que um agente usa para ler o backlog, a memória e a biblioteca de prompts. Um agente disparado as recebe como qualquer outro.
Agent Notifications
Saiba no instante em que um gatilho dispara, no desktop e no seu celular, com um toque para abrir o agente que ele iniciou.
Remote Fleet
Várias máquinas em uma conta. Fixe um gatilho naquela que deve responder a ele, e só essa máquina roda o agente.
Pare de consultar. Comece a reagir.
Baixe o AgentsRoom, cole uma URL no GitHub, GitLab, Slack, Linear ou Sentry, e deixe o evento iniciar o agente. Nada roda enquanto nada acontece.
App complementar: acompanhe seus agentes em qualquer lugar
Use Claude, Codex, Antigravity CLI ou outro provedor de IA.
Envie bugs e pedidos direto para o seu backlog público.
Uma visão do AgentsRoom em ação.