Microsoft Copilot Harness arriva tramite Foundry, cambiando la decisione tra sviluppo interno e acquisto

Microsoft ha reso disponibile il proprio Microsoft Copilot harness tramite Foundry il 28 ottobre, estendendo agli sviluppatori una base di esecuzione interna pur mantenendone il controllo operativo. Un harness è il software che circonda un modello di AI e organizza istruzioni, contesto, strumenti ed esecuzione. L'annuncio cambia ciò che le aziende possono acquistare anziché sviluppare, senza eliminare la loro responsabilità per il lavoro risultante.

La scelta centrale è se mantenere internamente tale meccanismo di esecuzione o adottare l'approccio gestito da Microsoft. Un agente, software che utilizza modelli e strumenti per perseguire un'attività, necessita di più del semplice accesso a un modello capace. Qualcuno deve decidere come prosegue, come gestisce i guasti e come rimane entro i confini aziendali.

Anthropic offre già un approccio gestito concorrente, fornendo agli acquirenti un utile riferimento al di là della famiglia di prodotti Microsoft. La proposta distintiva di Microsoft enfatizza l'accesso a diverse famiglie di modelli attraverso un'infrastruttura condivisa. Per i team di sviluppo, ciò solleva una domanda pratica: quali responsabilità diventano più facili da delegare e quali richiedono ancora un giudizio specifico dell'applicazione?

Microsoft Copilot Harness entra nell'anteprima pubblica di Foundry

Microsoft sta trasformando una base di prodotto condivisa in un componente gestito per le applicazioni dei clienti.

Secondo l'annuncio dell'harness multi-modello di Microsoft, il team di ingegneria di GitHub ha sviluppato l'harness prima che Microsoft lo adottasse nelle esperienze Copilot. L'azienda identifica tra i suoi utenti Copilot Code, Copilot Studio, l'app GitHub Copilot, l'interfaccia a riga di comando e VS Code.

Foundry Agent Service, la piattaforma Microsoft per creare e gestire agenti, offre ora l'harness in anteprima pubblica. Questo stato è rilevante perché l'annuncio combina una tecnologia interna consolidata con un servizio gestito reso disponibile di recente. L'esperienza all'interno dei prodotti Microsoft non dimostra automaticamente la preparazione per il carico di lavoro di ogni cliente esterno.

Microsoft descrive una ripartizione delle responsabilità in cui gestisce il meccanismo di esecuzione, mentre i clienti forniscono istruzioni e connessioni specifiche per le loro applicazioni. Questa configurazione rende il lancio rilevante anche oltre gli assistenti di programmazione. Un'azienda che sviluppa un assistente di ricerca o un agente operativo può valutare l'acquisto di un'infrastruttura in precedenza considerata lavoro di ingegneria interno.

L'annuncio descrive anche un kit di sviluppo software scaricabile, un pacchetto che gli sviluppatori usano per integrare la tecnologia nelle applicazioni. Questo percorso non va confuso con l'esperienza Foundry gestita. Scegliere un metodo di distribuzione e scegliere chi gestisce un servizio sono decisioni correlate, ma rispondono a domande diverse.

Per un acquirente aziendale, il cambiamento immediato è un'ulteriore opzione di implementazione. Un team che valuta un agente non deve più presumere che supportare modelli diversi richieda la manutenzione del proprio sistema di esecuzione circostante. Microsoft si offre di mantenere questa base condivisa per conto del cliente.

Questa offerta merita una lettura precisa. Acquistare un harness gestito non dimostra che un determinato flusso di lavoro produca risposte corrette o azioni appropriate. Cambia chi fornisce una parte del meccanismo. L'acquirente necessita comunque di prove che l'applicazione completa soddisfi i propri requisiti.

Si consideri un'ipotetica applicazione di ricerca che confronta gli annunci dei fornitori e prepara un briefing interno. Un risultato utile include fonti accurate, date chiare e un trattamento esplicito delle informazioni in conflitto. Un sistema di esecuzione funzionante supporta questo lavoro, ma non può definire tali requisiti editoriali per l'organizzazione.

