A2UI spiegato: cosa fa (e cosa non fa) il protocollo Agent-to-UI
A2UI è un protocollo JSON dichiarativo che consente agli agenti AI di descrivere le interfacce di cui un client deve eseguire il rendering. Come funziona, quali renderer esistono e cosa non fa.
Punto chiave
A2UI (Agent to UI) è un protocollo JSON aperto e dichiarativo creato da Google. Un agente AI invia una descrizione di un'interfaccia e un client la esegue con i propri componenti nativi invece di eseguire il codice dall'agente. È un modo per spostare la struttura e i dati dell'interfaccia utente oltre un confine di fiducia, non un sistema di animazione, una libreria di componenti o un renderer finito. ExodeUI non è un renderer A2UI e non è affiliato con Google.
Cos'è A2UI?
A2UI è un protocollo per interfacce guidate da agenti. Invece di restituire un muro di testo o eseguire codice generato, un agente AI invia un flusso di messaggi JSON che descrivono un'interfaccia utente: quale superficie creare, quali componenti contiene e quali dati la riempiono. Il client riceve tali messaggi ed esegue il rendering del risultato con componenti di cui già si fida. A2UI è stato creato da Google ed è concesso in licenza Apache 2.0, con il contributo di CopilotKit e della comunità open source. A partire dall'ottobre 2026, l'attuale specifica di produzione era la v0.9.1 e la v1.0 era una candidata al rilascio.
Il problema che A2UI sta cercando di risolvere
Gli agenti sono bravi a produrre una risposta utile ma pessimi a fornirla come interfaccia. Una risposta testuale non può mostrare una tabella comparativa, un modulo d'ordine o un dashboard. La generazione di HTML o JavaScript arbitrari risolve il problema di presentazione e ne crea uno di sicurezza, poiché il client ora sta eseguendo codice che non ha scritto. A2UI prende una terza strada: l'agente descrive l'interfaccia utente in un formato vincolato e il client decide come renderla. L'agente può utilizzare solo i componenti approvati dal client e l'output sono dati anziché codice eseguibile.
Come viene costruita una superficie A2UI
Il protocollo utilizza un piccolo insieme di tipi di messaggio. Lo schema esatto cambia tra le versioni, quindi controlla le specifiche prima di implementarne una, ma la forma è stabile.
- createSurface: dice al renderer di creare una nuova superficie, che è una regione dell'interfaccia che l'agente può aggiornare
- updateComponents: aggiunge o modifica le definizioni dei componenti su quella superficie
- updateDataModel: modifica i dati visualizzati dai componenti, senza inviare nuovamente la struttura
- deleteSurface: rimuove una superficie quando non è più necessaria
Renderer e trasporti
A2UI è indipendente dal trasporto. Le specifiche descrivono i messaggi, non il modo in cui viaggiano. Il progetto elenca le implementazioni del renderer per Angular, Flutter, Lit, React e Markdown e i collegamenti di trasporto per AG-UI, A2A e MCP, con WebSocket, SSE e REST utilizzabili. Il punto è questa flessibilità: la stessa risposta dell'agente può essere resa da un client Web, un'app mobile o un'applicazione desktop, ciascuno utilizzando il proprio sistema di progettazione.
Ciò che A2UI non fa
A2UI è facile da sovraleggere. Non fornisce una libreria di componenti che puoi inserire in un'app e non esegue il rendering di nulla da solo: hai bisogno di un renderer e di un catalogo di componenti controllati dal client. Non decide come si muove l'interfaccia utente. Non sostituisce MCP, che espone strumenti e dati a un modello, o AG-UI, che trasporta gli eventi di interazione tra un agente e un frontend. E non elimina la necessità di una revisione tecnica: le interfacce generate devono comunque gestire il caricamento, gli stati vuoti e di errore, le autorizzazioni e l'accessibilità.
A2UI contro AG-UI contro MCP
Questi tre sono spesso menzionati insieme perché risolvono diversi livelli dello stesso problema. Una scorciatoia utile: A2UI descrive l'interfaccia, AG-UI porta l'interazione e MCP fornisce all'agente strumenti e dati. La documentazione di A2UI descrive AG-UI come collegamento di trasporto per A2UI e A2UI può anche viaggiare su MCP. Sono standard complementari e non concorrenti. Se scegli un'integrazione, inizia da ciò che il tuo client può rendere e da quale trasporto già supporta, non dal protocollo con più slancio.
Dove si adattano animazione e interazione
A2UI descrive struttura e dati. Il movimento è una preoccupazione del cliente: il renderer decide se una superficie appare istantaneamente, si dissolve o passa da uno stato precedente. Questa è una buona notizia per i team di prodotto, perché mantiene il sistema di animazione nel client dove può rispettare il sistema di progettazione e le impostazioni di accessibilità. Significa anche che un'implementazione A2UI non viene animata automaticamente. Se un'interfaccia generata richiede la pressione di un pulsante, una transizione di stato o una reazione della mascotte, il client deve fornire tale comportamento. ExodeUI può riprodurre movimenti interattivi in un client e dispone di un server MCP per strumenti di codifica AI, ma non è un renderer A2UI e non deve essere descritto come tale.
Estratto di implementazione in produzione
// Simplified shape of an A2UI message stream (schema differs by version).
{ "createSurface": { "surfaceId": "cart" } }
{ "updateComponents": { "surfaceId": "cart", "components": [ /* ... */ ] } }
{ "updateDataModel": { "surfaceId": "cart", "data": { /* ... */ } } }
{ "deleteSurface": { "surfaceId": "cart" } }Principi chiave da ricordare
- A2UI è un protocollo JSON per interfacce descritte dall'agente, creato da Google e concesso in licenza con Apache 2.0
- Il client esegue il rendering con i propri componenti; l'agente non esegue codice UI arbitrario
- Definisce i messaggi e lascia il renderer, il trasporto e il movimento al client
- Non è un sistema di animazione o una libreria di componenti drop-in
- ExodeUI non è un renderer A2UI e non ha alcuna affiliazione con Google