Argo's New Dreams

TL;DR — Consegnare un agente AI non significa aver finito il lavoro. Il fornitore aggiorna e ritira il modello linguistico secondo un calendario che non decidi tu; quando il modello cambia, anche prompt, flussi e tono vanno rimessi alla prova. Microsoft lo dice senza giri di parole: la scelta del modello “non è una decisione di design una tantum”. Più che consegnare un prodotto, si tratta di accompagnare un collega.

Intro

“L’agente ce l’avete consegnato a giugno, perché dovremmo pagare ancora qualcosa?”

Da mesi, in alcune sale riunioni, torno su questa domanda. La capisco: se qualcuno mi consegna un tornio, mi aspetto che il tornio resti quello. Ma un agente non è un tornio. Somiglia di più a un collega: va nutrito con dati aggiornati, osservato mentre lavora e, ogni tanto, aiutato a cambiare abito.

Gli abiti sono i modelli linguistici. Non parlo di una cravatta diversa sopra lo stesso completo. Quando cambi modello, cambi ciò che legge le istruzioni, sceglie come rispondere e decide quando usare gli strumenti. Puoi lasciare tutto il resto al suo posto e accorgerti che l’agente non lavora più nello stesso modo.

Il 29 settembre 2026 ho letto un post su LinkedIn di Leandro Nesi, Senior Manager di BIP. Raccontava il cambio di modello sotto una soluzione con decine di migliaia di utenti. Era il caso concreto che mi mancava per dare alla mia allegoria qualcosa di più solido di un attaccapanni.

Background: cosa intendo per “agente” e per “modello”

Un agente AI interpreta la richiesta di un utente, tiene conto di obiettivi e vincoli e può agire chiamando strumenti: API, cioè interfacce con altri sistemi, connettori e basi di conoscenza. Il modello linguistico (LLM, Large Language Model) è il motore che legge il contesto e genera testo o decisioni. L’agente comprende anche ciò che sta attorno al motore: istruzioni (il system prompt), strumenti, dati, flussi e interfaccia.

La distinzione conta. Se cambi motore, non hai necessariamente cambiato l’interfaccia o gli strumenti. Hai però cambiato il modo in cui una parte del sistema interpreta tutto il resto.

IBM, nella sua definizione di agent lifecycle management pubblicata il 23 giugno 2026, parla di “sistemi adattivi” che “richiedono supervisione continua”: “possono produrre output diversi per input simili o scegliere passaggi diversi in base all’intento dell’utente, al contesto disponibile o ai sistemi connessi” (McGrath & Downie, 2026). Il paragone con un’applicazione classica, che una volta compilata fa sempre la stessa cosa, si ferma qui.

C’è poi il particolare che nelle discussioni sulla consegna tende a sparire: il motore non è tuo. Lo usi alle condizioni di un fornitore che può aggiornarlo e ritirarlo. Come ho già scritto parlando di skill e system prompt, le istruzioni dell’agente non sono “un prompt salvato”. Definiscono un comportamento. E quel comportamento dipende anche dal modello che le legge.

Cosa succede a un agente in produzione quando il modello viene ritirato?

L’agente deve passare a un modello sostitutivo, automaticamente o per tua iniziativa. Il passaggio può cambiare le risposte anche se il sistema, dal punto di vista tecnico, continua a funzionare. Alla fine del ciclo, invece, il vecchio modello smette proprio di rispondere: Microsoft Foundry descrive gli stadi Preview, Generally Available, Legacy, Deprecated e Retired; allo stadio finale ogni richiesta restituisce HTTP 410 Gone (Microsoft Learn, s.d.).

Il calendario non è indefinito. Secondo la policy di Microsoft Foundry, il ciclo di vita standard dei modelli in disponibilità generale è di 18 mesi; per i modelli di Anthropic, DeepSeek, Fireworks e Mistral AI è di 12 mesi (Microsoft Learn, s.d.). La Microsoft Tech Community, in un articolo del 31 agosto 2026, porta un caso preciso: gpt-4o (versione 2024-05-13) è in calendario per il ritiro il 1° ottobre 2026, con gpt-5.1 come sostituto [VERIFY: data di ritiro gpt-4o e modello sostitutivo — fonte: Microsoft Learn, Model retirement schedule].

