AIREITERCambiare modello non dovrebbe costringere a riscrivere tutta l’orchestrazione. Eppure è proprio questo tipo di lavoro a far slittare i progetti basati sugli agenti. Il Microsoft Copilot harness in Microsoft Foundry è la risposta gestita di Microsoft: lo stesso livello di esecuzione alla base di Copilot Code, Copilot Studio, dell’app GitHub Copilot, della CLI e di Visual Studio Code, ora disponibile in anteprima pubblica con runtime gratuito fino al 1° dicembre 2026 (blogs.microsoft.com). È un buon momento per sperimentare, ma per la produzione conviene restare sullo stack attuale finché i limiti dell’anteprima descritti sotto non saranno risolti.
Cosa fa davvero Microsoft Copilot harness
Microsoft Copilot harness è il livello di orchestrazione gestito che circonda il modello e trasforma il ragionamento in attività completate. Microsoft mette a disposizione il ciclo dell’agente, la sandbox, la governance e le ottimizzazioni; allo sviluppatore restano istruzioni, skill, strumenti e scelta del modello.
La definizione di Microsoft è piuttosto diretta: «Se il modello fornisce l’intelligenza, il harness è tutto ciò che sta intorno al modello» (blogs.microsoft.com). In pratica, il harness gestisce il contesto di lavoro mentre l’attività procede, coordina chiamate al modello e agli strumenti, esegue file e codice in una sandbox, delega sottoattività circoscritte agli agenti secondari integrati e applica limiti e confini di policy configurati (devblogs.microsoft.com).
| Responsabilità | Gestita da Microsoft Foundry | A tuo carico |
|---|---|---|
| Ciclo dell’agente ed esecuzione in sandbox | Sì | No |
| Governance, approvazioni e ottimizzazione | Sì | Configurazione |
| Istruzioni e skill | No | Sì |
| Strumenti, server MCP e knowledge base | No | Sì, con autenticazione configurata da te |
| Scelta del modello | Elenco supportato | Il deployment scelto |
Routing multi-modello con oltre 20 modelli frontier e BYOK
Microsoft Copilot harness supporta più di 20 modelli frontier appartenenti a diverse famiglie, anche con configurazioni bring-your-own-key (BYOK), e indirizza il lavoro verso il modello o i modelli più adatti in base all’attività (blogs.microsoft.com). Nell’annuncio Microsoft non pubblica l’elenco completo dei 20 modelli: prima di progettare un’architettura multi-modello, verifica quindi quali siano effettivamente disponibili nella tua area Foundry. L’idea è smettere di mantenere un router personalizzato: «Tu porti istruzioni, skill, strumenti e scelta del modello».
Un primo sviluppatore ha riassunto così il vantaggio: non dover riscrivere il livello di orchestrazione ogni volta che cambia il modello — @ai_fengshou.
Runtime Rust e prodotti già alimentati dal harness
Il runtime di Microsoft Copilot harness è stato recentemente portato in Rust. Secondo Microsoft, questo ha ridotto l’overhead delle sessioni e il time-to-first-token (blogs.microsoft.com). Non sono stati pubblicati né percentuali di miglioramento né tabelle sulla latenza: per ora, quindi, è meglio considerare il dato come un’indicazione generale.
Microsoft afferma che lo stesso harness alimenta già Copilot Code, Copilot Studio, l’app GitHub Copilot, la GitHub Copilot CLI, Visual Studio Code e altre esperienze Microsoft e GitHub Copilot (blogs.microsoft.com). La base condivisa, spiega l’azienda, è stata testata con milioni di utenti e centinaia di casi d’uso reali (blogs.microsoft.com).
Il harness è estensibile tramite Model Context Protocol (MCP), agent skill e agent plugin (blogs.microsoft.com).
Cosa è cambiato il 28 ottobre 2026
Il 28 ottobre 2026 Microsoft ha annunciato due novità collegate: Microsoft Copilot harness è entrato nell’anteprima pubblica di Foundry Agent Service e la resilienza degli agenti ospitati durante le esecuzioni prolungate è diventata generalmente disponibile (devblogs.microsoft.com).
Anche la terminologia sta cambiando: nella documentazione di Copilot Studio si trova ancora l’espressione GitHub Copilot harness, ma nei nomi dei prodotti il termine è ora Microsoft Copilot harness. Le varie pagine verranno aggiornate in momenti diversi (microsoft.com).
Foundry Agent Service offre ora tre livelli di astrazione: prompt agent senza harness, prompt agent con Microsoft Copilot harness in anteprima e hosted agent, con framework sotto il controllo dello sviluppatore (devblogs.microsoft.com). La resilienza per i processi lunghi — la capacità degli hosted agent di riprendersi da interruzioni durante workflow della durata di ore o giorni — è invece già disponibile in versione GA.
Come si costruisce un agente con harness in Foundry
Un agente Foundry con harness viene definito in modo dichiarativo e archiviato insieme al codice dell’applicazione (devblogs.microsoft.com). Gli sviluppatori lo creano e lo testano in Foundry, mantengono le definizioni sotto controllo versione e lo distribuiscono con Azure Developer CLI (azd) oppure dal portale Foundry (devblogs.microsoft.com).
Le skill riutilizzabili trasformano il metodo in un pacchetto
Le skill riutilizzabili raccolgono istruzioni, script, risorse di supporto e procedure che gli agenti possono applicare a più attività. L’esempio documentato usa una skill research-brief in skills/research-brief/SKILL.md, che obbliga l’agente a verificare domanda, pubblico, ambito e periodo temporale, raccogliere prove con strumenti approvati, citare fonti e date, distinguere i fatti dalle interpretazioni e segnalare le evidenze in conflitto.
Gli strumenti connessi restano sotto controllo
Gli strumenti connessi permettono agli agenti di usare quelli di Microsoft Foundry e gli strumenti MCP con autenticazione e approvazioni configurate esplicitamente. L’approvazione è un controllo di governance, ma — come mostrano più avanti le segnalazioni su Reddit — può diventare anche una fonte di attrito in produzione quando gli utenti finali devono affrontare richieste di consenso ripetute.
Esecuzione, file e delega delle attività
Gli agenti lavorano con i file, eseguono codice e delegano attività circoscritte agli agenti secondari integrati, mentre l’agente principale coordina i risultati. Il confronto tra harness di Copilot Studio aggiunge che il harness di derivazione GitHub crea e modifica nativamente file Word, Excel, PowerPoint e PDF, oltre a supportare skill e memoria (learn.microsoft.com).
Definizioni sotto controllo versione e un flag per attivare il harness
Le definizioni degli agenti vivono accanto al codice. L’esempio di Foundry dichiara il harness in azure.yaml (devblogs.microsoft.com):
harness:
type: microsoft_copilot_previewL’esempio collega il prompt agent research-brief alla skill research-brief-skill, con ricerca web (public-research) e Code Interpreter (research-analysis), usando FOUNDRY_PROJECT_ENDPOINT e MODEL_DEPLOYMENT_NAME come variabili d’ambiente (devblogs.microsoft.com). Il deployment e l’invocazione passano dalla CLI in anteprima:
azd deploy --all
azd ai agent invoke research-brief \
"Compare publicly announced approaches to agent interoperability. Produce a concise brief with sources, tradeoffs, and open questions."Gli altri percorsi di authoring includono il portale Foundry, Foundry Toolkit per Visual Studio Code e il plugin Foundry per l’app GitHub Copilot (devblogs.microsoft.com).
Quale percorso per gli agenti Foundry scegliere
Non esiste un unico livello di astrazione adatto a tutti. La raccomandazione di Microsoft è scegliere il livello che garantisce la soluzione richiesta con il minor carico possibile di infrastruttura a tuo carico (devblogs.microsoft.com). Durante l’anteprima la scelta viene fissata al momento della creazione, quindi va fatta prima di premere il pulsante di creazione.
| Approccio | Quando usarlo | Cosa offre | A cosa rinunci |
|---|---|---|---|
| Prompt agent senza harness | Bastano istruzioni e strumenti supportati | La soluzione più semplice, con la minore responsabilità operativa | Niente skill, gestione dei file, agenti secondari o orchestrazione avanzata |
| Prompt agent con Microsoft Copilot harness (anteprima) | Servono skill, esecuzione gestita, file, agenti secondari e coordinamento complesso degli strumenti | Ciclo e sandbox gestiti, skill riutilizzabili ed esecuzione più completa | Si applicano i limiti dell’anteprima; Microsoft controlla una parte maggiore del runtime e valgono i vincoli su modelli, strumenti e aree geografiche supportati |
| Hosted agent | Devi portare o modificare framework, ciclo, middleware o dipendenze | Massimo controllo con hosting gestito da Foundry | Checkpoint, logica di ripresa e prevenzione delle azioni duplicate sono a tuo carico |
Tra i primi segnali riportati da Microsoft ci sono Confluence Technologies, che avrebbe distribuito una soluzione in meno di una settimana concentrandosi sul design invece che sull’infrastruttura, e Fashable, che usa il harness per workflow di sourcing governati mantenendo sotto controllo umano le decisioni con valore commerciale vincolante (devblogs.microsoft.com).
Quanto costa dopo il 1° dicembre 2026
La fatturazione del runtime di Microsoft Copilot harness inizierà il 1° dicembre 2026, con un modello a consumo. L’utilizzo del runtime precedente a quella data è gratuito, ma l’inferenza dei modelli, gli strumenti fatturati separatamente e i servizi connessi vengono addebitati separatamente per tutto il periodo.
| Risorsa della sandbox | Prezzo dal 1° dicembre 2026 |
|---|---|
| Calcolo sandbox | $0.0994 per vCPU-ora |
| Memoria sandbox | $0.0118 per GiB-ora |
I prezzi possono variare in base all’area geografica e all’accordo con il cliente (devblogs.microsoft.com). Durante l’anteprima Foundry gestisce CPU, memoria e impostazioni di inattività dell’ambiente di esecuzione (devblogs.microsoft.com) e rimanda alla documentazione specifica per aree, modelli, strumenti e limiti dell’anteprima supportati.
In Copilot Studio, gli agenti basati sul harness di derivazione GitHub vengono fatturati tramite Copilot Credits con un modello a consumo: è un sistema distinto dalla misurazione della sandbox di Foundry (learn.microsoft.com). Per stimare un progetto pilota, moltiplica le ore-vCPU e le ore-GiB della sandbox osservate per le tariffe sopra indicate, poi aggiungi i costi dei token del modello e degli strumenti.
Limiti dell’anteprima da verificare prima di iniziare
In un progetto pilota, sono i dettagli a determinare se la soluzione reggerà il passaggio alla produzione. I vincoli seguenti provengono dal post ufficiale di Microsoft su Foundry, salvo dove indicato che si tratta di segnalazioni degli utenti.
- La scelta del harness, per ora, è definitiva. Il harness si seleziona quando si crea l’agente; quelli già esistenti restano invariati e al momento non è possibile cambiarlo dopo la creazione. Un primo lettore ha segnalato proprio questo: «scegli il Copilot harness quando crei l’agente. Gli agenti esistenti restano invariati e per ora non è possibile cambiare harness dopo la creazione» — @navaneethan_es.
- Aree e modelli sono limitati. Per l’elenco completo, Foundry rimanda alla documentazione su aree, modelli, strumenti e limiti dell’anteprima supportati. Secondo il riepilogo di un utente, ci sarebbero circa nove aree, senza copertura del Medio Oriente e senza un BYOM completo — @HeshamSaadZaki. È una lettura riportata da un utente da verificare nella documentazione, non una tabella ufficiale delle aree.
- Il recupero dei processi lunghi resta a carico del codice. Foundry riavvia il lavoro interrotto degli hosted agent e ripropone l’input originale, ma l’applicazione deve salvare lo stato di avanzamento, ripartire dai checkpoint e impedire azioni duplicate, come la creazione due volte dello stesso report esterno. La sola cronologia della conversazione non ripristina il lavoro in corso.
- Il lancio non include benchmark o numeri SLA. Sono disponibili affermazioni qualitative come «prestazioni leader del settore», ma non tabelle su latenza, throughput o accuratezza.
Cosa hanno incontrato in produzione i primi utenti del Copilot harness
Gli utenti di Copilot Studio che lavorano con il harness di derivazione GitHub segnalano problemi ricorrenti nel passaggio dall’anteprima alla produzione. Sono esperienze relative al GitHub harness di Copilot Studio precedenti all’anteprima Foundry, riportate qui come inferenza sulla linea tecnologica condivisa descritta da Microsoft (blogs.microsoft.com), non come misurazioni di Foundry.
«Dannazione, in produzione i connettori non restano collegati nemmeno per un giorno.» — u/roberts2727 in r/copilotstudio
«A volte i flussi funzionano; altre volte l’agente non passa loro proprio nulla.» — u/donstazz in r/copilotstudio
«Gli utenti aziendali non possono occuparsi di queste app registration e simili: devono farlo gli amministratori IT. Per ogni singolo agente.» — u/Teemu_St in r/copilotstudio
Problemi segnalati in quelle discussioni:
- Risposte più lente negli agenti basati su SharePoint, descritte come significativamente più lente rispetto alle alternative in r/copilotstudio.
- Agenti che funzionano nel pannello di test di Studio ma falliscono dopo la distribuzione su Teams o M365 Copilot, mostrando errori generici in r/copilotstudio.
- Instabilità di connettori e flussi, oltre ad attriti legati all’autenticazione ripetuta e al consenso per MCP in r/copilotstudio.
- Confusione sulla fatturazione: non è chiaro se una licenza M365 Copilot copra il runtime del harness o se si applichino comunque i Copilot Credits, come discusso in r/microsoft_365_copilot.
Nulla di tutto questo smentisce l’anteprima di Foundry, ma definisce la checklist per il progetto pilota: prova la soluzione con la tua fonte di conoscenza reale, il tuo canale effettivo e il flusso di consenso che dovranno usare gli utenti finali, prima di promettere tempistiche.
FAQ
Microsoft Copilot harness è la stessa cosa di GitHub Copilot harness?
Sì: la linea tecnologica sviluppata da GitHub è la stessa, ma ora usa il nuovo nome Microsoft. Durante la transizione, alcuni documenti di Copilot Studio continuano a usare la denominazione precedente.
Quali modelli supporta il harness di Foundry?
Più di 20 modelli frontier, oltre a BYOK con routing basato sull’attività. Microsoft non pubblica l’elenco completo: controlla quindi la documentazione Foundry relativa alla tua area geografica, come indicato nella sezione sul multi-modello.
Posso migrare un agente Foundry esistente al harness?
No, durante l’anteprima non è possibile cambiarlo direttamente. Esegui una valutazione parallela: fai l’inventario di prompt, strumenti, autenticazione e requisiti di stato, ricrea l’agente con microsoft_copilot_preview in un progetto di anteprima, quindi confronta qualità, latenza, utilizzo della sandbox e capacità di recupero prima del passaggio definitivo.
Una licenza M365 Copilot copre l’utilizzo del harness?
Non automaticamente. Foundry misura separatamente calcolo e memoria della sandbox rispetto all’inferenza del modello, mentre Copilot Studio fattura questa famiglia di harness tramite Copilot Credits. Verifica quale misuratore si applica alla superficie che stai utilizzando.
Meglio usare il harness o un hosted agent?
Scegli il harness se vuoi ciclo gestito, sandbox, skill e agenti secondari senza occuparti direttamente dell’orchestrazione. Scegli un hosted agent quando devi controllare framework o runtime e puoi gestire checkpoint e idempotenza.
Parti in anteprima dal modello di skill research-brief, misura il costo della sandbox e dei token rispetto a un prompt agent senza harness impegnato sulla stessa attività e mantieni la produzione sul percorso già collaudato finché migrazione, aree disponibili e gestione del consenso non saranno documentate per il tuo tenant.