Gli artefatti vengono prima dei log
Un’orchestrazione multi-agente si giudica da ciò che lascia dietro di sé, e il primo artefatto rivedibile non è un file di log: è la pull request. La documentazione di GitHub descrive il pattern delle stacked pull requests, cioè una serie di pull request nello stesso repository in cui ognuna punta al branch di quella sotto, formando una catena ordinata che atterra su un unico branch. La regola operativa è che ogni livello sia un cambiamento coerente e rivedibile da solo, e abbastanza piccolo da leggersi in fretta: così due revisori possono guardare in parallelo il modello dati e gli endpoint senza attraversare tutta la feature. Tradotto in linguaggio di orchestrazione: una unità di lavoro, una pull request, un diff. È il modo più economico per rendere leggibile chi ha fatto cosa.
Sul cloud agent la revisione umana resta obbligatoria per costruzione: la doc avverte che la tua approvazione di una pull request di Copilot non conta ai fini delle approvazioni richieste, e che per impostazione predefinita i workflow di Actions non partono sulle modifiche dell’agente — vanno abilitati con Approve and run workflows dopo aver ispezionato il diff, in particolare le modifiche sotto .github/workflows/. Nei GitHub Agentic Workflows gli artefatti sono invece dichiarati in anticipo: le operazioni di scrittura sono ammesse soltanto attraverso i safe-outputs elencati nel frontmatter, per esempio create-issue, add-comment, create-pull-request. Chi legge il Markdown sa già quali tracce quel workflow potrà produrre, e il .lock.yml generato da gh aw compile è a sua volta un artefatto versionato nel repository.
Dove vive la traccia, superficie per superficie
Il cloud agent espone la sua storia nella agents page (github.com/copilot/agents) e nel pannello agenti raggiungibile da qualsiasi pagina di GitHub. Aprendo una sessione si accede al session log e alla panoramica, dove si seguono l’avanzamento, il consumo di token e la durata; il log mostra il ragionamento interno di Copilot e gli strumenti che ha usato. Da lì si può inviare un prompt di follow-up, fermare la run con Stop session o archiviare la sessione dal menu a tre punti. L’elenco distingue le sessioni cloud condivise, visibili ai collaboratori del repository, dalle sessioni locali di CLI, VS Code, JetBrains o app GitHub Copilot.
Sulla Copilot CLI lo strumento di analisi a posteriori è Chronicle, esposto dallo slash command /chronicle con sottocomandi come standup, search, tips, improve, cost tips e reindex. Chronicle indicizza le sessioni di Copilot CLI, del cloud agent, di Copilot code review, di VS Code, di JetBrains e dell’app GitHub Copilot, e i dati di sessione comprendono i tuoi prompt, le risposte di Copilot, gli strumenti usati e i dettagli dei file modificati. Attenzione alla dipendenza: per impostazione predefinita la CLI sincronizza i dati di sessione verso l’account GitHub, ed è proprio il sync che permette di interrogarle da dispositivi e piattaforme diverse. Si può rinunciare impostando "remoteExport": false nel settings JSON della CLI, e in azienda la disponibilità è governata dalla policy Store local sessions in the Cloud. /session delete e /session delete-all rimuovono le sessioni. Corollario: se il sync è spento, l’analisi a posteriori centralizzata non esiste, per quanto tu abbia orchestrato bene.
Il Copilot SDK è l’unica superficie con telemetria strutturata: si passa una configurazione di telemetria con un otlpEndpoint HTTP (in alternativa un exporter su file in formato JSON-lines) e le tracce finiscono in un collector OpenTelemetry. Il pezzo importante per il multi-agente è la propagazione del W3C Trace Context, con traceparent e tracestate sui payload JSON-RPC di session.create, session.resume e session.send: gli span della tua applicazione e quelli della CLI si uniscono in una singola trace distribuita. Sugli eventi in streaming trovi il ciclo di vita dei sotto-agenti — subagent.started, subagent.completed, subagent.failed — e la distinzione fra eventi effimeri, che passano in tempo reale e non vengono scritti nel session log, ed eventi persistiti, salvati su disco e riprodotti al resume. Sulla persistenza vale un consiglio che la doc dà esplicitamente in chiave di audit: fornisci tu un sessionId significativo, perché senza id la sessione non è ripristinabile e non è tracciabile.
Nei GitHub Agentic Workflows, infine, i log sono quelli normali delle run di Actions, più due comandi dedicati.
gh aw logs
gh aw audit RUN-IDStrumentare decisioni e passaggi di consegna
Documentare gli handoff non è un commento gentile a fine giornata: è il punto in cui l’orchestrazione diventa verificabile. Gli hooks servono esattamente a questo, perché eseguono comandi locali (bash o powershell) su eventi definiti — fra gli altri sessionStart, sessionEnd, userPromptSubmitted, preToolUse, postToolUse, postToolUseFailure, subagentStart, subagentStop, permissionRequest, errorOccurred. Un hook su postToolUse che appende una riga a un file per ogni strumento eseguito produce la traccia che nessun agente scriverà da solo. Nota la geografia della configurazione, perché è materia d’esame: per la CLI convivono livello repository in .github/hooks/, livello utente in ~/.copilot/hooks/, il campo hooks nei settings e i file di policy della macchina; per il cloud agent esiste il solo livello repository, .github/hooks/.
Analisi a posteriori e che cosa verifica l’esame
Sopra le singole sessioni c’è il piano enterprise. In AI controls la sezione Agent sessions mostra le sessioni più recenti dell’enterprise, con View all per l’elenco completo, e i filtri disponibili sono agent, organization, repository, status, timeframe e user. L’audit log è il secondo canale: actor:Copilot isola le azioni compiute dagli agenti, il campo actor_is_agent vale sempre true sugli eventi agentici e le voci registrano l’azione svolta, per esempio pull_request.create. Poiché la retention on-platform è limitata, per uno storico più lungo e per gli alert la doc indirizza allo streaming verso un SIEM; i dati di utilizzo sono inoltre recuperabili via REST API con gli endpoint delle Copilot usage metrics.
La confusione tipica da evitare è mescolare le superfici. Le tracce OpenTelemetry sono una capacità dell’SDK, non del cloud agent; Chronicle è un comando della Copilot CLI che però indicizza sessioni di più superfici e dipende dal sync; i filtri delle agent sessions e l’audit log sono strumenti dell’amministratore, non dello sviluppatore che orchestra. Se una domanda ti chiede come ricostruire il comportamento di una flotta di sotto-agenti in produzione, la risposta plausibile combina eventi dell’SDK verso un collector e artefatti su GitHub; se ti chiede chi ha avviato quali agenti la settimana scorsa in tutta l’organizzazione, la risposta sta in AI controls e nell’audit log.