Il protocollo conta più del framework: cosa cambia con AG-UI in .NET

Nel software agentico stiamo ripetendo un errore molto vecchio: confondere il framework con l’architettura. Finché l’agente vive dentro una demo, tutto sembra semplice. Il backend produce token, il frontend li mostra e qualche evento speciale gestisce tool, stato o approvazioni. Poi l’applicazione cresce, cambiamo framework, aggiungiamo un secondo client o proviamo a collegare un agente scritto in un altro linguaggio. A quel punto scopriamo che l’interfaccia utente era accoppiata non all’agente, ma alla sua implementazione.

Il nuovo SDK .NET first-class di AG-UI annunciato dal team .NET di Microsoft è interessante per questo motivo. Non perché aggiunga l’ennesima libreria AI a NuGet, ma perché sposta il confine: il contratto tra agente e applicazione può diventare un protocollo indipendente dal framework che esegue l’agente e dalla UI che lo rappresenta.

Un agente diventa infrastruttura quando la sua interfaccia smette di dipendere dal framework che lo esegue.

Il problema non è più soltanto lo streaming del testo

Un chatbot tradizionale può essere modellato come una richiesta e una risposta. Un agente no. Può lavorare a lungo, emettere output incrementale, chiamare strumenti, interrompersi in attesa di un’approvazione, aggiornare stato condiviso, delegare attività e riprendere l’esecuzione. Ridurre tutto a una sequenza di stringhe significa perdere proprio la parte che distingue un agente da una chat.

AG-UI affronta il problema descrivendo il lifecycle attraverso eventi tipizzati. Il frontend può ricevere segnali come avvio della run, contenuto testuale, variazioni di stato, tool call e conclusione senza conoscere i dettagli interni del framework che li ha prodotti. È una separazione apparentemente piccola, ma architetturalmente importante: il client reagisce a un contratto, non a un formato proprietario inventato dal backend del momento.

È lo stesso principio che rende fragile trattare un errore come semplice testo invece che come parte dell’API. Quando un’informazione influenza il comportamento del software, lasciarla implicita in una stringa è quasi sempre un debito che prima o poi presenta il conto.

Perché l’SDK .NET cambia davvero il confine

Microsoft e CopilotKit hanno portato l’implementazione C# nel repository AG-UI, accanto agli SDK TypeScript e Python, e i pacchetti sono pubblicati su NuGet con licenza MIT. La distribuzione non è un monolite: il team descrive cinque package principali, da AGUI.Abstractions per i tipi di protocollo fino a AGUI.Client e AGUI.Server, passando per formattazione e supporto protobuf.

La parte più interessante è l’integrazione con Microsoft.Extensions.AI. Sul server un normale IChatClient può essere trasformato in uno stream di eventi AG-UI; sul client AGUIChatClient implementa a sua volta IChatClient. Il protocollo quindi non chiede necessariamente di adottare un nuovo framework agentico: può stare tra componenti che già parlano le astrazioni .NET esistenti.

Questo dettaglio evita un equivoco frequente. AG-UI non è “la UI degli agenti” e non decide come debba apparire un’applicazione. Standardizza l’interazione. La stessa sequenza di eventi può essere rappresentata in una web app, in un terminale, su mobile o in una superficie collaborativa. Il rendering resta responsabilità del client.

Microsoft Agent Framework diventa un utilizzatore, non il proprietario del protocollo

Qui c’è il passaggio che considero più significativo. Microsoft Agent Framework aveva una propria implementazione AG-UI; ora la versione .NET dipende dai package AGUI.* pubblicati su NuGet e mantiene il livello di integrazione ASP.NET Core. Il modello di programmazione resta sostanzialmente lo stesso, mentre l’implementazione del protocollo esce dal framework.

È una scelta sana perché riduce due accoppiamenti contemporaneamente. Da una parte un backend .NET può esporre AG-UI senza essere obbligato a usare Microsoft Agent Framework. Dall’altra un frontend AG-UI non deve sapere se dall’altra parte ci sia un agente C#, Python o TypeScript. Microsoft dichiara che il formato degli eventi resta wire-compatible con gli altri SDK.