Il lancio sposta quindi il punto di partenza delle discussioni architetturali. Invece di chiedersi soltanto quale modello debba rispondere a una richiesta, i team possono chiedersi quali parti dell'esecuzione degli agenti meritino ingegneria personalizzata. È una domanda più rilevante del fatto che un altro modello compaia in un menu di selezione.

La pressione ricade sui team che mantengono il proprio meccanismo di esecuzione

L'offerta di Microsoft sottopone a esame i progetti infrastrutturali interni, soprattutto quando replicano capacità senza creare un vantaggio aziendale.

La pressione maggiore ricade sui team applicativi che già mantengono il meccanismo circostante per gli agenti. I loro responsabili hanno ora un'alternativa esterna da esaminare. Continuare con un'implementazione personalizzata diventa una decisione che richiede giustificazione, anziché un prerequisito automatico per distribuire un agente.

Questa giustificazione può comunque essere convincente. Un'azienda potrebbe richiedere un comportamento di esecuzione insolito, integrazioni specializzate o controllo diretto sul modo in cui il lavoro procede. La distinzione rilevante è se tali requisiti influenzino materialmente l'applicazione. La proprietà personalizzata ha più senso quando l'organizzazione può identificare ciò che quel controllo consente di ottenere.

Acquistare infrastruttura introduce un obbligo diverso: comprendere i confini del fornitore. Un team di sviluppo non può valutare un servizio gestito soltanto attraverso le capacità mostrate in una dimostrazione. Deve identificare dove termina la piattaforma e dove iniziano il proprio software, le proprie procedure e la propria supervisione.

L'annuncio di Microsoft sull'esecuzione gestita degli agenti illustra competenze, strumenti connessi, esecuzione di file e codice e delega delimitata. Le competenze sono procedure riutilizzabili confezionate con istruzioni e risorse di supporto. Gli strumenti consentono agli agenti di accedere a informazioni o azioni esterne. Queste capacità descrivono una base applicativa più ampia della sola generazione di testo.

Lo stesso annuncio offre una prospettiva iniziale di un cliente. Chris Evans, chief technology officer di Confluence Technologies, afferma che l'azienda ha messo in funzione una soluzione in meno di una settimana. Si tratta di un utile aneddoto di implementazione, sebbene non stabilisca una tempistica di distribuzione tipica né un risultato operativo a lungo termine.

Per gli acquirenti, la distinzione importante è tra raggiungere uno stato iniziale funzionante e mantenere un servizio affidabile. Un prototipo interno può tollerare presupposti che un'applicazione operativa non può accettare. Una base gestita può abbreviare parte del lavoro di ingegneria lasciando irrisolti controlli sulle integrazioni, criteri di accettazione e decisioni sulla responsabilità.

Un confronto finanziario utile dovrebbe quindi esaminare il flusso di lavoro completo anziché una singola risposta di modello. Le considerazioni rilevanti includono manutenzione ingegneristica, indagine sui guasti, revisione umana e modifiche ai sistemi connessi. Dal lancio non deriva alcun calcolo universale, poiché tali responsabilità differiscono tra le organizzazioni.

La pressione raggiunge anche i fornitori di infrastrutture i cui prodotti circondano i modelli. La distribuzione di Microsoft offre ai clienti un ulteriore motivo per interrogarsi su quali componenti separati siano necessari. Ciò non dimostra che i prodotti indipendenti diventino superflui. Alza il livello richiesto per spiegare il controllo, la visibilità o la specializzazione aggiuntivi che offrono.

Per i knowledge worker, la posta in gioco si presenta in una forma diversa. Essi sperimentano se un agente completa un risultato utilizzabile, preserva le prove corrette e segnala adeguatamente l'incertezza. Un cambiamento architetturale è importante per loro quando riduce il lavoro incompleto o rende gli errori più facili da identificare e correggere.

Ecco perché la discussione tra sviluppo interno e acquisto riguarda i responsabili di prodotto oltre agli ingegneri. L'organizzazione deve definire un risultato soddisfacente prima di decidere quale configurazione infrastrutturale lo realizzi. Altrimenti, una distribuzione tecnicamente riuscita può lasciare in gran parte irrisolto il vero problema aziendale.

La scelta del modello e il controllo del runtime sono decisioni separate