La difficoltà, prima ancora dell’errore definitivo, è riconoscere il cambiamento. L’articolo lo descrive così: “I fallimenti del modello sono spesso silenziosi per i sistemi che lo usano e rumorosi per gli utenti. Niente va in crash. I tassi di errore restano piatti. Ogni dashboard dice che la migrazione è andata bene. Intanto le risposte cambiano forma, i riassunti diventano più lunghi e più cauti, i campi JSON spariscono, le chiamate agli strumenti partono in un ordine diverso” (Microsoft Tech Community, 2026).

È una scena che riconosco. Dal lato tecnico, la dashboard non segnala guasti. Dal lato di chi usa l’agente, qualcosa non torna. Nella mia esperienza, il cliente spesso lo riassume meglio di qualsiasi grafico: “l’agente è diventato strano”.

Copilot Studio offre un margine: dopo un aggiornamento automatico puoi continuare a usare il modello ritirato per 30 giorni, attivando Continue using retired models nelle impostazioni dell’agente (Microsoft Learn, aggiornato 3 agosto 2026). È tempo per lavorare sulla migrazione, non un modo per evitarla.

Perché cambiare LLM non è “cambiare una variabile”?

Perché un prompt non è scritto per un lettore astratto. È stato costruito, corretto e spesso ritoccato attorno alle abitudini del modello precedente. Quando quel lettore cambia, istruzioni rimaste identiche possono avere un effetto diverso. È una migrazione, non soltanto un aggiornamento di versione.

Nesi lo mette al primo posto fra i suoi sette punti: “Ogni riga è tarata sulle abitudini di partenza di quel modello, come una prescrizione di occhiali è tarata su un occhio preciso. Cambi modello, stai cambiando occhio. Le lenti restano le stesse, ma dove prima correggevano un difetto adesso ne creano uno” (Nesi, 2026). Il suo team è passato da GPT-4.1 a GPT-5.6 su una soluzione con decine di migliaia di utenti. Il bilancio, in una frase: “In teoria, poteva essere solo il cambio di una variabile. Spoiler: non lo è stato”.

La documentazione Microsoft per gli agenti Copilot Studio è altrettanto esplicita: “Un agente che funziona bene con un modello può comportarsi in modo completamente diverso con un altro modello, anche un modello della stessa famiglia” e “Un modello più recente può interpretare le istruzioni più letteralmente, scegliere gli strumenti in modo diverso, produrre lunghezza e formattazione delle risposte diverse e cambiare la latenza” (Microsoft Learn, s.d.).

Anche gli studi sui prompt invitano alla cautela. Salinas e Morstatter (2024), in uno studio presentato ad ACL 2024, hanno mostrato che “anche la più piccola delle perturbazioni, come aggiungere uno spazio alla fine di un prompt, può far cambiare risposta all’LLM”. Mizrahi e colleghi (2024), su Transactions of the ACL, hanno dimostrato che valutare un modello con un singolo prompt “porta a instabilità nei risultati” e propongono valutazioni multi-prompt.

Se persino uno spazio può spostare una risposta, cambiare il motore e dare per scontato il risultato mi sembra un atto di fiducia un po’ impegnativo.

I modelli nuovi seguono le istruzioni alla lettera: vantaggio o rischio?

È un vantaggio quando le istruzioni sono chiare. Diventa un rischio quando il prompt porta i segni di mesi di correzioni: un divieto aggiunto qui, un’eccezione là, due indicazioni che non vanno più d’accordo. Il modello precedente poteva interpretare l’intenzione; quello nuovo può eseguire con maggiore letteralità anche la contraddizione.

