GitHub Agentic Workflows ora disponibili: cosa sono, come si attivano e cosa limitano

Il 28 ottobre 2026 GitHub ha dichiarato disponibile in versione stabile GitHub Agentic Workflows, il progetto open source di GitHub Next che permette di far girare agenti di coding dentro GitHub Actions scrivendo le istruzioni in Markdown. La notizia, nel changelog ufficiale, interessa chi gestisce repository con molte issue, test che falliscono senza una causa chiara e documentazione che invecchia: sono i compiti che il changelog elenca come casi d'uso.

GitHub Agentic Workflows è un sistema che trasforma un file Markdown in un workflow di GitHub Actions in cui un agente AI legge il repository e propone azioni. Non sostituisce Actions: ci gira sopra, con gli stessi runner e gli stessi vincoli di policy.

Cosa cambia con i GitHub Agentic Workflows

Prima di questo annuncio chi voleva un agente dentro Actions doveva scrivere il YAML a mano, gestire le credenziali e inventarsi un modo per limitare ciò che l'agente poteva toccare. Ora il file è Markdown: nel frontmatter si dichiarano il trigger e le scritture consentite, nel corpo si descrive in italiano o in inglese cosa deve fare l'agente. L'esempio della documentazione ufficiale è un daily-issue-summary.md con on: daily e safe-outputs: create-issue, e un'istruzione in linguaggio naturale per riassumere le issue del giorno.

Il comando gh aw compile trasforma quel file in un workflow Actions con le dipendenze fissate. Un dettaglio utile per chi si occupa di sicurezza: l'annuncio dice che i workflow possono essere alimentati da GitHub Copilot oppure da un agente a scelta, e la documentazione elenca Copilot, Claude Code, Codex e Antigravity, più Pi per i provider multipli.

Cosa include la versione stabile

Secondo il changelog, la versione stabile aggiunge il supporto ai runner self-hosted con Actions Runner Controller, compreso Docker-in-Docker, la scelta del provider di modelli per singolo workflow e un router che sceglie il modello in base al tipo e alla difficoltà del compito. Aggiunge inoltre l'isolamento dell'agente con Cloud Hypervisor o micro-VM NVX, enclave per i workflow che toccano più repository e nuovi modelli di workflow installabili con gh aw add-wizard. Il comando gh aw forecast, prima sperimentale, stima la spesa in crediti AI.

Come si attiva GitHub Agentic Workflows

La guida rapida parte da tre requisiti: un repository in cui hai accesso in scrittura, GitHub Actions abilitato nelle impostazioni, la GitHub CLI nella versione 2.0.0 o successiva con autenticazione valida. Se serve, l'accesso si rinnova con gh auth login --scopes repo,workflow. Funziona su Linux, macOS e Windows con WSL.

L'installazione è un solo comando, seguito dal workflow di esempio che la guida propone come prima prova:

gh extension install github/gh-aw
gh aw add-wizard githubnext/agentics/repo-status

La procedura guidata controlla i prerequisiti, ti fa scegliere il motore AI, configura l'autenticazione e aggiunge i file in .github/workflows/, con un push diretto o con una pull request. La guida indica 2-3 minuti per la prima esecuzione, che si segue con gh aw status e gh run watch. Se va a buon fine, compare nelle Issues un rapporto dal titolo "Daily Repo Report". Dopo ogni modifica al frontmatter va rieseguito gh aw compile, e vanno committati sia il file .md sia il .lock.yml generato.

Quale segreto serve per quale motore

Con Copilot l'opzione consigliata dalla guida per chi ce l'ha già è l'addebito a livello di organizzazione, che richiede un abbonamento con fatturazione centralizzata; in alternativa un token personale con il permesso Copilot Requests in lettura, salvato con gh secret set COPILOT_GITHUB_TOKEN. Per Claude serve una chiave API Anthropic salvata come ANTHROPIC_API_KEY, e la guida precisa che un token OAuth di claude login non è supportato. Per Codex si usa OPENAI_API_KEY, per Gemini GEMINI_API_KEY.

Quanto è sicuro far girare un agente dentro Actions

La documentazione descrive sei livelli di difesa: validazione in fase di compilazione, agente in sandbox con permessi di sola lettura, credenziali isolate dietro un proxy per le API, filtro di integrità sui contenuti non fidati di GitHub, rilevamento delle minacce sui risultati proposti e safe outputs. Quest'ultimo è il meccanismo che conta di più: l'agente non scrive nulla da solo, e un job separato applica soltanto le scritture dichiarate nel frontmatter. Con staged: true si può vedere cosa verrebbe scritto senza scrivere nulla.

Dal punto di vista pratico, questo cambia la domanda che bisogna farsi prima di attivare un workflow. Non è più "cosa può fare l'agente", ma "quali scritture ho dichiarato". Se il frontmatter permette di creare issue e non pull request, l'agente non apre pull request. Il principio è lo stesso discusso in chi controlla gli agenti AI in azienda e nelle assisted permissions di Copilot: i permessi si decidono prima, non si scoprono dopo.

Limiti e cose che la fonte non dice

Il changelog non pubblica prezzi né limiti d'uso. Dice che il motore predefinito, Copilot CLI, richiede una licenza Copilot, e che la disponibilità riguarda github.com per i piani Free, Team ed Enterprise. Non indica quanto costi in crediti un workflow tipico, né quanto una threat detection aggiunga al conto: per questo il consiglio è provare gh aw forecast su un workflow di prova prima di collegarlo a trigger frequenti.

Un altro dato da tenere presente: la sicurezza descritta è quella dichiarata da GitHub, e non l'ho verificata con prove proprie. Un agente che legge issue e commenti di terzi lavora su testo che chiunque può scrivere, ed è il motivo per cui il filtro sui contenuti non fidati esiste. Per i repository pubblici partirei da un workflow che crea solo issue e non tocca il codice. Se poi l'obiettivo è far correggere all'agente pull request e test, il confronto è con Agent Merge di GitHub Copilot, che fa una parte di quel lavoro direttamente dall'interfaccia, e conviene leggere anche cosa resta alla persona nella revisione del codice.