L’API Slack Code è disponibile in generale con tutti i piani Slack

Il 28 ottobre 2026 Slack ha reso l’API Slack Code disponibile in generale con tutti i piani Slack, aprendo il sistema dei canali di codice lanciato nell’agosto 2026 agli agenti di qualsiasi sviluppatore. In un post sul blog per sviluppatori di Slack, l’azienda ha dichiarato che oltre 150 clienti e partner avevano chiesto l’accesso per creare esperienze basate sui canali di codice per i propri agenti, una possibilità in precedenza riservata a pochi partner del lancio.

Slack ha presentato Slack Code ad agosto insieme a partner tra cui Anthropic, Cognition, GitHub e Vercel; nell’annuncio del lancio figuravano anche OpenAI e ChatGPT, indicato come disponibile a breve. Un canale di codice è uno spazio dedicato che un agente apre per un singolo compito, con già al suo interno le persone giuste, il contesto e il piano di lavoro; al termine dell’attività, il canale viene archiviato automaticamente, ma resta consultabile tramite ricerca. Al momento del lancio, Slack ha riferito che oltre il 70% dei canali di codice viene creato e chiuso nell’arco di una sola giornata, dall’idea alla richiesta pull integrata.

Usa il tuo agente

Ora che l’API è disponibile in generale, qualsiasi sviluppatore può fare in modo che un agente avvii un canale di codice, aggiunga le persone e i file pertinenti, pubblichi aggiornamenti durante il lavoro e archivi il canale al termine dell’attività. Slack ha dichiarato che gli sviluppatori hanno a disposizione gli stessi strumenti di base utilizzati dai partner del lancio, sia che stiano creando un agente sviluppato internamente per un’azienda, sia che ne stiano realizzando uno nuovo per Slack Marketplace.

Secondo Slack, in precedenza integrare gli agenti di programmazione in Slack significava instradare i risultati degli agenti tramite thread standard e messaggi diretti, spazi che diventavano angusti quando un agente doveva allegare un file di registro di grandi dimensioni, proporre una modifica al codice di 50 righe o eseguire un piano operativo articolato in più passaggi. Slack ha aggiunto che le aziende con rigidi requisiti di sicurezza non potevano usare affatto agenti di terze parti pronti all’uso.

L’azienda descrive l’API come uno strumento che abilita tre funzionalità: agenti che lavorano alla luce del sole, creando un proprio canale di codice quando una richiesta merita uno spazio dedicato; agenti che un intero team può guidare, grazie ai segnalibri e a una cronologia completa dell’esecuzione; e agenti di cui le aziende possono fidarsi, con la conformità dei messaggi integrata nei controlli dell’area di lavoro e nei limiti dei dati già utilizzati dagli amministratori. Le API possono mostrare differenze nel codice, anteprime HTML e passaggi del ragionamento, mentre Slack gestisce il resto dell’interfaccia. Slack ha dichiarato di continuare a essere un hub neutrale rispetto agli agenti, così i team possono passare in seguito ad altri agenti o modelli continuando a lavorare nello stesso ambiente.

Slack ha riferito che GitHub Copilot apre un canale di codice dedicato nel 30% delle sue sessioni con agenti. Tim Hunter, ingegnere senior di GitHub, ha dichiarato che GitHub sta integrando le interazioni con Copilot a cui gli utenti sono già abituati nello stesso spazio in cui svolgono il resto del loro lavoro. Mael Kerichard, ingegnere del software di Mistral, ha affermato che l’API sembrava progettata pensando agli agenti di IA, sottolineandone la flessibilità, la semplicità di configurazione e la ricchezza di funzionalità.

Secondo Slack, la governance è integrata: un agente eredita le autorizzazioni e i controlli di amministrazione del canale in cui opera, senza che gli sviluppatori debbano creare un modello di accesso separato e senza che il reparto IT debba configurare nulla di nuovo. Una persona può approvare ogni modifica ad alto impatto e il resoconto delle attività svolte dall’agente resta consultabile tramite ricerca anche dopo l’archiviazione del canale.

Slack illustra il modello con un avviso di produzione alle 2:00 di notte: un agente personalizzato per l’osservabilità apre un canale di codice, recupera i registri pertinenti e inizia a lavorare a una correzione, mentre gli ingegneri reperibili seguono l’attività e lo reindirizzano nel corso del compito. L’azienda ha dichiarato che lo stesso approccio si applica alla gestione delle segnalazioni di bug e ad attività DevOps come le modifiche alla configurazione o i ripristini.

Come funziona l’API

La documentazione per sviluppatori di Slack spiega che le app controllano il titolo, lo stato, la barra contestuale e le schede di visualizzazione di un canale di codice tramite due famiglie di metodi API. I agents.sessions.* metodi sono unificati per i canali di codice e i thread di sessione; un parametro con il timestamp del thread determina il tipo di sessione e, per utilizzarli, è necessario l’ambito di chat:write autorizzazione. I agents.conversations.* metodi gestiscono le attività specifiche dei canali di codice e richiedono l’ambito di code_channels:manage autorizzazione.

I metodi documentati agents.conversations.* includono create, archive (che può facoltativamente registrare un riepilogo), setProperties, setCommands, setView (che supporta le visualizzazioni html, diff, block_kit o canvas), listViews, removeView, getCanvas e setCanvasContent.

Le app abilitano i canali di codice impostando features.code_channels.enabled su true nel manifest dell’app, con un campo facoltativo slash_command_url. Quando un utente menziona l’app, questa riceve un evento app_mention e decide se creare un canale di codice dedicato o rispondere direttamente nel thread. La chiamata create richiede il canale di origine e il timestamp del messaggio; Slack crea quindi il canale, ne imposta la privacy in modo corrispondente e invita automaticamente il bot.

Secondo il modello di autorizzazione documentato, chi effettua la chiamata deve essere il bot agente assegnato al canale oppure un membro del canale; in caso contrario, le chiamate restituiscono gli errori not_agent_channel o not_authorized. I canali di codice sono progettati per essere semi-temporanei (un canale per ogni attività, archiviato al termine della sessione) e, una volta archiviati, restano consultabili, ricercabili e riapribili, insieme alla relativa cronologia.

Strumenti in arrivo e come iniziare

Slack ha dichiarato che a breve saranno disponibili miglioramenti all’esperienza delle richieste pull: gli utenti di GitHub potranno richiedere revisioni in Slack, i commenti saranno sincronizzati in entrambe le direzioni tra Slack e GitHub e, una volta approvata una richiesta pull e superati i test, nel canale dedicato al codice comparirà una richiesta di unione. Tra le novità in arrivo è indicata anche una scheda Agents & Tools potenziata, che offrirà una panoramica delle conversazioni con gli agenti e dei canali dedicati al codice, con informazioni sullo stato, sui membri dei canali e sul contesto recente, oltre alla possibilità di consultare i canali pubblici dedicati al codice.

Slack ha indicato tre modi per iniziare: consultare la documentazione e aggiungere l’API al manifest di un agente, inviare un agente allo Slack Marketplace oppure provare gli agenti Slack Code disponibili nel marketplace, tra cui Claude, Devin, GitHub Copilot e Vercel.