Nesi sceglie ancora l’immagine del collega: “Il vecchio modello era un collega esperto, che intuiva cosa stavi chiedendo. Il nuovo è un collega che segue alla lettera. È più affidabile il secondo, ma devi dare istruzioni giuste. Dopo mesi di aggiustamenti a mano […] le contraddizioni erano… lì. Il nuovo modello le ha solo messe in evidenza” (Nesi, 2026).

OpenAI, all’uscita di GPT-5, ha pubblicato una guida al prompting datata 7 agosto 2025 (Kotha, Lee, Zakariasson & Kavanaugh, 2025). Cinque giorni dopo, sul forum ufficiale per sviluppatori, ha scritto: “GPT-5 è il nostro modello più orientabile finora, e il prompting differisce dagli altri modelli. Non limitarti a sostituirlo senza adattare i prompt!” (OpenAI Developer Community, 12 agosto 2025) [VERIFY: la guida GPT-5 dichiara esplicitamente che istruzioni contraddittorie degradano le prestazioni — fonte: OpenAI Cookbook, GPT-5 prompting guide, sezione instruction following].

Qui l’armadio diventa una metafora piuttosto precisa. Puoi mettere al nuovo collega l’abito del precedente. Magari gli va anche bene sulle spalle. Poi prova a lavorare e scopri che le maniche intralciano proprio il gesto che gli hai chiesto di fare.

Quando ho costruito Bussola in una notte, buona parte delle istruzioni che ho scritto erano “divieti”: non fare questo, evita quello. Rileggendole oggi con un modello più letterale, molte mi sembrano zavorra. Alcune ricordano il caso degli elefanti di Nesi: scrivi “una conversazione non è un interrogatorio” e hai comunque messo “interrogatorio” nelle istruzioni che il modello legge.

Quanto tempo hai davvero prima di dover cambiare modello?

Meno di quanto suggerisca la durata nominale del modello. Dal ciclo di vita devi sottrarre il tempo necessario per valutare un sostituto, adattare l’agente e collaudarlo. Il ciclo standard è di 18 mesi, o 12 per alcuni fornitori; in Copilot Studio la finestra sul modello ritirato dopo l’aggiornamento automatico è di 30 giorni. Quel margine non sostituisce la preparazione.

I dati della documentazione Microsoft, messi uno accanto all’altro, rendono visibile il calendario:

Elemento	Valore	Fonte
Ciclo di vita standard di un modello GA su Foundry	18 mesi	Microsoft Learn, lifecycle policy
Ciclo di vita modelli Anthropic, DeepSeek, Fireworks, Mistral AI	12 mesi	Microsoft Learn, lifecycle policy
Stadi del ciclo di vita	Preview → GA → Legacy → Deprecated → Retired	Microsoft Learn, lifecycle policy
Risposta di un modello ritirato	HTTP 410 Gone	Microsoft Learn, lifecycle policy
Finestra sul modello ritirato dopo upgrade automatico in Copilot Studio	30 giorni	Microsoft Learn, aggiornato 03/08/2026

C’è una distinzione che porterei in ogni conversazione sull’assistenza: chi decide quando avviene il cambio? Microsoft avverte: “Un agente che usa il modello predefinito passa a un nuovo modello ogni volta che il predefinito viene aggiornato, che tu l’abbia pianificato o no. Per gli agenti ad alto rischio e ad alto volume, seleziona un modello specifico anziché seguire il predefinito, così ogni cambio di modello passa dal tuo processo di migrazione” (Microsoft Learn, s.d.).

Lasciare il modello predefinito significa accettare che la data del cambio d’abito non la scegli tu.

Come si gestisce il ciclo di vita di un agente Copilot Studio?

Con un ciclo ripetibile, non con una corsa ai ripari quando arriva l’avviso di ritiro. Microsoft lo articola in sette passi: scoprire i cambiamenti, censire gli agenti coinvolti, valutare i sostituti, approvare, distribuire, monitorare e ricominciare.

La sequenza della guida Manage the AI model lifecycle for Copilot Studio agents (Microsoft Learn, s.d.) è questa:

1. Discover: individuare modelli nuovi, aggiornati, predefiniti e in ritiro.
2. Inventory: censire agenti, ambienti, proprietari e processi di business che dipendono da ciascun modello.
3. Evaluate: valutare i modelli sostitutivi contro una baseline stabilita.
4. Approve: approvare la migrazione con criteri di qualità e operativi documentati.
5. Deploy: rilasciare attraverso il processo di Application Lifecycle Management dell’organizzazione.
6. Monitor: osservare i risultati in produzione e aggiungere gli scenari nuovi alla suite di regressione.
7. Repeat: ripetere man mano che modelli e requisiti evolvono.

La baseline è il riferimento con cui confrontare il comportamento dell’agente prima e dopo il cambio. La suite di regressione è l’insieme dei test che permette di vedere se qualcosa che funzionava ha smesso di funzionare. Senza quel confronto, resta soprattutto un’impressione: proprio quella che arriva quando qualcuno dice che l’agente è cambiato, ma non sa indicare dove.

Microsoft riassume l’equilibrio così: “progettare per la flessibilità, operare con prudenza e sottoporre ogni upgrade a valutazione. Aggiornare a ogni nuovo modello rischia regressioni silenziose. Evitare ogni cambio di modello garantisce un’emergenza quando arriva un ritiro”. La guida raccomanda anche di registrare, per ogni agente, proprietario di business, proprietario tecnico, tester, approvatore del rilascio, modello configurato, posizione del set di test di regressione e data dell’ultima baseline.

Quando ho guardato da vicino ASSERT, il framework Microsoft per collaudare gli agenti, il punto era già questo: i test non servono solo prima del rilascio. Servono anche quando il collega torna con un abito nuovo e vuoi capire se riesce ancora a fare il suo lavoro.

“Less is more”: perché la manutenzione di un prompt è spesso una sottrazione?

Perché alcune istruzioni erano rimedi ai difetti del vecchio modello. Se il difetto non c’è più, il rimedio può diventare un ostacolo. Un modello più capace non ha necessariamente bisogno di più regole: ha bisogno che obiettivi e contesto non siano sepolti sotto correzioni ormai inutili.

Nesi, nel suo settimo punto, lo dice così: “quasi ogni correzione fatta bene è in realtà una sottrazione. Via le ‘cerimonie’, via i ‘divieti’, le regole scritte contro i vizi del modello precedente. Ogni istruzione in più è un’altra occasione di contraddizione, e un modello più capace ha bisogno di obiettivi e contesto, non di binari” (Nesi, 2026).

La sottrazione, però, non riguarda soltanto il testo del prompt. I suoi altri esempi obbligano a guardare l’agente intero:

• Agire o parlare: l’agente sceglie fra chiamare strumenti e rispondere. Se un flusso lasciava al modello il compito di decidere l’ordine, può richiedere una struttura più rigida.
• Risposta e interfaccia: il modello può produrre una tabella, ma l’interfaccia che riceve la risposta sa mostrarla?
• Tono: “usa un tono professionale” non basta a ottenere un risultato stabile; servono esempi concreti del tono desiderato.

Nella mia esperienza è la manutenzione più difficile da raccontare. “ho aggiunto una funzione” suona come lavoro. “ho tolto trenta righe e ora funziona meglio” suona quasi come una confessione. Eppure rimettere ordine nell’armadio è parte del cambio d’abito.

Cosa cambia, in pratica, per le PMI italiane?

Per una PMI che ha commissionato un agente a un partner, l’assistenza continuativa va considerata nel preventivo. Il modello cambia secondo un calendario esterno e ogni passaggio richiede il lavoro di una migrazione. I dati suggeriscono una finestra misurata in mesi, non in anni.

In un contratto o in un piano interno, partirei dagli elementi indicati da Microsoft e dall’esperienza raccontata da Nesi:

• Inventario: sapere quali agenti usano quale modello, chi ne è proprietario e se seguono il modello predefinito o uno fissato.
• Baseline di test: conservare conversazioni reali e risposte attese per confrontare il comportamento a ogni cambio.
• Revisione dei prompt: rileggere le istruzioni riga per riga, chiedendosi, con Nesi, “questa istruzione contro quale comportamento l’avevo scritta?”.
• Notifiche: seguire il Message Center di Microsoft 365 e le notifiche del Power Platform admin center, le fonti che Microsoft cita per gli annunci di ritiro.
• Budget ricorrente: prevedere il lavoro anche dopo la consegna.

Il rischio hype, qui, prende una forma poco spettacolare. Non è soltanto immaginare che l’agente possa fare troppo. È immaginare che, una volta consegnato, possa restare uguale a sé stesso. Come ho scritto nell’Agente Boss, quando il team include le macchine, anche le macchine hanno bisogno di un percorso di crescita. L’AI attraversa processi e competenze: non è un prodotto da comprare, collocare in un reparto e dimenticare.

FAQ

Un agente AI ha bisogno di manutenzione dopo il rilascio?

Sì. Il fornitore aggiorna e ritira il modello linguistico su cui l’agente si basa. Su Microsoft Foundry il ciclo standard è di 18 mesi, o 12 per alcuni fornitori esterni. Un cambio di modello può modificare prompt, flussi e tono senza produrre errori visibili: per questo servono test di regressione e revisione periodica.

Cosa succede se il modello del mio agente Copilot Studio viene ritirato?

L’agente passa a un modello sostitutivo. Dopo l’aggiornamento automatico, Copilot Studio permette di continuare a usare il modello ritirato per 30 giorni attivando Continue using retired models nelle impostazioni dell’agente. È una finestra per completare test e adattamenti, non una soluzione permanente.

Perché un prompt che funzionava non funziona con il nuovo modello?

Perché le istruzioni possono essere state scritte attorno alle abitudini del modello precedente. Un modello più recente può seguirle più letteralmente e rendere evidenti contraddizioni che prima venivano coperte dall’interpretazione. Microsoft e OpenAI indicano di rivedere i prompt al cambio di modello; una baseline di test permette di confrontare i comportamenti.

Quanto costa mantenere un agente nel tempo?

Dipende da volumi e criticità, e non ho dati generali attendibili da citare. La documentazione Microsoft rende però esplicito il lavoro ricorrente: inventario, valutazione contro una baseline, approvazione, rilascio tramite ALM — il processo di gestione dei rilasci — e monitoraggio. Sono attività da ripetere a ogni cambio di modello, quindi il costo va previsto come ricorrente, non una tantum.

Conclusioni

Torno alla sala riunioni e alla domanda iniziale. Capisco perché un agente consegnato a giugno sembri una voce da chiudere. Se fosse un tornio, il ragionamento filerebbe. Ma il suo motore ha un calendario di aggiornamenti e ritiri; le istruzioni che oggi lo fanno lavorare bene potrebbero non produrre lo stesso risultato con il prossimo modello.

Microsoft scrive che la scelta del modello “non è una decisione di design una tantum”. I cicli di vita indicati sono di 12-18 mesi. E Nesi, dopo la migrazione di una soluzione con decine di migliaia di utenti, mostra quanto lavoro possa nascondersi dietro “cambiare una variabile”: una revisione riga per riga.

La mia posizione non cambia: consegnare un agente senza un piano di manutenzione significa consegnare una fotografia, non un collaboratore. Nesi si chiede se fra un anno diremo le stesse cose dei modelli che oggi sono “nuovi”. Io penso di sì. Perciò terrei pronto non soltanto l’abito successivo, ma anche il tempo per capire se, una volta indossato, il collega riesce ancora a lavorare.

Riferimenti

Fonti verificate al 30 settembre 2026.

Livello A – Scientifico