L'accesso a modelli diversi non dà ai clienti un controllo illimitato sul modo in cui il servizio gestito esegue il loro lavoro.

Le FAQ sulla disponibilità dell'harness di Microsoft definiscono i limiti dell'anteprima. Il supporto per modelli propri non è disponibile. I clienti selezionano l'harness quando creano un nuovo prompt agent e non possono cambiarlo successivamente. La disponibilità può inoltre variare in base a regione, client, strumenti, rete e quote.

Queste restrizioni chiariscono il significato del supporto multi-modello. Un cliente può valutare le opzioni supportate entro i confini del servizio. Ciò è diverso dal presumere che qualsiasi modello, connessione o configurazione di distribuzione funzionerà semplicemente perché la strategia più ampia enfatizza la scelta.

La distinzione conta durante l'approvvigionamento. La presenza di un modello altrove nel portafoglio di un fornitore non risponde alla domanda se sia supportato in una specifica esperienza gestita. Gli acquirenti devono valutare la combinazione che intendono utilizzare, compresa la posizione di distribuzione pertinente e i sistemi connessi.

Esiste anche una distinzione tra cambiare un modello e preservare il comportamento di un'applicazione. Anche se un'interfaccia rimane coerente, un modello diverso può produrre decisioni o risultati diversi. I responsabili dell'applicazione dovrebbero considerare una modifica del modello come qualcosa da valutare rispetto ai requisiti aziendali, anziché come una sostituzione amministrativa.

Si consideri un ipotetico assistente agli acquisti che esamina una proposta di un fornitore. Un compito consiste nell'estrarre le date di consegna. Un altro nell'interpretare una clausola di annullamento ambigua. L'organizzazione potrebbe preferire caratteristiche di modello diverse per tali attività, ma necessita comunque di una definizione coerente delle prove accettabili e dell'escalation.

Una base di esecuzione condivisa può rendere più semplice organizzare questo confronto. Non dimostra che le stesse istruzioni funzionino altrettanto bene su tutti i modelli supportati. Il risultato utile è un'opportunità controllata per confrontare i risultati, con registrazioni chiare di cosa è cambiato e perché.

L'architettura degli agenti gestiti di Anthropic fornisce un confronto competitivo pertinente. Il suo resoconto tecnico dell'aprile 2026 descrive la separazione tra modello e harness, da un lato, e ambienti di esecuzione e registrazioni di sessione persistenti, dall'altro. L'obiettivo dichiarato è consentire alle implementazioni di evolvere dietro interfacce stabili.

Questo confronto mostra perché la concorrenza del settore va oltre la selezione dei modelli. I fornitori competono anche su quali responsabilità di esecuzione possano assorbire mantenendo un'interfaccia su cui i clienti possano fare affidamento. L'enfasi di Microsoft su più famiglie di modelli affronta una dimensione di quella più ampia decisione di acquisto.

Nessuna delle due descrizioni architetturali stabilisce un vincitore universale. Un'azienda che sceglie tra approcci gestiti deve confrontare il proprio flusso di lavoro effettivo, le integrazioni richieste e i vincoli operativi. Un servizio che si adatta bene a un'applicazione può imporre presupposti inadatti a un'altra.

Il compromesso più profondo riguarda dove risieda la flessibilità. Un team può mantenere la possibilità di scelta tra modelli supportati accettando al contempo il design di esecuzione del fornitore. In alternativa, può preservare maggiore controllo sull'esecuzione e assumersi la responsabilità di mantenerlo. Sono forme distinte di flessibilità, con conseguenze ingegneristiche differenti.

Per il harness Microsoft Copilot, l'interpretazione pratica più solida è quindi quella della scelta circoscritta. I clienti ottengono un ulteriore percorso gestito per lo sviluppo di agenti. Dovrebbero valutare tale percorso in base alle sue capacità documentate, anziché considerare il branding più ampio come una promessa di compatibilità universale.

I risultati di valutazione di Microsoft richiedono un'interpretazione attenta

I risultati interni di Microsoft giustificano ulteriori valutazioni, ma non dimostrano vantaggi equivalenti per ogni applicazione Foundry.

