Due assi da versionare, non uno

Il ciclo di vita di una soluzione costruita sul Microsoft Foundry Agents service non si descrive con il vocabolario dell’ALM di Power Platform: solution, environment e pipeline appartengono a quella piattaforma, e trasportarli qui è l’errore che l’esame punisce per primo. In Microsoft Foundry il ciclo di vita poggia su due assi indipendenti, da promuovere separatamente:

  • la agent version, cioè lo snapshot della definizione dell’agente (istruzioni, modello, tool);
  • il model deployment, cioè l’istanza di un modello di Foundry Models resa richiamabile per l’inferenza.

Un agente può cambiare senza che cambi il modello, e il modello sotto un agente può essere sostituito da Microsoft senza che nessuno tocchi la definizione dell’agente. Chi progetta l’ALM decide chi governa ciascun asse. Nota lessicale: parte della documentazione vive ancora sotto /azure/ai-foundry/ o /azure/foundry-classic/ e dice “Azure AI Foundry” o “Azure OpenAI”, ma è lo stesso prodotto rinominato.

Versioni dell’agente, pubblicazione e identità

Una agent version è immutabile: ogni modifica salvata produce una nuova versione, e nel codice si referenzia come <agent_name>:<version>. Il nome non è modificabile dopo la creazione, quindi la convenzione di naming è una decisione architetturale. Le modifiche non salvate sono draft e si perdono uscendo dal portale: senza salvataggio non hai cronologia, confronto fra versioni né evaluation complete.

La distinzione da dichiarare è fra prompt-based agent, definito in modo dichiarativo con istruzioni e tool, e Hosted agent, il tuo codice in un container su Azure Container Registry gestito dal servizio. Per gli Hosted agent la versione comprende immagine, allocazione di CPU e memoria, variabili d’ambiente e protocolli: le variabili sono fissate per versione, quindi cambiare una configurazione runtime significa creare una nuova versione, non modificare quella in esecuzione.

La pubblicazione trasforma una versione in una Agent Application, risorsa Azure con endpoint stabile, RBAC proprio e un deployment figlio che punta a una specifica agent version. Quel flusso è oggi marcato nella documentazione come esperienza di pubblicazione legacy.

Il vincolo architetturale che decide più scenari è l’identità. Un agente non pubblicato usa l’identità condivisa del project; una volta pubblicato riceve una propria agent identity in Microsoft Entra, e i permessi non si trasferiscono automaticamente: se non riassegni i ruoli RBAC alle risorse downstream, i tool che funzionavano in sviluppo falliscono in autorizzazione dopo il go-live. Sui ruoli l’esame gioca sulla rinomina: Foundry Project Manager sullo scope della risorsa serve per pubblicare, Foundry User sullo scope dell’Agent Application serve per invocare, e Foundry Agent Consumer non basta perché usa un percorso di permessi diverso.

ALM dei modelli custom e dei deployment

Sull’asse del modello il ciclo di vita è governato in parte da te, in parte da Microsoft. Ogni modello del catalogo attraversa gli stadi Preview, Generally Available, Legacy, Deprecated e Retired; a ritiro avvenuto ogni chiamata di inferenza risponde 410 Gone. La leva di controllo è la proprietà versionUpgradeOption sul deployment, con tre valori: OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired e NoAutoUpgrade — l’ultimo significa che il deployment smette di funzionare al ritiro. Da non confondere con i deployment type (Global Standard, Data Zone Standard, Standard, le varianti provisioned, batch e Developer), che decidono dove i dati sono processati e come si paga, né con il model router.

Il criterio operativo: i deployment standard vengono aggiornati automaticamente da Microsoft regione per regione, mentre i deployment provisioned non sono aggiornati automaticamente e richiedono una migrazione manuale, in-place o side-by-side. Un’assicurazione che tiene il triage sinistri su capacità riservata, con il vincolo di non processare dati fuori dall’Unione Europea, sceglie Data Zone Provisioned e si assume l’onere della migrazione: proroghe al ritiro non ne vengono concesse.

Per i modelli custom ottenuti con fine-tuning il ritiro avviene in due fasi distinte, training e deployment: quando il modello base esce dal training non puoi più addestrarlo, ma i modelli già addestrati restano deployabili fino alla seconda scadenza. Il fine-tuning va quindi pianificato come processo ricorrente, da ripetere quando i dati cambiano o quando esce un modello base aggiornato. Il deployment type Developer serve a valutare un modello fine-tuned a costo contenuto, ma ha durata fissa di 24 ore, nessuno SLA e nessuna garanzia di data residency: non è un ambiente di test permanente.

Continuità del servizio e governance

Quando una versione sostituisce la precedente, l’endpoint dell’Agent Application resta invariato e il traffico va al 100% al nuovo deployment: non esiste traffic splitting fra versioni, quindi un canary non si progetta con percentuali ma con applicazioni separate. Il rollback consiste nel ripuntare il deployment a una versione precedente, che resta disponibile proprio perché immutabile. Un identificatore di agente cancellato invece non torna: un 404 Not Found su un ID già valido è terminale, e va gestito con un pattern get-or-create, non ritentando in loop.

Il gate di promozione è l’evaluation, da non confondere con il monitoring: la prima è un test riproducibile su dataset o tracce, integrabile in CI/CD tramite cloud evaluation, il secondo osserva la produzione dopo il rilascio. Tracing ed evaluation sono in preview, come l’agent optimizer per gli Hosted agent. Sul lato governance, due policy Azure in disponibilità generale — Foundry model deployments should only use approved models e Foundry model deployments should meet eligibility requirements — negano i modelli fuori allow list o in stato Preview, con effetto Deny o Audit valutato al momento del deployment.

L’esame verifica questa separazione: se lo scenario chiede che una nuova versione dell’agente vada in produzione senza che i consumatori cambino configurazione, la risposta corretta parla di agent version e deployment dietro l’endpoint stabile, non di solution o pipeline.