• Mizrahi, M., Kaplan, G., Malkin, D., Dror, R., Shahaf, D., & Stanovsky, G. (2024, 1 agosto). State of what art? A call for multi-prompt LLM evaluation. Transactions of the Association for Computational Linguistics, 12. https://doi.org/10.1162/tacl_a_00681
• Salinas, A., & Morstatter, F. (2024, agosto). The butterfly effect of altering prompts: How small changes and jailbreaks affect large language model performance. In Findings of the Association for Computational Linguistics: ACL 2024 (pp. 4629–4651). https://doi.org/10.18653/v1/2024.findings-acl.275

Livello B – Primario autorevole

• Kotha, A., Lee, J., Zakariasson, E., & Kavanaugh, E. (2025, 7 agosto). GPT-5 prompting guide. OpenAI Cookbook. https://developers.openai.com/cookbook/examples/gpt-5/gpt-5_prompting_guide
• McGrath, A., & Downie, A. (2026, 23 giugno). What is agent lifecycle management? IBM Think. https://www.ibm.com/think/topics/agent-lifecycle-management
• Microsoft Learn. (s.d.). Manage the AI model lifecycle for Copilot Studio agents. https://learn.microsoft.com/microsoft-copilot-studio/guidance/plan-agent-model-lifecycle
• Microsoft Learn. (2026, 3 agosto). Continue using a retired AI model – Microsoft Copilot Studio. https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-retired-model
• Microsoft Learn. (s.d.). Microsoft Foundry Models lifecycle and support policy. https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirements
• Microsoft Tech Community. (2026, 31 agosto). Model migration process on Microsoft Foundry and Azure OpenAI. https://365community.online/model-migration-process-on-microsoft-foundry-and-azure-openai [VERIFY: URL originale del post su techcommunity.microsoft.com — fonte: Microsoft Tech Community]
• OpenAI Developer Community. (2025, 12 agosto). Prompting GPT-5 is different. https://community.openai.com/t/prompting-gpt-5-is-different/1344710

Fonte d’ispirazione (post professionale)

• Nesi, L. (2026, 29 settembre). Come (non) “rompere” un intero prodotto cambiando una sola variabile [Post]. LinkedIn. https://www.linkedin.com/in/leandro-nesi-899575153/ [verificare URL del post specifico]

Livello C – Argos New Dreams

• Borio, L. (2026, 6 giugno). Gli agenti AI non si lanciano, si collaudano: ho guardato da vicino ASSERT di Microsoft. https://argosnewdreams.blog/2026/06/06/gli-agenti-ai-non-si-lanciano-si-collaudano-ho-guardato-da-vicino-assert-di-microsoft/
• Borio, L. (2026, 9 giugno). L’Agente Boss: quando il tuo team include le macchine. https://argosnewdreams.blog/2026/06/09/lagente-boss-quando-il-tuo-team-include-le-macchine/
• Borio, L. (2026, 2 luglio). Skill vs system prompt: perché non è solo ‘un prompt salvato’. https://argosnewdreams.blog/2026/07/02/skill-vs-system-prompt-perche-non-e-solo-un-prompt-salvato/
• Borio, L. (2026, 15 luglio). Microsoft Copilot Studio: come ho costruito “Bussola” in una notte, tra birre e un’amicizia. https://argosnewdreams.blog/2026/07/15/microsoft-copilot-studio-come-ho-costruito-bussola-in-una-notte-tra-birre-e-unamicizia/

Trasparenza sull’uso dell’intelligenza artificiale
Questo articolo è stato redatto con l’assistenza di sistemi di intelligenza artificiale generativa: Claude Sonnet 5 per la ricerca delle fonti, la strutturazione e la prima stesura, e GPT-5.5 Chat per la revisione stilistica e la resa narrativa, entrambi tramite agenti su Microsoft Copilot Studio. Nessuno dei due sistemi ha verificato in autonomia i fatti riportati. Il testo è stato successivamente verificato, corretto e approvato da un autore umano, Luca Borio, che ne detiene la responsabilità editoriale ai sensi dell’art. 50 del Regolamento (UE) 2024/1689. Dati, citazioni e link sono stati controllati sulle fonti originali indicate. Eventuali errori residui sono miei.