AIREITERO Factory Automations pode iniciar uma sessão do Droid a partir de um agendamento, de uma mensagem principal no Slack, de um evento do GitHub ou de uma requisição HTTP recebida. Os gatilhos por webhook ainda estão em Private Preview, enquanto os agendamentos usam horários fixos em UTC e não acompanham automaticamente as mudanças do horário de verão. É uma solução pronta para um piloto com escopo controlado — não para uma implantação em produção sem restrições.
O que o Factory Automations realmente executa
Cada automação combina um gatilho, instruções, uma identidade e um destino de execução (documentação do Factory).
| Gatilho | O que inicia a execução | Principal detalhe da execução |
|---|---|---|
| Agendado | Frequência em linguagem natural ou cron de cinco campos | Executa em um computador ou destino de execução selecionado; computadores gerenciados aceitam 10 automações e 5 agendadas para um minuto |
| Slack | Mensagem principal de canal que corresponda aos filtros | Responde na thread de origem |
| GitHub | Pull requests, comentários, pushes, labels, verificações ou um agendamento | Executa no GitHub Actions depois que a configuração é mesclada |
| Webhook | HTTP POST de outro serviço | Droid Computer ou template de execução; Private Preview |
Uma automação pode ser privada ou compartilhada com uma organização. A privacidade da sessão é um controle separado e define quem pode abrir as sessões criadas pelas execuções.
A escolha do gatilho muda o modelo de operação
Execuções agendadas: o ponto de partida mais seguro
Os agendamentos aceitam frases simples, como “every Monday at 9am PST”, ou uma expressão cron, como 0 9 * * 1. O Factory mostra uma prévia do horário resultante, mas o cron é executado em UTC. Quando você informa um fuso horário, ele é convertido em um agendamento UTC fixo e não se ajusta sozinho ao horário de verão (documentação do Factory).
Bons primeiros usos incluem gerar um resumo diário de status, auditar dependências, verificar documentação desatualizada ou revisar PRs produzindo evidências em vez de fazer merge do código.
Mensagens do Slack: úteis, mas limitadas aos sinais principais
Uma automação do Slack começa quando uma mensagem principal que corresponda aos filtros aparece em um canal acessível. Respostas em threads não iniciam uma execução por conta própria. Os filtros podem restringir mensagens por padrão de canal, tipo de remetente, palavras-chave, palavras-chave excluídas ou remetentes excluídos.
As execuções respondem na thread da mensagem que acionou o processo. Se várias automações corresponderem à mesma mensagem, apenas a primeira responde ali; as demais publicam mensagens separadas com um link para a original. O Factory documenta esses comportamentos, incluindo as regras de acesso a canais privados (documentação do Factory). Isso funciona bem em um canal de incidentes controlado, mas não em fluxos que dependem de cada resposta posterior.
Eventos do GitHub: poderosos depois de uma etapa de configuração visível
As automações personalizadas do GitHub podem reagir a pull requests, pushes, comentários, mudanças de labels, verificações concluídas ou a um agendamento. Elas são executadas no GitHub Actions, e sua criação abre um pull request de configuração em cada repositório selecionado.
Esse pull request de configuração precisa ser mesclado antes que o workflow fique ativo. As execuções iniciadas antes de o workflow chegar à branch padrão falham, e a automação não pode publicar comentários, enviar commits ou abrir pull requests antes disso. O GitHub é o gatilho mais forte quando o trabalho recorrente já está associado a um evento do repositório e a revisão normal de pull requests continua sendo a barreira para envio.
Webhooks: capacidade real, disponibilidade limitada
O Factory classifica as automações por webhook como Private Preview e orienta as organizações a entrar em contato com o suporte para habilitá-las. Um webhook inicia uma execução a partir de um HTTP POST externo, mas não pode rodar na máquina local de um usuário; é necessário usar um Droid Computer ou um template de execução.
O Factory fornece uma URL de webhook, a opção de usar o cabeçalho X-Webhook-Secret e um formato de URL para remetentes que não conseguem definir cabeçalhos. A documentação recomenda o cabeçalho porque segredos incluídos na URL podem aparecer em logs; o segredo é exibido uma única vez, e a rotação invalida o valor antigo (documentação de webhooks do Factory).
A mesma documentação estabelece um limite de 200 KiB para o corpo, 60 requisições aceitas por minuto, registros de entrega mantidos por 30 dias, uma janela de deduplicação de 10 minutos para corpos idênticos e um limite de 10 execuções por hora. Esses controles tornam os webhooks testáveis para respostas a alertas, mas o status de prévia é um bloqueio para produção quando o acesso precisa ser previsível.
Os controles que definem se é seguro automatizar
As automações agendadas, do Slack e por webhook podem ser executadas como o usuário ou como uma conta de serviço compartilhada. A identidade afeta o acesso aos conectores, o faturamento e a atribuição no Slack; as regras de destino da execução estão listadas na documentação do Factory.
Mantenha o prompt restrito, use credenciais revogáveis, selecione um destino de execução dedicado e deixe as permissões de deploy e merge sob o controle dos mecanismos já existentes no repositório. O anúncio do Factory no Slack Marketplace afirma explicitamente que o app pode cometer erros e orienta os usuários a conferir novamente o código e as respostas.
Um usuário mencionou lacunas de supervisão, incluindo a ausência de um aplicativo de desktop para Linux e de sincronização entre computadores (publicação de @JoelDeTeves no X); isso é relevante quando uma equipe espera supervisionar trabalhos automatizados de longa duração longe do desktop.
Factory Automations vs. um GitHub Action simples
| Necessidade | Factory Automations | GitHub Action simples |
|---|---|---|
| Executar um prompt em um repositório | Sessão nativa do Droid e destino de execução | A equipe fornece o runtime do agente e o código do workflow |
| Trabalho agendado | Linguagem natural ou cron, com a ressalva do UTC | Cron do GitHub e lógica personalizada |
| Gatilho do Slack | Mensagens principais com filtros e respostas em threads | Integração com app do Slack ou infraestrutura de webhook |
| Evento do GitHub | PR de configuração guiada e execução no GitHub Actions | Arquivo de workflow direto |
| Webhook | Integrado, mas em Private Preview | Construir endpoint, autenticação, tentativas e worker |
| Barreira de revisão | Pode preparar o trabalho para revisão humana | Depende das permissões do workflow |
Use um GitHub Action quando a tarefa for uma integração determinística com APIs, como um resumo diário de PRs. Prefira o Factory quando a etapa recorrente exigir investigação, contexto do repositório, uma proposta de alteração no código ou uma sessão legível por humanos. Não escolha uma plataforma de agentes apenas para evitar escrever um script curto.
Um piloto de baixo risco para conquistar mais autonomia
- Escolha uma tarefa recorrente com entrada bem delimitada, como revisar novos pull requests ou verificar arquivos gerados.
- Comece com uma automação agendada em vez de um webhook; assim, você evita a necessidade de acesso à prévia e consegue inspecionar facilmente a cadência.
- Faça com que a saída seja um relatório ou pull request, não um deploy ou merge.
- Registre execuções que falharam, trabalhos bloqueados, arquivos alterados e correções humanas; apenas pull requests aceitos não são evidência suficiente.
- Amplie uma dimensão por vez: outra classe de tarefa, outro repositório ou outro gatilho.
As orientações de workflow do Factory recomendam reproduzir a falha original, testar a correção em um ambiente limpo e verificar um caso vizinho antes de manter uma instrução reutilizável. Esse é um padrão sensato para um piloto do Automations.
Perguntas frequentes
O Factory Automations oferece suporte a webhooks?
Sim, mas os gatilhos por webhook estão em Private Preview e podem exigir habilitação no nível da organização. As execuções precisam de um Droid Computer ou de um template de execução. Os detalhes estão na seção sobre webhooks acima.
As respostas em threads do Slack acionam uma automação?
Não. Apenas uma mensagem principal que corresponda aos filtros inicia a execução; consulte Mensagens do Slack.
O agendamento acompanha o horário de verão?
Não. O Factory salva um agendamento UTC fixo; revise-o quando as regras locais de horário de verão mudarem. Consulte Execuções agendadas.
As automações do GitHub são executadas antes de o pull request de configuração ser mesclado?
Não. O pull request de configuração precisa chegar primeiro à branch padrão; as execuções anteriores falham. Consulte Eventos do GitHub.
O que acontece quando uma entrega de webhook é repetida?
Um corpo idêntico recebido dentro de 10 minutos é registrado como Deduped e não inicia outra execução. O Factory também registra entregas filtradas, limitadas por taxa, ignoradas e com falha.
O ponto de equilíbrio que precisa continuar visível
Faça o piloto de trabalhos acionados por agendamento ou pelo GitHub quando a saída puder permanecer dentro de um fluxo de revisão por pull request. O Slack é prático com convenções para mensagens principais; os webhooks são detalhados o suficiente para testes, mas o status de Private Preview significa que eles ainda não devem sustentar um sistema de incidentes em produção.