Agentic Experience e Composable Architecture: progettare dati e API per un web dove l’80% del traffico non è umano

Per anni abbiamo ottimizzato siti e piattaforme pensando a una traiettoria lineare: l’utente visita, naviga, confronta, decide. In un mondo agentico, una quota crescente del percorso viene delegata. Le persone non “navigano” sempre direttamente, ma conversano con un sistema che esplora fonti e opzioni, sintetizza, seleziona e, in alcuni casi, compie azioni concrete.

Questo cambio di prospettiva ha due implicazioni immediate.

La prima è che la tua interfaccia non è solo la UI, motivo per cui diventa fondamentale anche il modo in cui esponi dati e funzionalità a sistemi automatici: API, schemi, regole di accesso, qualità dei metadati.

La seconda è che non basta “esserci” online o in piattaforma. Devi essere comprensibile per chi decide e opera al posto dell’utente, perché una parte delle scelte verrà mediata da agenti che privilegiano ciò che è leggibile, affidabile e interoperabile.

Quando l’interazione diventa conversazionale e mediata da agenti, emerge un’esigenza di design “doppia”: una parte riguarda l’utente che ancora interagisce direttamente; l’altra riguarda l’agente che agisce al suo posto.

Da un lato quindi c’è la UI (Human Experience), che resta importante, ma tende a diventare più essenziale. Deve essere chiara, fluida, orientata all’obiettivo, capace di accompagnare l’utente nelle decisioni e nelle eccezioni.

Dall’altro lato cresce l’importanza della AX (Agent Experience), ovvero lo strato che permette a un agente di capire cosa può fare, con quali limiti, con quali dati, e con quale affidabilità. Qui non conta l’estetica: contano struttura, semantica, contratti e stabilità.

In concreto, l’AX si gioca su alcuni elementi chiave:

• API pulite e versionate, con contratti chiari e comportamenti prevedibili.
• Dati strutturati e coerenti nel tempo (stessa entità, stessa rappresentazione).
• Metadati e tassonomie che rendono i contenuti interpretabili, senza ambiguità.
• Osservabilità: sapere cosa è stato chiamato, quando, con quale esito e con quale costo.

Se progetti solo la UI, rischi di ottimizzare una parte dell’esperienza e di perdere rilevanza in quella che cresce.

La SEO nasce per aiutare i motori di ricerca a capire contenuti e pagine. La GEO (Generative Engine Optimization) sposta il baricentro, poichè in questo caso non si tratta solo di essere indicizzati, ma anche di rendere le informazioni utilizzabili da motori generativi e agenti.

La GEO è quindi un requisito architetturale, perché riguarda come i dati sono esposti, descritti e governati.

• Se i dati non sono esposti in modo semanticamente leggibile, un agente non li userà.
• Se non esiste un accesso affidabile e governato, un agente non potrà agire.
• Se la semantica è ambigua o incoerente, l’agente commetterà errori o, più spesso, sceglierà alternative più semplici da interpretare.

Il rischio, a quel punto, è l’invisibilità digitale: non sparisci dalla rete, ma diventi irrilevante per chi media le scelte.

Quando diciamo “data governance”, spesso pensiamo a compliance, accessi e qualità, ma in un contesto agentico serve una governance che faccia anche un’altra cosa: rendere i dati parlabili, ovvero costruire le condizioni perché un agente possa interpretare correttamente il contesto e usare i dati senza generare ambiguità o comportamenti inattesi. In pratica, una governance orientata agli agenti comprende:

• un glossario e una tassonomia condivisa (nomi, entità, relazioni);
• coerenza tra sistemi (stesso concetto, stessa rappresentazione);
• metadati utili al ragionamento (fonte, aggiornamento, affidabilità);
• policy di accesso e responsabilità (chi può leggere, scrivere, autorizzare);
• audit e tracciabilità (cosa è stato usato per prendere una decisione).

Con più agenti e più strumenti, il rischio più comune è tornare all’accumulo, questa volta sulle integrazioni: connettori ad hoc, bridge improvvisati, dipendenze fragili. È lo stesso film, solo con attori nuovi.

Qui entra in gioco il Model Context Protocol (MCP), descritto come un modo per standardizzare l’accesso degli agenti a dati e strumenti, ridurre l’attrito e impedire che ogni nuova integrazione diventi un progetto a sé.

La standardizzazione vale proprio perché ogni integrazione fatta bene una volta non va rifatta quando arriva lo strumento successivo.

C’è un tema che molti sottovalutano: il modello economico cambia. Molta AI si paga a consumo, quindi token, chiamate e runtime hanno un costo diretto, e in un sistema di agenti che operano in autonomia la spesa può diventare volatile molto in fretta, perché un loop o un comportamento anomalo può consumare budget prima che qualcuno se ne accorga.

Per questo la governance non è solo una questione di qualità e compliance, ma anche e soprattutto di controllo operativo e finanziario. Alcuni guardrail diventano fondamentali:

• budget cap e soglie di consumo per use case e per agenti;
• rate limiting e controlli sulle chiamate;
• kill switch come freno d’emergenza;
• audit log per ricostruire decisioni e azioni;
• human-in-the-loop nei punti critici (autorizzazioni, spese, cambi di stato).

Ed è proprio qui che possono entrare in gioco le FinOps.

L’automazione non elimina lavoro: lo sposta. Quando gli agenti agiscono su processi reali, servono nuove responsabilità e questo introduce un tipo di debito meno visibile del debito tecnico: lo skill debt, cioè la distanza tra ciò che la tecnologia abilita e ciò che l’organizzazione sa governare.

Tre ruoli aiutano a chiarire la catena del valore:

• Originator: definisce obiettivi, policy e criteri di successo. I nuovi ruoli: skill debt e responsabilità
• Orchestrator: costruisce i workflow, collega sistemi, governa l’integrazione.
• Evaluator: misura, verifica, monitora, corregge (qualità, sicurezza, costo).

Gestire questo skill debt è parte della soluzione poichè senza competenze e responsabilità, la tecnologia resta fragile e non scala.

Se l’interazione si sposta verso gli agenti, la domanda diventa molto concreta: i tuoi dati e le tue capability sono leggibili, interoperabili e governabili?

La GEO traduce questa trasformazione in scelte operative: progettare API, semantica e guardrail in modo che gli agenti possano lavorare con te, dentro processi reali e con costi sotto controllo.

In pratica, la differenza tra una demo e un sistema in produzione si misura su tre criteri: dati con semantica stabile, workflow end‑to‑end, governance su rischio e spesa. l’AI smette di essere un esperimento e diventa una capacità ripetibile. Quando uno di questi elementi manca, l’AI funziona in condizioni ideali ma si inceppa nell’uso reale.