Nei suoi risultati di valutazione degli agenti, Microsoft confronta il harness Copilot con il harness Standard in Copilot Studio. Riporta miglioramenti del tasso di superamento di 10,8 punti percentuali con un modello OpenAI e di 22,1 punti percentuali con un modello Anthropic.

Microsoft riferisce inoltre tentativi proseguiti dopo chiamate a strumenti non riuscite nell'84–91% dei casi valutati, rispetto a meno del 7% con il harness Standard. Le note di accompagnamento distinguono esplicitamente tra l'uso continuato degli strumenti e i nuovi tentativi riusciti, da un lato, e il completamento riuscito dell'intero compito, dall'altro. Si tratta di risultati riportati dall'azienda, senza una validazione indipendente qui stabilita.

Questa precisazione è centrale per interpretare l'annuncio. La persistenza descrive il comportamento dopo che qualcosa è andato storto. Il completamento descrive se è stato raggiunto il risultato richiesto. Un sistema può continuare a operare e tuttavia fraintendere il compito, usare prove inadeguate o produrre un risultato inaccettabile.

La differenza diventa concreta in un ipotetico flusso di assistenza clienti. Un agente potrebbe riprovare con successo ad accedere a un record del caso, ma raccomandare comunque la risoluzione sbagliata. Misurare il recupero da una connessione fallita aiuta a spiegare il comportamento di esecuzione. Non stabilisce se il cliente abbia ricevuto una risposta accurata.

Allo stesso modo, un tasso di superamento della valutazione più elevato dipende da ciò che la valutazione richiede. Gli acquirenti devono comprendere i compiti pertinenti, i criteri di accettazione e le configurazioni prima di trasferire un risultato nel proprio ambiente. Un miglioramento in punti percentuali è informativo solo in relazione al test che misura.

Ciò non riduce l'importanza del sistema di esecuzione circostante. Il confronto riportato da Microsoft è coerente con l'argomento secondo cui la sola capacità del modello non determina gli esiti degli agenti. Offre ai clienti un motivo per testare le scelte di esecuzione insieme a quelle relative ai modelli, mantenendo esplicite attribuzione e limitazioni.

Microsoft descrive inoltre un'applicazione interna di supporto che ha superato un tasso di risoluzione completamente autonoma del 35% nell'agosto 2026. L'azienda definisce questa misura come la risoluzione dei casi senza intervento umano. È una distribuzione concreta riportata, ma la sua idoneità come confronto dipende dai casi e dalle condizioni operative.

Per un'impresa che valuta un'applicazione simile, l'autonomia dovrebbe essere considerata insieme a correttezza e conseguenze. Un caso risolto senza intervento può costituire una prova utile quando la risoluzione è accurata e appropriata. La sola assenza di intervento non può dimostrare che il risultato abbia soddisfatto lo standard dell'organizzazione.

La valutazione dovrebbe tenere conto anche del lavoro trasferito ai revisori. Se un agente produce più materiale ma richiede correzioni sostanziali, il volume dell'output può rappresentare in modo fuorviante il suo contributo pratico. La questione aziendale riguarda il lavoro completato e accettabile, nonché lo sforzo necessario per ottenerlo.

La stessa logica si applica ai fallimenti che restano invisibili fino a più tardi. Un briefing rifinito con un'affermazione non supportata può apparire riuscito al momento della consegna. Una valutazione che controlli prove e attribuzione mostrerebbe un esito diverso. I criteri di accettazione dovrebbero riflettere il modo in cui il risultato verrà effettivamente utilizzato.

Per ora, i numeri di Microsoft costituiscono prove utili sui propri ambienti testati. Giustificano un'indagine senza sostituire i test specifici del cliente. Gli acquirenti dovrebbero evitare di trasformare un confronto del fornitore in una previsione per carichi di lavoro che non facevano parte della valutazione riportata.

L'esecuzione gestita lascia comunque al cliente la responsabilità aziendale

Delegare l'infrastruttura non trasferisce la responsabilità di decidere cosa un agente sia autorizzato a fare.

Il confine più chiaro riguarda le azioni con conseguenze rilevanti. Un agente che prepara una raccomandazione e un agente che vincola l'organizzazione a tale raccomandazione richiedono controlli diversi. Un servizio di esecuzione gestita può supportare entrambe le progettazioni, ma l'organizzazione deve decidere dove iniziano e finiscono le autorizzazioni.