In pratica il framework torna a fare il framework: orchestration, agenti, tool, workflow e integrazioni. Il protocollo fa il protocollo. Sembra una distinzione scolastica, finché non devi sostituire uno dei due senza riscrivere il resto.

Il vero valore è la sostituibilità

Nel mercato AI di questi anni l’attenzione è quasi sempre catturata dal modello più nuovo o dal framework più recente. Ma per chi costruisce software destinato a vivere, la domanda importante è meno spettacolare: quanto costa cambiare un componente?

Se la UI interpreta direttamente gli eventi interni del framework A, sostituire A con B significa modificare anche la UI. Se un’app mobile e un’app web implementano ciascuna una traduzione diversa, il costo si moltiplica. Se invece il confine è un protocollo stabile, la sostituzione si concentra sull’adapter che produce quel protocollo.

Questo non rende magicamente intercambiabili tutti gli agenti. Le capability possono essere diverse, così come semantica dello stato, tool disponibili, autenticazione e persistenza. Un protocollo non cancella le differenze: offre un posto preciso in cui dichiararle. Ed è già molto.

Un protocollo non risolve sicurezza e identità

C’è anche un rischio: vedere la standardizzazione del trasporto e concludere che l’integrazione sia automaticamente sicura. Non lo è. La documentazione recente di Microsoft Agent Framework ricorda esplicitamente che un endpoint AG-UI pubblico deve autenticare i chiamanti e autorizzare l’accesso alle sessioni; un thread ID identifica una conversazione, non dimostra chi abbia diritto a leggerla.

È coerente con un principio che vale anche per la sicurezza degli agenti AI: le garanzie importanti devono stare nel livello che può realmente imporle. Il protocollo descrive eventi e interazioni; autenticazione, autorizzazione, isolamento e policy restano responsabilità dell’architettura che lo ospita.

L’interfaccia agentica sta diventando un livello autonomo

Tre giorni dopo l’annuncio dell’SDK, Microsoft ha presentato anche nuovi componenti sperimentali Blazor per le Agentic UI. È un segnale utile perché mostra la stratificazione: Microsoft.Extensions.AI offre astrazioni, Agent Framework gestisce agenti e workflow, AG-UI collega agente e superficie utente, Blazor può renderizzare quell’interazione. Nessuno di questi livelli deve possedere tutti gli altri.

È questa separazione, più del singolo package, che rende l’annuncio interessante. Stiamo uscendo dalla fase in cui ogni demo agentica inventa il proprio piccolo universo di callback, JSON e componenti frontend. Se il settore vuole costruire applicazioni che sopravvivano alla velocità con cui cambiano modelli e framework, i confini dovranno diventare più stabili dei componenti.

La maturità dell’AI applicativa non si misurerà da quanti framework possiamo adottare, ma da quanti possiamo sostituire senza demolire il prodotto.

La parte meno appariscente è quella che conta

Un SDK su NuGet non ha il fascino di un nuovo modello. E un protocollo di eventi è decisamente meno vendibile di una demo in cui un agente sembra fare tutto da solo. Ma l’ingegneria del software diventa interessante proprio quando smettiamo di guardare la demo e iniziamo a chiederci quali contratti resteranno in piedi tra due anni.

AG-UI non garantisce di diventare quello standard. È ancora un ecosistema in evoluzione e alcune integrazioni Microsoft sono in preview o sperimentali. Il dato concreto, però, è che oggi esiste un’implementazione .NET first-class, pubblicata indipendentemente su NuGet, compatibile a livello wire con gli altri SDK e già consumata da Microsoft Agent Framework. È abbastanza per trattarla non come una curiosità, ma come un segnale architetturale.

Per chi sviluppa agenti, la domanda utile quindi non è “quale UI devo usare?”. È: qual è il contratto tra l’agente e qualunque UI vorrò usare domani? Quando quella risposta è separata dal framework, abbiamo finalmente iniziato a progettare un sistema invece di assemblare una demo.

Domande frequenti su AG-UI in .NET