La WordPress Abilities API è un registro standardizzato con cui WordPress, plugin e temi possono dichiarare funzioni utilizzabili da altri componenti software. Una Ability non è soltanto una funzione PHP con un nome: descrive cosa fa, quali dati accetta, cosa restituisce e chi può eseguirla.
È questa struttura a renderla interessante per automazioni, integrazioni e AI Agent. Un client non deve conoscere in anticipo l’implementazione interna di ogni plugin: può scoprire una capacità, leggerne il contratto e decidere se e come invocarla.
L’API è entrata nel Core con WordPress 6.9. WordPress 7.1, la cui release finale è programmata per il 19 agosto 2026, non la reinventa: ne rende più maturi discovery, esposizione verso client esterni, validazione e ciclo di esecuzione. Se vuoi il quadro della release nel suo complesso, nell’analisi su WordPress 7.1 e AI Agent abbiamo separato ciò che entra davvero nel Core dalle funzioni rimaste nel plugin AI.
Qui facciamo un passo diverso: vediamo come funziona realmente l’Abilities API, come registrare una Ability e dove si colloca rispetto a REST API e Model Context Protocol.
Cos’è la WordPress Abilities API e quale problema risolve
La documentazione ufficiale dell’Abilities API la definisce come un modo standardizzato per registrare e scoprire unità distinte di funzionalità all’interno di un sito WordPress.
Il problema che risolve è soprattutto di interoperabilità.
Prima di avere un registro comune, ogni plugin poteva esporre le proprie funzioni attraverso metodi differenti: funzioni PHP, hook proprietari, endpoint REST personalizzati, comandi CLI o integrazioni costruite ad hoc. Questo modello continua a essere valido quando serve, ma diventa poco efficiente se molti consumer devono capire automaticamente che cosa è disponibile.
Con le Abilities, WordPress introduce un contratto condiviso:
funzione → descrizione → input → output → permessi → discovery → esecuzione
La logica interna rimane nel plugin o nel componente che registra l’Ability. L’API standardizza il modo in cui quella logica viene descritta, trovata e invocata.
Da funzioni isolate a capacità standardizzate e individuabili
Immagina un plugin WooCommerce che possiede già una funzione per restituire un riepilogo delle vendite mensili.
Senza una Ability, un’integrazione esterna deve sapere dove si trova quella funzione o quale endpoint proprietario chiamare. Se un secondo plugin implementa una funzione simile con un’interfaccia differente, l’integrazione deve conoscere anche quella.
Registrando invece una Ability come:
mio-plugin/get-monthly-sales
il plugin può dichiarare in modo strutturato:
- una label comprensibile;
- una descrizione del risultato;
- la categoria;
- lo schema degli argomenti;
- lo schema della risposta;
- la callback che esegue il lavoro;
- la regola che decide se l’utente corrente può eseguirla.
Il consumer può quindi ragionare sul contratto, non sull’implementazione.
Ability, categoria e registry: il modello mentale da capire
Tre oggetti sono centrali.
Ability è la singola capacità registrata. Utilizza un identificatore namespaced nel formato namespace/nome-ability, per esempio creativemotions/get-site-summary.
Category organizza Ability correlate. Ogni Ability appartiene a una categoria registrata.
Registry è il registro centrale in cui WordPress conserva le Ability disponibili. Da PHP puoi recuperare una singola Ability con wp_get_ability() oppure l’insieme delle Ability registrate con wp_get_abilities().
Questo significa che il sistema non deve scandagliare plugin, classi o endpoint per capire quali capacità esistono: interroga un registro comune.
Abilities API non significa necessariamente intelligenza artificiale
L’associazione con gli AI Agent è naturale, ma può creare un equivoco.
Le Abilities non sono una API esclusivamente AI. Possono essere utilizzate da un altro plugin, da codice PHP, da un client REST, da strumenti di automazione o da altri consumer.
L’AI diventa interessante perché i modelli e gli agenti beneficiano molto di funzioni accompagnate da descrizioni e schemi machine-readable. Un sistema che deve scegliere autonomamente uno strumento ha bisogno di sapere non soltanto che la funzione esiste, ma anche quando usarla e quali argomenti produrre.
Il vantaggio architetturale, però, resta più ampio: descrivere capacità software in modo coerente.
Come funziona una Ability in WordPress
Una Ability può essere vista come una funzione racchiusa dentro un contratto.
La funzione continua a fare il lavoro reale. Il contratto aggiunge ciò che serve agli altri componenti per usarla in modo prevedibile.
Nome, descrizione, input e output schema
Quando registri una Ability con wp_register_ability(), i campi essenziali comprendono label, description e categoria. Quando esistono dati in ingresso o in uscita, gli schema descrivono la forma attesa.
Per esempio, una Ability che recupera un prodotto potrebbe accettare:
product_id: integer
e restituire un oggetto con:
name, price, stock_status
Lo schema serve a due scopi diversi ma collegati.
Il primo è documentare il contratto. Un consumer può capire quali dati inviare.
Il secondo è validare il dato. WordPress può rifiutare un input incompatibile prima di arrivare alla business logic oppure rilevare un output che non rispetta il contratto dichiarato.
Per un’integrazione agentica questa distinzione conta molto: un modello può proporre argomenti, ma l’applicazione non dovrebbe assumere che siano corretti solo perché sono sintatticamente plausibili.
execute_callback e permission_callback
execute_callback contiene o richiama la logica che deve essere eseguita.
permission_callback, invece, decide se l’utente corrente è autorizzato a farlo.
Sono due responsabilità differenti.
Supponiamo che l’Ability aggiorni un’opzione del sito. Il fatto che il client sappia che l’Ability esiste non implica che chiunque possa eseguirla. La permission callback può verificare una capability WordPress, per esempio manage_options, e negare l’operazione quando il contesto non è autorizzato.
Questa separazione diventa ancora più importante con agenti e automazioni: discovery e autorizzazione non sono la stessa cosa.
Registrazione con wp_register_ability() e wp_abilities_api_init
La reference PHP ufficiale indica wp_register_ability() come il metodo principale per registrare una Ability e raccomanda di farlo sull’action wp_abilities_api_init, quando l’infrastruttura è stata inizializzata.
Le categorie hanno un lifecycle dedicato e vanno registrate prima delle Ability che le utilizzano.
Un’implementazione minima, quindi, segue questa sequenza:
- registra la categoria;
- registra l’Ability;
- definisce la callback;
- definisce i permessi;
- recupera o espone la capacità soltanto nel contesto necessario.
Non è molto codice. La parte che richiede più attenzione è progettare bene il confine della capacità.
Una Ability troppo generica, come execute-anything, è semplice da registrare ma difficile da governare. Una Ability più specifica rende più chiari input, output, autorizzazioni, audit e conseguenze dell’esecuzione.
Come WordPress valida input e output prima e dopo l’esecuzione
Quando chiami WP_Ability::execute(), WordPress non passa semplicemente gli argomenti alla callback.
Il ciclo comprende normalizzazione dell’input, validazione, controllo dei permessi, esecuzione e validazione dell’output. Con WordPress 7.1 questo lifecycle diventa ancora più estendibile attraverso nuovi filtri che possono intervenire in punti precisi della pipeline.
Il vantaggio è importante: la callback può concentrarsi sulla business logic, mentre il contratto e il lifecycle riducono la quantità di comportamento implicito che ogni integrazione deve reinventare.
Esempio pratico: creare una Ability read-only
Vediamo un esempio volutamente semplice: una Ability che restituisce nome e URL del sito.
Non serve un’AI per usarla. L’obiettivo è capire il pattern.
Registrare una categoria
add_action( 'wp_abilities_api_categories_init', function () {
wp_register_ability_category(
'creativemotions-site',
array(
'label' => __( 'Creativemotions Site', 'creativemotions' ),
'description' => __( 'Read-only abilities related to site information.', 'creativemotions' ),
)
);
} );
La categoria deve esistere prima della registrazione dell’Ability che la usa.
Registrare l’Ability
Questo esempio usa show_in_rest => true, disponibile nelle versioni attuali dell’Abilities API, per rendere la capacità disponibile attraverso gli endpoint REST. Nella sezione dedicata a WordPress 7.1 vedremo come cambia il concetto di esposizione con il nuovo flag public.
add_action( 'wp_abilities_api_init', function () {
wp_register_ability(
'creativemotions/get-site-summary',
array(
'label' => __( 'Get site summary', 'creativemotions' ),
'description' => __( 'Returns the site name and home URL.', 'creativemotions' ),
'category' => 'creativemotions-site',
'input_schema' => array(),
'output_schema' => array(
'type' => 'object',
'properties' => array(
'name' => array(
'type' => 'string',
),
'url' => array(
'type' => 'string',
'format' => 'uri',
),
),
'required' => array( 'name', 'url' ),
),
'execute_callback' => function () {
return array(
'name' => get_bloginfo( 'name' ),
'url' => home_url( '/' ),
);
},
'permission_callback' => function () {
return current_user_can( 'read' );
},
'meta' => array(
'show_in_rest' => true,
),
)
);
} );
Qui il contratto è intenzionalmente ristretto.
Non abbiamo creato una Ability generica per leggere qualsiasi informazione WordPress. Abbiamo dichiarato una singola operazione con output prevedibile e un controllo dei permessi facilmente comprensibile.
Recuperarla ed eseguirla da PHP
Una volta registrata, la stessa Ability può essere recuperata dal registry ed eseguita direttamente in PHP:
$ability = wp_get_ability( 'creativemotions/get-site-summary' );
if ( $ability ) {
$result = $ability->execute();
if ( ! is_wp_error( $result ) ) {
$site_name = $result['name'];
$site_url = $result['url'];
}
}
Questo dettaglio chiarisce perché Abilities API e REST API non sono sinonimi.
La Ability esiste nel registry indipendentemente dal fatto che venga consumata attraverso HTTP. REST è uno dei possibili canali.
Cosa cambia quando l’Ability modifica dati
Se la callback modifica contenuti, impostazioni, utenti o altri dati, il design richiede più attenzione.
Cambiano almeno quattro cose:
- la capability verificata dalla permission callback;
- la semantica degli input;
- l’idempotenza dell’operazione;
- la necessità di logging, conferme o ulteriori policy.
Per esempio, una Ability get-site-summary è naturalmente read-only. Una delete-user ha un profilo di rischio completamente diverso e non dovrebbe ereditare automaticamente lo stesso modello di esposizione solo perché entrambe sono tecnicamente registrabili.
Il principio utile è semplice: la granularità della Ability dovrebbe riflettere il confine di autorizzazione che vuoi realmente controllare.
Cosa cambia con WordPress 7.1
Alla data di questa guida WordPress 7.1 è ancora nel ciclo Release Candidate. Il Field Guide ufficiale di WordPress 7.1 raccoglie però le modifiche developer-facing già entrate nella fase RC.
Per l’Abilities API le novità più importanti riguardano esposizione, discovery, lifecycle e compatibilità degli schema verso client esterni.
Il nuovo flag public
Prima di WordPress 7.1, un’Ability destinata alla REST API poteva dichiarare show_in_rest => true.
Con 7.1 arriva un metadato più generale:
'meta' => array( 'public' => true, ),
La dev note sul flag public chiarisce che il suo obiettivo è dichiarare l’intenzione di rendere una Ability disponibile a client esterni, senza dover esprimere la stessa policy separatamente per ogni integrazione.
Per REST, public => true fa sì che show_in_rest risolva di default a true. Un valore esplicito di show_in_rest, però, continua ad avere precedenza.
Quindi puoi avere un’Ability generalmente pubblica ma deliberatamente esclusa da REST, oppure una Ability non pubblica in senso generale ma esposta specificamente via REST.
La distinzione fondamentale è un’altra: public governa l’esposizione, non l’autorizzazione. La permission_callback continua a decidere se l’utente corrente può eseguire la funzione.
Filtrare le Abilities con wp_get_abilities()
WordPress 7.1 rende più utile anche il registry in scenari con molte capacità.
La nuova API di filtro di wp_get_abilities() consente di recuperare subset per:
- categoria;
- namespace;
- metadati;
- callback di filtro personalizzate.
Per esempio, da WordPress 7.1 puoi cercare tutte le Ability di un namespace:
$abilities = wp_get_abilities( array( 'namespace' => 'creativemotions', ) );
oppure quelle marcate come pubbliche:
$abilities = wp_get_abilities( array( 'meta' => array( 'public' => true, ), ) );
Questo è utile sia per plugin tradizionali sia per client che devono costruire un catalogo selettivo di capacità. Recuperare ogni Ability e filtrarla manualmente diventa meno necessario.
Lifecycle: intervenire prima, durante e dopo l’esecuzione
Una delle modifiche più interessanti di WordPress 7.1 è l’estensione del ciclo di esecuzione.
La dev note sui nuovi lifecycle filter introduce quattro punti di intervento:
| Filtro | Funzione |
|---|---|
wp_pre_execute_ability | può interrompere anticipatamente l’esecuzione |
wp_ability_normalize_input | può trasformare l’input normalizzato |
wp_ability_permission_result | può applicare policy aggiuntive al risultato dei permessi |
wp_ability_execute_result | può trasformare o recuperare il risultato dell’esecuzione |
Questo apre scenari molto concreti.
Un plugin di sicurezza può introdurre una policy globale aggiuntiva senza modificare ogni Ability. Un sistema di multi-tenancy può aggiungere contesto all’input normalizzato. Un’integrazione può filtrare dati interni dal risultato prima della validazione finale.
WordPress 7.1 aggiunge inoltre wp_ability_validate_input e wp_ability_validate_output per estendere la validazione oltre ciò che viene espresso dallo schema, oltre all’action wp_ability_invoked utile per auditing e tracing.
Il lifecycle diventa quindi qualcosa di più vicino a una pipeline governabile che a una semplice callback.
JSON Schema più compatibili con i client esterni
Gli schema usati internamente da WordPress possono contenere convenzioni utili al PHP server-side ma non adatte a un validatore esterno.
WordPress 7.1 introduce wp_prepare_json_schema_for_client(). La dev note sulla preparazione degli schema spiega che Core applica automaticamente questa trasformazione agli schema dell’Abilities API esposti attraverso REST e alle dichiarazioni di funzione dell’AI Client.
Nella pratica significa che il server può continuare a usare le proprie convenzioni interne, mentre il client riceve una rappresentazione più portabile.
È un dettaglio poco appariscente, ma essenziale quando il consumer non è PHP e deve interpretare automaticamente il contratto della funzione.
Abilities API, REST API e MCP: non sono la stessa cosa
Questa è probabilmente la distinzione più importante dell’intera guida.
Le tre tecnologie possono lavorare insieme, ma risolvono problemi differenti.
| Livello | Cosa risolve |
|---|---|
| Abilities API | descrive e registra una capacità WordPress |
| REST API | fornisce un’interfaccia HTTP per comunicare con WordPress |
| MCP | standardizza come un’applicazione AI scopre e usa strumenti e contesto tramite un server compatibile |
Abilities API descrive cosa WordPress sa fare
L’Ability è il contratto della capacità.
Dichiara nome, descrizione, schema, callback e permessi. Può essere recuperata ed eseguita anche internamente da PHP.
Non richiede MCP per esistere.
REST API fornisce un canale HTTP per scoprire ed eseguire Abilities
La documentazione degli endpoint REST delle Abilities definisce il namespace wp-abilities/v1.
Sul sito, gli endpoint passano normalmente da /wp-json/wp-abilities/v1/....
Un client autenticato può, in base all’esposizione configurata:
- elencare le Ability;
- elencare le categorie;
- recuperare il contratto di una singola Ability;
- eseguire una Ability.
L’esposizione via REST non bypassa i permessi. Gli endpoint richiedono un utente autenticato e la singola esecuzione continua a essere soggetta alla permission callback.
Se ti serve ripassare il livello HTTP sottostante, la guida alle WordPress REST API copre richieste, endpoint e uso di WordPress come backend per sistemi esterni.
MCP Adapter traduce le Abilities in strumenti utilizzabili dagli agenti
MCP aggiunge un altro livello.
Il Model Context Protocol non sostituisce il registry WordPress e non sostituisce automaticamente REST. Offre un protocollo attraverso cui un’applicazione AI può scoprire e utilizzare strumenti esposti da un server compatibile.
Nel caso WordPress, un adapter può prendere le Ability registrate e rappresentarle nel formato richiesto dal client MCP.
Per il flusso specifico su WordPress puoi leggere la guida a WordPress MCP e AI Agent. Se invece vuoi capire il protocollo indipendentemente da WordPress, nella guida agli MCP Server analizziamo host, client, server, tools e transport.
Perché MCP non sostituisce la REST API
È facile immaginare una catena del tipo:
AI Agent → MCP → WordPress
ma quella rappresentazione nasconde ciò che avviene sotto.
L’MCP Server o Adapter può utilizzare REST, PHP, API proprietarie o altre interfacce per eseguire il lavoro reale. MCP standardizza il rapporto con il client; non impone che il sistema sottostante smetta di avere le proprie API.
La relazione utile da ricordare è:
Ability = capacità
REST = possibile canale HTTP
MCP = possibile protocollo di interoperabilità per client AI
Non sono tre alternative mutualmente esclusive.
Come un AI Agent può utilizzare una WordPress Ability
Un agente non dovrebbe ricevere accesso indiscriminato al backend e “provare a capire” quali pulsanti cliccare.
Con un’interfaccia strutturata il percorso può essere molto più controllabile.
1. Discovery della capacità
Il client recupera le Ability disponibili attraverso il consumer che sta utilizzando: REST, MCP Adapter o un altro livello compatibile.
Non è necessario esporre ogni funzione registrata. Il catalogo può essere filtrato in base a policy, namespace, categoria o metadati.
2. Interpretazione dello schema
L’applicazione fornisce al modello le descrizioni e gli schema delle capacità che considera pertinenti.
Supponiamo che esista:
shop/get-order
con un input:
order_id: integer
Il modello può associare la richiesta “controlla l’ordine 4821” a quello strumento e produrre argomenti strutturati.
3. Richiesta di esecuzione
Il modello propone la tool call, ma è l’applicazione che deve orchestrare l’esecuzione.
Questo passaggio è importante: dire che “l’LLM chiama WordPress” è una semplificazione. Normalmente il modello produce una richiesta strutturata e l’host decide come inoltrarla al sistema appropriato.
4. Controllo dei permessi
Prima della callback, WordPress verifica i permessi dell’Ability.
Con WordPress 7.1 ulteriori policy possono intervenire anche attraverso wp_ability_permission_result.
Se l’utente associato alla richiesta non possiede la capability necessaria, l’operazione deve fallire anche se il modello ha scelto correttamente lo strumento.
5. Risultato restituito all’agente
Il risultato viene validato rispetto all’output schema e ritorna al consumer.
A quel punto l’applicazione può reinserirlo nel contesto del modello per produrre una risposta, decidere il prossimo tool o richiedere un’approvazione umana.
Il punto non è rendere il modello “onnipotente”. È ridurre quante decisioni critiche devono essere affidate all’improvvisazione.
Sicurezza: rendere una Ability individuabile non significa autorizzarla
Quando si parla di AI Agent la discussione tende a concentrarsi sulla capacità del modello. Per WordPress, il problema più importante è invece quali azioni il sistema consente realmente di eseguire.
permission_callback come confine di autorizzazione
Ogni Ability dovrebbe controllare i permessi coerentemente con ciò che fa.
Un’operazione di sola lettura su informazioni non sensibili può richiedere una capability relativamente comune. Un’operazione che cambia configurazioni, utenti o contenuti richiede un confine più forte.
Non utilizzare __return_true per comodità quando la funzione può avere conseguenze sul sito.
Ability pubblica, utente autenticato e privilegi reali
Il nuovo flag public di WordPress 7.1 non significa “anonimo”.
Indica che l’Ability è destinata all’esposizione verso client esterni. Per gli endpoint REST continua a essere richiesto un utente autenticato e l’esecuzione resta vincolata ai permessi della singola Ability.
Sono quindi almeno tre livelli distinti:
discoverable → authenticated → authorised
Confonderli è uno dei modi più semplici per progettare male un’integrazione.
Read-only e operazioni mutative
Una buona classificazione iniziale separa le Ability che leggono dati da quelle che li modificano.
Le operazioni mutative richiedono particolare attenzione a:
- capability;
- validazione;
- idempotenza;
- logging;
- retry;
- possibilità di rollback;
- approvazione umana quando l’impatto lo giustifica.
Un sistema agentico può ripetere una richiesta a causa di un timeout o di uno stato ambiguo. Se l’Ability non è progettata per gestire correttamente le ripetizioni, il problema non è “l’AI”: è il contratto dell’operazione.
Principio del minimo privilegio per agenti e automazioni
La scelta più sicura non è creare un utente amministratore dedicato all’AI.
È concedere al consumer soltanto le capacità necessarie al workflow reale.
Se un agente deve leggere statistiche e preparare una bozza, non c’è motivo di dargli la possibilità di installare plugin, cancellare utenti o cambiare impostazioni critiche.
Le Abilities diventano utili proprio quando aiutano a rendere questi confini espliciti.
Quando usare Abilities API e quando una normale API è sufficiente
Non ogni funzione di un plugin deve diventare una Ability.
Aggiungere un altro livello ha senso quando produce interoperabilità reale.
Plugin che vogliono esporre funzioni a più consumer
È uno dei casi più forti.
Se una stessa operazione deve poter essere usata da codice PHP, automazioni, REST, MCP o futuri consumer, registrarla come Ability riduce la necessità di descrivere la stessa funzione con contratti separati.
Automazioni e interoperabilità tra plugin
Un plugin può cercare Ability registrate da un altro componente senza dipendere direttamente dalle sue classi interne.
Questo può rendere alcune integrazioni meno fragili, a condizione che il contratto dell’Ability rimanga stabile e sufficientemente specifico.
AI Agent e tool calling
Qui il vantaggio è evidente: nomi, descrizioni e schema forniscono il materiale necessario per costruire tool declaration comprensibili da un sistema agentico.
Ma non basta “esporre tutto all’AI”.
La qualità delle descrizioni, la granularità dei tool, i permessi e il numero di capacità rese disponibili influenzano quanto sia controllabile il workflow.
Casi in cui aggiungere una Ability sarebbe solo complessità inutile
Se una funzione è puramente interna, viene chiamata da un solo punto del plugin e non ha bisogno di discovery o interoperabilità, trasformarla in Ability può non aggiungere valore.
Lo stesso vale quando esiste già un endpoint ben progettato e nessun consumer ha bisogno del registry o del contratto Abilities.
L’API non sostituisce ogni pattern WordPress esistente. Aggiunge una primitiva quando serve un catalogo di capacità dichiarate e invocabili.
Cosa significa Abilities API per il futuro di WordPress
Il cambiamento interessante non è che WordPress abbia aggiunto un’altra API.
È il tipo di interfaccia che sta diventando importante.
Per molto tempo una parte consistente dell’estensibilità WordPress è stata progettata pensando a sviluppatori che conoscono in anticipo hook, funzioni, endpoint o classi da utilizzare.
I sistemi agentici introducono un consumer diverso: software che deve poter scoprire una funzione e interpretarne il contratto in modo dinamico.
WordPress come registry di capacità, non soltanto come CMS
Questo non trasforma WordPress in un “sistema operativo per AI” e non rende automaticamente agentico un sito.
Rende però possibile descrivere parti della business logic come capacità standardizzate.
È un cambiamento sottile ma importante.
Un plugin non è più obbligato a essere soltanto un insieme di schermate e funzioni interne. Può diventare anche un provider di operazioni dichiarate che altri componenti sanno individuare.
Perché MCP è solo uno dei possibili consumer
L’interesse attuale per MCP rischia di far sembrare l’Abilities API un componente costruito specificamente per quel protocollo.
Non è così.
MCP Adapter è un consumer molto interessante perché collega WordPress all’ecosistema degli agenti. Ma la stessa Ability può essere utilizzata da PHP, REST, CLI o altri strumenti.
Progettare una Ability soltanto intorno alle esigenze contingenti di un singolo protocollo ridurrebbe proprio l’interoperabilità che l’API cerca di creare.
Cosa osservare dopo WordPress 7.1
Dopo la release del 19 agosto, i segnali più interessanti saranno nell’ecosistema.
Bisognerà osservare:
- quali plugin inizieranno a registrare Ability realmente utili;
- come verrà adottato il flag
public; - quali pattern emergeranno per le operazioni mutative;
- come MCP Adapter e altri consumer useranno metadata e schema;
- quali convenzioni diventeranno abbastanza stabili da ridurre integrazioni proprietarie.
Il successo dell’Abilities API non si misurerà dal numero di funzioni registrate.
Si misurerà da quanto bene permetterà a componenti diversi di capire e utilizzare le stesse capacità senza sacrificare controllo, permessi e prevedibilità.
WordPress ha già il registry. WordPress 7.1 lo rende più adatto a essere consumato da sistemi esterni. Il passaggio successivo sarà vedere se plugin, automazioni e agenti riusciranno a costruire sopra questo contratto senza trasformarlo nell’ennesimo livello di complessità.