Fashable offre una prospettiva del cliente nel materiale di lancio di Microsoft. L'amministratore delegato Orlando Ribas Fernandes descrive opportunità relative ai flussi di approvvigionamento, mantenendo al contempo sotto controllo umano le decisioni commercialmente vincolanti. Si tratta di un confine operativo previsto, non della prova che ogni capacità proposta abbia già prodotto un risultato misurato.

L'esempio illustra perché la responsabilità non può essere dedotta dall'automazione. Un assistente per gli approvvigionamenti potrebbe confrontare specifiche, identificare informazioni mancanti o preparare materiale per la negoziazione. Autorizzare un acquisto introduce una responsabilità diversa. La distinzione dovrebbe rimanere visibile anche quando tali attività appaiono in un'unica conversazione.

Il lavoro di lunga durata introduce un altro confine: ricordare ciò che è accaduto rispetto a sapere cosa resta valido. Un agente può conservare un risultato precedente senza sapere che le circostanze sono cambiate. I responsabili delle applicazioni devono stabilire quando le informazioni precedenti richiedono una nuova verifica e quali decisioni dipendono da prove aggiornate.

La ricerca sugli agenti di lunga durata di Anthropic descrive fallimenti legati a lavoro incompleto e dichiarazioni premature di completamento tra sessioni diverse. L'approccio proposto utilizza registri espliciti di avanzamento e lavoro incrementale. L'insegnamento più ampio è che l'esecuzione continuata richiede una rendicontazione affidabile degli obblighi non completati.

Per le imprese, questo insegnamento suggerisce di trattare il completamento come una condizione aziendale. Un'attività è conclusa quando i suoi criteri di accettazione sono soddisfatti, incluse eventuali revisioni o conferme richieste. Un messaggio finale sicuro di sé non può sostituire la prova che tali condizioni siano rispettate.

Il riavvio di lavoro interrotto crea una preoccupazione correlata. Immaginate un ipotetico agente che prepara un report e lo invia a un altro sistema. Se l'invio riesce ma la conferma va persa, ripetere l'azione può creare record duplicati. L'applicazione deve poter distinguere un'azione non completata da un'azione non confermata.

Microsoft ha annunciato separatamente la disponibilità generale della resilienza per attività di lunga durata per gli agenti ospitati, nei casi in cui i clienti portano la propria logica di esecuzione. La documentazione attribuisce al codice dell'applicazione la responsabilità del salvataggio dei progressi e della prevenzione dei duplicati. Questa funzionalità separata non dovrebbe essere considerata una garanzia generalizzata per la nuova anteprima del harness.

La qualità delle informazioni crea un'ulteriore responsabilità. Un agente collegato a indicazioni obsolete può eseguire le proprie istruzioni in modo coerente e produrre comunque lavoro inadeguato. I team che valutano una base di conoscenza ricercabile dovrebbero considerare l'organizzazione e la manutenzione delle fonti come parte dell'applicazione.

Questa relazione rende la gestione della conoscenza rilevante per il lancio senza implicare una particolare integrazione. L'infrastruttura determina come procede il lavoro; le prove disponibili limitano ciò che l'agente può ragionevolmente concludere. Migliorare l'una non elimina le debolezze dell'altra.

Le organizzazioni dovrebbero quindi assegnare la titolarità dell'intero flusso di lavoro. Qualcuno deve essere responsabile del materiale di origine, delle autorizzazioni, dei criteri di accettazione e delle correzioni quando gli esiti falliscono. L'esecuzione gestita può modificare il carico ingegneristico, ma non elimina queste decisioni organizzative.

Il caso di adozione più credibile identifica sia il lavoro assorbito dal fornitore sia gli obblighi che il cliente conserva. Questa chiarezza rende più semplice giudicare se il servizio riduca la complessità complessiva. Impedisce inoltre che un prototipo riuscito diventi un'applicazione di cui nessuno possiede pienamente la responsabilità.

Tre segnali mostreranno se l'approccio gestito mantiene le promesse

Le prossime prove utili riguardano la maturità del servizio, gli esiti comparativi e le operazioni dei clienti, anziché ulteriori affermazioni di lancio.

