Affida il lavoro a un agente da Slack e Teams

Un thread in #payments, a metà mattina. Qualcuno chiede a @Archyl cosa chiama il webhook sender, e il bot risponde: i container Checkout e Billing, entrambi attraverso la Payments API. Due messaggi dopo arriva la frase con cui finiscono tutti questi thread: «dovremmo aggiungere dei retry lì, qualcuno può prenderselo?»

Poi il thread si ammutolisce. Qualcuno deve aprire Archyl, trovare il progetto, scegliere un profilo agente e riscrivere un task che esiste già, parola per parola, tre messaggi più su.

Da giugno il bot di Archyl risponde alle domande in Slack e Microsoft Teams. Da oggi può anche agire. Lo stesso thread può passare il lavoro a un agente gestito:

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

L'agente gira come la persona che ha scritto quel comando, e il bot segue l'esecuzione nel thread finché non c'è una pull request.

Un thread, dall'inizio alla fine

Ecco il resto di quello scambio. I messaggi di Archyl sono i formati che il bot pubblica davvero. I nomi, la domanda e la pull request sono esempi.

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» porta alla pagina dell'esecuzione, dove il piano si riempie come una checklist e ogni chiamata a un tool compare nel feed delle attività. Nessuno deve tenerla aperta.

Venti minuti dopo l'agente arriva a una decisione che non dovrebbe prendere da solo:

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

Marie apre il link, sceglie «only 5xx and timeouts» tra le risposte suggerite e torna a quello che stava facendo. Quando l'esecuzione finisce:

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

Se il profilo ha Rivedi prima il piano attivo, c'è un'altra tappa prima di qualsiasi modifica al codice: «📋 The agent proposed a plan and is waiting for your review», con un link. Se l'esecuzione fallisce o raggiunge il suo limite di tempo o di costo, l'ultimo messaggio dice perché e porta alla pull request in bozza che contiene il lavoro fatto fino a quel momento.

In Slack ognuno di questi aggiornamenti @menziona la persona che ha avviato l'esecuzione, così finisce nelle sue notifiche. In Teams gli aggiornamenti arrivano come risposte nello stesso thread, senza menzione.

Cosa è successo tra quei messaggi

Il thread mostra tre messaggi. L'esecuzione ha fatto parecchio di più, ed è proprio quella parte il senso di questa release.

Prima di toccare un file, l'esecuzione ha aperto una sessione di lavoro sugli elementi di architettura toccati dal task, qui il component webhook sender dentro la Payments API. Ha preso dei lease su di essi, così uno sviluppatore che più tardi avvia Claude Code sullo stesso component viene avvisato che qualcuno ci sta già lavorando. Il suo briefing conteneva gli ADR, le regole di conformità e i contratti API collegati a quegli elementi, più tutto quello che le sessioni precedenti ricordavano su di essi. Ogni file che ha scritto è passato dal Guard, che rifiuta una scrittura che viola una regola di conformità critica. Alla fine, il suo riepilogo è diventato memoria sugli elementi a cui i file modificati appartengono davvero, e ogni decisione che ha registrato ha aperto un Architecture Change Request in bozza da far rivedere a qualcuno.

Niente di tutto questo è specifico della chat. È quello che fa ogni esecuzione di Archyl. Quello che cambia è da dove arriva la richiesta.

È questa la scommessa dietro la funzionalità. Un posto ospitato dove far girare un agente sta diventando qualcosa che si sceglie da un elenco: come abbiamo notato due settimane fa, Anthropic, OpenAI e Cursor ne offrono ciascuno uno. Quello che un runtime non conosce è il tuo sistema: a quale container appartiene il webhook sender, chi ne è responsabile, quale regola dice che l'HTTP in uscita passa dal client condiviso, e quale altro agente ci sta lavorando in questo momento. Questa conoscenza vive nel modello di architettura. La chat è dove il lavoro viene chiesto. Questa release collega le due cose, così una richiesta fatta in un thread arriva con il contesto di cui un agente ha bisogno per farla bene.

Perché l'esecuzione viene creata come te

Quando il bot risponde a una domanda, usa i permessi dell'amministratore che ha collegato il workspace. Per leggere funziona. Chiunque nel canale ottiene la stessa vista dell'architettura, ristretta per canale se l'hai limitato.

Agire è diverso. Un'esecuzione scrive codice e apre una pull request. Se @Archyl run prendesse in prestito i permessi di chi ha installato il bot, chiunque in un canale Slack potrebbe far modificare a un agente un progetto che non può modificare di persona, e lo storico delle esecuzioni riporterebbe il nome dell'amministratore per ognuna di esse.

Per questo le esecuzioni vengono create come la persona che ha scritto il comando, entro i limiti del suo accesso in modifica al progetto. Il bot non può sapere chi è un utente della chat su Archyl finché non glielo dice, quindi serve un passaggio per persona, una volta sola:

1. In Archyl, vai su Profilo → Account di chat e clicca su Collega il mio account Slack o Collega il mio account Microsoft Teams.
2. Invia il comando mostrato, @Archyl connect <code>, in qualsiasi punto in cui il bot è presente su quella piattaforma.

Il codice è monouso e valido 15 minuti, e l'hai generato tu mentre avevi fatto l'accesso: è questo che dimostra che l'account di chat è tuo. Slack e Teams si collegano separatamente. @Archyl disconnect rimuove il collegamento; il bot continua a rispondere alle tue domande e smette di avviare agenti per te.

Se salti questo passaggio e scrivi comunque run, il bot ti dice cosa manca invece di tirare a indovinare:

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

Come viene letto il comando

@Archyl run [Project name] <task>, con due parti opzionali.

Il progetto va tra parentesi quadre. Per ora le parentesi sono obbligatorie, così il bot non deve mai indovinare dove finisce il nome del progetto e dove comincia il task. In un canale limitato a un solo progetto puoi omettere il progetto: @Archyl run fix the flaky login test. Un canale limitato a più progetti accetta solo progetti dentro il suo ambito. Chiedi qualcos'altro e il bot risponde che non trova quel progetto nell'ambito di questo canale.

Il profilo va prima del task. Senza profilo, l'esecuzione usa il profilo predefinito della tua organizzazione. Per sceglierne un altro, metti profile:<name> all'inizio:

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

Un nome di profilo che non esiste riceve una risposta con l'elenco di quelli esistenti.

Tutto il resto si comporta come nell'app. Ti serve l'accesso in modifica al progetto. L'esecuzione conta nelle esecuzioni mensili di agenti della tua organizzazione, come un'esecuzione avviata da Hub Agenti → Esecuzioni (e, come nell'app, le organizzazioni con un proprio provider di AI non vengono conteggiate). Se il profilo ha Rispetta il lavoro degli altri agenti attivo e un altro agente ha un lease sugli stessi elementi, il bot risponde che il gate di preflight ha rifiutato l'esecuzione. Se il gate si limita ad avvisare, l'esecuzione resta in attesa di approvazione e il bot ti manda il link.

Due piccole cose a cui abbiamo fatto attenzione

Un testo non affidabile non può notificare tutto il canale. Il task, il nome del progetto e le domande dell'agente finiscono tutti citati di nuovo nel canale. Per ognuno viene fatto l'escape secondo la sua piattaforma prima della pubblicazione, così un task o una domanda che contiene <!channel> in Slack, o una menzione <at> in Teams, arriva come testo semplice invece di notificare tutti.

Il thread a cui un'esecuzione riferisce non è qualcosa che un client possa cambiare. Il canale e il thread in cui un'esecuzione pubblica vengono salvati sul server quando l'esecuzione viene creata, non nei suoi metadati, che i client dell'API possono scrivere. Inoltre gli aggiornamenti vanno solo a un workspace collegato all'organizzazione proprietaria dell'esecuzione.

Cosa non fa ancora

La revisione del piano e le risposte avvengono in Archyl, non nel thread. Il bot ti dice che l'agente è in attesa e porta alla pagina dell'esecuzione. Non puoi approvare un piano né rispondere a una domanda da Slack o Teams. Conta più di quanto sembri: una domanda a cui nessuno risponde entro un'ora lascia che l'agente prosegua secondo il proprio giudizio, e un piano che nessuno rivede entro un'ora fa fallire l'esecuzione. La @menzione serve perché quell'ora non passi inosservata.

I nomi dei progetti devono corrispondere a esattamente un progetto. Non c'è fuzzy matching, e se due progetti hanno lo stesso nome il bot ti chiede di rinominarne uno o di avviare dall'app.

Gli aggiornamenti di Teams non ti menzionano. Sono risposte nel thread, quindi quanto sono visibili dipende da come segui quel thread.

Una pull request richiede un host supportato. Le esecuzioni aprono pull request su github.com, gitlab.com e bitbucket.org. Bitbucket non ha pull request in bozza, quindi un'esecuzione che fallisce lì fa il push del suo branch senza aprirne una. Un repository su un server Git self-hosted non riceve una pull request, quindi il messaggio finale dice che l'agente ha finito e porta all'esecuzione.

Provalo

Avviare esecuzioni dalla chat richiede gli agenti gestiti, disponibili nei piani Scale e Custom, e un workspace Slack o Teams collegato. Collega il tuo account di chat da Profilo → Account di chat, poi scegli un thread in cui qualcuno ha appena chiesto qualcosa di piccolo e ben definito, e scrivi @Archyl run.

Il riferimento completo, compreso il modo in cui si applicano permessi e ambiti dei canali, è nella documentazione alla sezione Avviare esecuzioni di agenti da Slack o Teams.

Letture correlate: il lancio del bot per Slack e Teams, limitare il bot per canale, gli agenti gestiti ora rispondono all'harness e seguire e guidare un'esecuzione dal vivo.