Passe Trabalho para um Agente pelo Slack e pelo Teams

Um thread no #payments, no meio da manhã. Alguém pergunta ao @Archyl o que chama o webhook sender, e o bot responde: os containers Checkout e Billing, ambos pela Payments API. Duas mensagens depois vem a frase em que todo thread desses termina: "a gente devia colocar retries nisso, alguém consegue pegar?"

Aí o thread fica em silêncio. Alguém precisa abrir o Archyl, achar o projeto, escolher um perfil de agente e redigitar uma tarefa que já existe, palavra por palavra, três mensagens acima.

Desde junho, o bot do Archyl responde perguntas no Slack e no Microsoft Teams. A partir de hoje, ele também pode agir. O mesmo thread pode passar o trabalho para um agente gerenciado:

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

O agente roda como a pessoa que digitou isso, e o bot acompanha a execução no thread até existir um pull request.

Um thread, do começo ao fim

Aqui está o resto dessa conversa. As mensagens do Archyl são os formatos que o bot realmente publica. Os nomes, a pergunta e o pull request são exemplos.

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" leva à página da execução, onde o plano vai sendo preenchido como uma checklist e cada chamada de tool aparece no feed de atividade. Ninguém precisa deixar a página aberta.

Vinte minutos depois, o agente chega a uma decisão que não deveria tomar sozinho:

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

Marie clica, escolhe "only 5xx and timeouts" entre as respostas sugeridas e volta ao que estava fazendo. Quando a execução termina:

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

Se o perfil estiver com Revisar o plano primeiro ativado, há mais uma parada antes de qualquer mudança no código: "📋 The agent proposed a plan and is waiting for your review", com um link. Se a execução falhar ou atingir o limite de tempo ou de custo, a última mensagem diz por quê e leva ao pull request em rascunho que guarda o trabalho feito até ali.

No Slack, cada uma dessas atualizações @menciona a pessoa que iniciou a execução, para que caia nas notificações dela. No Teams, as atualizações chegam como respostas no mesmo thread, sem menção.

O que aconteceu entre essas mensagens

O thread mostra três mensagens. A execução fez bem mais do que isso, e essa parte é a razão deste release.

Antes de tocar em um arquivo, a execução abriu uma sessão de trabalho nos elementos de arquitetura que a tarefa envolve, aqui o component webhook sender dentro da Payments API. Ela pegou reservas nesses elementos, então um desenvolvedor que mais tarde iniciar o Claude Code no mesmo component fica sabendo que alguém já está trabalhando ali. O briefing dela trazia os ADRs, as regras de conformidade e os contratos de API ligados a esses elementos, além de tudo o que sessões anteriores lembravam sobre eles. Cada arquivo que ela gravou passou pelo Guard, que recusa uma gravação que quebre uma regra de conformidade crítica. Ao terminar, o resumo dela virou memória nos elementos aos quais os arquivos alterados de fato pertencem, e cada decisão que ela registrou abriu um Architecture Change Request em rascunho para alguém revisar.

Nada disso é específico do chat. É o que toda execução do Archyl faz. O que mudou é de onde vem o pedido.

Essa é a aposta por trás desta funcionalidade. Um lugar hospedado para rodar um agente está virando algo que você escolhe de uma lista: como observamos duas semanas atrás, Anthropic, OpenAI e Cursor oferecem um cada. O que um runtime não conhece é o seu sistema: a qual container o webhook sender pertence, quem é o responsável por ele, qual regra diz que o HTTP de saída passa pelo client compartilhado e qual outro agente está mexendo ali agora. Esse conhecimento vive no modelo de arquitetura. O chat é onde o trabalho é pedido. Este release conecta os dois, para que um pedido feito em um thread chegue com o contexto de que um agente precisa para fazer bem o trabalho.

Por que a execução é criada como você

Quando o bot responde uma pergunta, ele usa as permissões do administrador que conectou o workspace. Para leitura, isso funciona. Todo mundo no canal tem a mesma visão da arquitetura, restrita por canal se você a limitou.

Agir é diferente. Uma execução escreve código e abre um pull request. Se o @Archyl run pegasse emprestadas as permissões de quem instalou o bot, qualquer pessoa em um canal do Slack poderia fazer um agente alterar um projeto que ela mesma não pode editar, e o histórico de execuções mostraria o administrador em cada uma delas.

Por isso as execuções são criadas como a pessoa que digitou o comando, limitadas ao acesso de edição dessa pessoa no projeto. O bot não tem como saber quem é um usuário de chat no Archyl até que ele diga, o que significa um passo por pessoa, uma única vez:

1. No Archyl, vá em Perfil → Contas de chat e clique em Vincular minha conta do Slack ou Vincular minha conta do Microsoft Teams.
2. Envie o comando exibido, @Archyl connect <code>, em qualquer lugar onde o bot esteja presente nessa plataforma.

O código é de uso único e vale por 15 minutos, e foi gerado por você com a sessão iniciada, que é o que prova que a conta de chat é sua. Slack e Teams são vinculados separadamente. @Archyl disconnect remove o vínculo; o bot continua respondendo suas perguntas e para de iniciar agentes por você.

Se você pular isso e digitar run mesmo assim, o bot diz o que está faltando em vez de adivinhar:

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>.

Como o comando é lido

@Archyl run [Project name] <task>, com duas partes opcionais.

O projeto vai entre colchetes. Por enquanto os colchetes são obrigatórios, para que o bot nunca tenha que adivinhar onde termina o nome do projeto e onde começa a tarefa. Em um canal restrito a um único projeto, você pode omitir o projeto: @Archyl run fix the flaky login test. Um canal restrito a vários projetos só aceita projetos dentro do seu âmbito. Peça qualquer outro e o bot responde que não encontra esse projeto no âmbito deste canal.

O perfil vem antes da tarefa. Sem perfil, a execução usa o perfil padrão da sua organização. Para escolher outro, coloque profile:<name> no início:

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

Um nome de perfil que não existe recebe uma resposta listando os que existem.

Todo o resto se comporta como no app. Você precisa de acesso de edição ao projeto. A execução conta para as execuções mensais de agentes da sua organização, como uma execução iniciada em Hub de Agentes → Execuções (e, como no app, organizações com o próprio provedor de IA não são contabilizadas). Se o perfil estiver com Respeitar o trabalho de outros agentes ativado e outro agente tiver uma reserva nos mesmos elementos, o bot responde que o gate de preflight recusou a execução. Se o gate só emitir um alerta, a execução fica retida aguardando aprovação e o bot manda o link para ela.

Dois detalhes em que tomamos cuidado

Texto não confiável não consegue notificar a sala inteira. A tarefa, o nome do projeto e as perguntas do agente acabam todos citados de volta no canal. Cada um passa por escape para a sua plataforma antes de ser publicado, então uma tarefa ou pergunta contendo <!channel> no Slack, ou uma menção <at> no Teams, chega como texto simples em vez de notificar todo mundo.

O thread para o qual uma execução reporta não é algo que um client possa mudar. O canal e o thread em que uma execução publica ficam guardados no servidor quando a execução é criada, e não nos metadados dela, que clients da API podem escrever. As atualizações também só vão para um workspace conectado à organização dona da execução.

O que ainda não faz

A revisão do plano e as respostas acontecem no Archyl, não no thread. O bot avisa que o agente está esperando e leva à página da execução. Você não consegue aprovar um plano nem responder uma pergunta pelo Slack ou pelo Teams. Isso pesa mais do que parece: uma pergunta que ninguém responde em uma hora deixa o agente seguir com o próprio julgamento, e um plano que ninguém revisa em uma hora faz a execução falhar. A @menção existe para que essa hora não passe despercebida.

O nome do projeto precisa corresponder a exatamente um projeto. Não há correspondência aproximada, e se dois projetos tiverem o mesmo nome o bot pede que você renomeie um ou inicie pelo app.

As atualizações do Teams não mencionam você. Elas são respostas no thread, então a visibilidade delas depende de como você acompanha esse thread.

Um pull request precisa de um host suportado. As execuções abrem pull requests no github.com, no gitlab.com e no bitbucket.org. O Bitbucket não tem pull requests em rascunho, então uma execução que falha lá faz push da branch sem abrir nenhum. Um repositório em um servidor Git self-hosted não recebe pull request, então a mensagem final diz que o agente terminou e leva à execução.

Experimente

Iniciar execuções pelo chat exige agentes gerenciados, disponíveis nos planos Scale e Custom, e um workspace do Slack ou do Teams conectado. Vincule sua conta de chat em Perfil → Contas de chat, escolha um thread em que alguém acabou de pedir algo pequeno e bem definido, e digite @Archyl run.

A referência completa, incluindo como as permissões e os âmbitos de canal se aplicam, está na documentação, em Iniciar execuções de agentes pelo Slack ou Teams.

Leitura relacionada: o lançamento do bot do Slack e do Teams, limitar o bot por canal, agentes gerenciados agora respondem ao harness e acompanhar e conduzir uma execução ao vivo.