Il primo segnale è il modo in cui Microsoft svilupperà l'anteprima Foundry nei prossimi mesi. Gli acquirenti dovrebbero osservare una disponibilità più chiara, le configurazioni supportate, le opzioni di migrazione e le indicazioni per la produzione. Un supporto documentato più ampio rafforzerebbe il caso per l'adozione di una base gestita comune in più applicazioni.

L'espansione più significativa affronterebbe un requisito che attualmente blocca una distribuzione reale. Un'altra configurazione supportata è importante quando consente a un'organizzazione di operare entro i propri vincoli tecnici e aziendali. Un elenco di funzionalità più lungo, da solo, dice meno sulla reale fattibilità di una determinata applicazione.

Se le restrizioni dell'anteprima restano significative per l'ambiente previsto dal cliente, il caso per un'adozione immediata si indebolisce per quel cliente. Si tratta di un giudizio specifico del carico di lavoro. Una limitazione può essere irrilevante per un prototipo di ricerca e decisiva per un'applicazione collegata a sistemi operativi sensibili.

Il secondo segnale è costituito da prove comparative che separino le modifiche del modello da quelle dell'esecuzione. Le valutazioni dovrebbero chiarire quale componente è cambiato e come è stato misurato il successo. Ciò aiuterebbe gli acquirenti a determinare se il beneficio riportato deriva dal harness, dal modello o dalla loro interazione.

Valutazioni indipendenti aggiungerebbero fiducia, soprattutto se rendessero pubbliche le categorie di fallimento e i requisiti di revisione. Un confronto incentrato sul lavoro completato rafforzerebbe l'argomento di Microsoft più direttamente di uno incentrato solo sull'attività. Risultati che mostrassero una forte dipendenza dalla configurazione restringerebbero l'applicazione della rivendicazione.

Gli sviluppi competitivi sono rilevanti nello stesso confronto. Cambiamenti all'offerta gestita di Anthropic, o all'approccio di esecuzione di un altro fornitore, possono modificare le alternative disponibili. Gli acquirenti dovrebbero confrontare i servizi rispetto a un requisito applicativo stabile, affinché un mercato in evoluzione non trasformi la valutazione in una rincorsa infinita alle funzionalità.

Il terzo segnale è la rendicontazione dei clienti oltre la velocità di distribuzione iniziale. Resoconti utili descriverebbero l'operatività sostenuta, risultati accettabili, sforzo di correzione e responsabilità mantenute dal cliente. Prove di minore manutenzione insieme a risultati affidabili rafforzerebbero l'argomento per l'acquisto del livello di esecuzione condiviso.

Resoconti di un ampio lavoro personalizzato richiederebbero una lettura più attenta. La personalizzazione può riflettere una preziosa specializzazione aziendale o lacune nel servizio gestito. Comprendere quale spiegazione si applichi conta più che limitarsi a contare quanto codice abbia scritto un cliente.

Questi segnali offrono anche un modo pratico per riesaminare una decisione precedente. Un team può ragionevolmente costruire oggi il proprio sistema di esecuzione e adottare un servizio gestito in seguito. Un altro può iniziare con infrastruttura gestita e mantenerla solo finché l'accordo continua a soddisfare i suoi requisiti.

Valutate l’harness Microsoft Copilot rispetto a un flusso di lavoro che la vostra organizzazione conosce bene. Definite un risultato accettabile, identificate le azioni che richiedono approvazione e registrate i punti in cui resta necessaria la correzione umana. Confrontate l’opzione gestita con il vostro approccio esistente usando le stesse evidenze e gli stessi criteri di completamento. Includete la qualità delle fonti, il comportamento di recupero e l’impegno necessario per analizzare gli errori. Mantenete la decisione legata a responsabilità che il vostro team può realmente delegare, quindi riesaminatela man mano che evolvono il supporto documentato e le evidenze dei clienti. Il lancio di Microsoft crea un’alternativa concreta al mantenimento interno dell’intera infrastruttura di esecuzione. Il passo successivo utile consiste nello stabilire quali parti del vostro flusso di lavoro questa alternativa migliora e quali evidenze potrebbero cambiare la vostra decisione.