WordPress 7.1 arriverà ufficialmente il 19 agosto 2026, ma la novità più interessante per l’intelligenza artificiale non è un chatbot nella dashboard, né un pulsante per generare automaticamente articoli.
Il cambiamento importante sta più in profondità.
Con WordPress 7.1 continua a maturare l’infrastruttura che consente a plugin, automazioni e sistemi esterni di scoprire cosa WordPress può fare, capire quali dati accetta, verificare i permessi ed eseguire una funzione attraverso un’interfaccia strutturata.
La protagonista di questo processo è l’Abilities API, introdotta nel Core con WordPress 6.9 e ulteriormente sviluppata in 7.1. Accanto ad essa c’è l’AI Client, entrato nel Core con WordPress 7.0, mentre strumenti separati come l’MCP Adapter permettono di esporre le Abilities anche a client e agenti compatibili con il Model Context Protocol.
C’è però un dettaglio importante, perché durante lo sviluppo di WordPress 7.1 alcune funzionalità sono state raccontate come se fossero già destinate alla release finale.
Non è andata esattamente così.
Le nuove ability core/read-settings, core/read-content e core/read-users erano candidate per WordPress 7.1, ma non sono entrate nel Core della RC1. Oggi stanno maturando nel plugin AI ufficiale di WordPress. Anche embeddings e streaming hanno seguito un percorso più prudente rispetto ai piani iniziali.
Il risultato è forse meno spettacolare da raccontare, ma tecnicamente più interessante: WordPress non sta aggiungendo in fretta funzioni AI visibili. Sta costruendo le fondamenta perché l’intero ecosistema possa svilupparle in modo interoperabile e controllabile.
WordPress 7.1 non aggiunge un chatbot: sta costruendo l’infrastruttura per gli agenti AI
Per capire cosa cambia con WordPress 7.1 bisogna distinguere due direzioni dell’intelligenza artificiale che spesso vengono messe nello stesso calderone.
La prima è quella che conosciamo già: WordPress utilizza un modello AI per generare un testo, un’immagine, un riassunto o un’altra risposta.
La seconda ribalta il rapporto: è un sistema esterno a voler utilizzare WordPress.
Un agente potrebbe, per esempio, avere bisogno di conoscere le informazioni del sito, recuperare determinati contenuti oppure invocare una funzione registrata da un plugin. In futuro, con ability sufficientemente mature e opportunamente autorizzate, lo stesso modello può estendersi anche alle azioni che modificano il sito.
È questa seconda direzione a rendere l’Abilities API particolarmente interessante.
Dall’Abilities API di WordPress 6.9 all’AI Client di WordPress 7.0
L’Abilities API è entrata nel Core con WordPress 6.9 come registro standardizzato di funzionalità.
Un plugin può registrare una determinata operazione specificando non soltanto il codice che deve essere eseguito, ma anche nome, descrizione, dati di input, struttura dell’output e controllo dei permessi.
WordPress 7.0 ha poi aggiunto un altro tassello: l’AI Client.
Secondo la documentazione ufficiale dell’AI Client di WordPress 7.0, si tratta di una API PHP indipendente dal provider attraverso cui plugin e temi possono richiedere operazioni a modelli AI utilizzando un’interfaccia comune. WordPress non include direttamente OpenAI, Anthropic, Google o le relative credenziali: i provider vengono configurati separatamente.
Questa distinzione è essenziale:
AI Client: WordPress chiama un sistema AI.
Abilities API: WordPress descrive funzioni che altri componenti possono scoprire e invocare.
Le due infrastrutture possono collaborare, ma non sono la stessa cosa.
Cos’è davvero una WordPress Ability e perché interessa agli agenti
Pensare a una Ability semplicemente come a una “funzione PHP con un nome” è riduttivo.
Il valore sta nel contratto che la circonda.
Un’applicazione tradizionale può conoscere in anticipo una funzione perché il programmatore ha scritto appositamente il codice necessario per chiamarla. Un agente, invece, deve poter ottenere informazioni sufficientemente strutturate per capire quale strumento scegliere, quali parametri fornire e quale risultato aspettarsi.
Un’Ability permette di descrivere proprio questo.
Il modello mentale utile è:
funzione WordPress → descrizione → schema di input/output → permessi → discovery → invocazione
Supponiamo che un plugin registri un’ability per recuperare le statistiche di un prodotto WooCommerce. Un client non dovrebbe essere costretto a conoscere l’implementazione PHP interna del plugin. Può invece scoprire l’Ability, leggere la sua descrizione, capire che richiede l’ID di un prodotto, verificare il formato del risultato e invocarla attraverso uno dei livelli di integrazione disponibili.
La differenza rispetto a un agente che “clicca” dentro wp-admin è notevole.
Nel secondo caso l’automazione cerca di imitare una persona davanti all’interfaccia. Nel primo interagisce con una capacità software esplicitamente dichiarata.
È una base molto più solida per sistemi agentici.
Il vero cambiamento di WordPress 7.1 è una Abilities API molto più matura
Se ci fermassimo a cercare nuove funzioni AI spettacolari nella dashboard, WordPress 7.1 sembrerebbe quasi deludente.
Guardando le API, cambia prospettiva.
Il Field Guide ufficiale di WordPress 7.1 mette l’Abilities API tra le aree di sviluppo rilevanti della release. Le modifiche interessano discovery, schemi, validazione e soprattutto il controllo del ciclo di esecuzione.
Sono modifiche poco visibili per chi pubblica un articolo, ma molto significative per chi deve costruire software sopra WordPress.
Discovery e flag public: capire quali capacità sono disponibili
Perché un agente possa usare una Ability, prima deve poter sapere che esiste.
WordPress 7.1 introduce una gestione più coerente dell’esposizione pubblica delle ability. Le ability del Core possono dichiarare il nuovo metadato public e i client autenticati possono scoprirle attraverso l’endpoint REST dell’Abilities API.
Attenzione al significato di “public”: non vuol dire necessariamente accessibile senza autenticazione o senza controllo dei permessi.
Indica la possibilità di esporre l’Ability ai meccanismi di discovery previsti. Quando arriva il momento dell’esecuzione continuano a entrare in gioco autenticazione, permission_callback, capabilities dell’utente e gli ulteriori controlli introdotti dalla piattaforma.
La discovery risponde quindi alla domanda:
“Questa funzione deve poter essere vista dai client?”
I permessi rispondono invece a:
“Questo specifico chiamante può eseguirla?”
Separare i due livelli è fondamentale quando il consumatore non è più necessariamente un utente che naviga nella dashboard.
JSON Schema: input e output diventano comprensibili ai client esterni
Le WordPress Abilities utilizzano JSON Schema per descrivere input e output.
Non è soltanto un esercizio di documentazione.
Se un’Ability dichiara che accetta un identificativo numerico, un determinato insieme di valori o una struttura composta da campi precisi, un client può conoscere queste regole prima di effettuare la chiamata.
WordPress 7.1 rende gli schemi delle ability del Core più coerenti e aggiunge metadata più ricchi. La documentazione ufficiale specifica che queste informazioni sono utili a REST, MCP, WebMCP, AI e altri client programmatici.
Qui sta uno dei passaggi più importanti verso sistemi agentici affidabili.
Un agente non deve soltanto sapere che esiste un tool chiamato “recupera informazioni utente”. Deve capire che cosa può chiedergli e quale forma avrà la risposta.
Schema e descrizione diventano quindi parte dell’interfaccia uomo/macchina tanto quanto lo sono i pulsanti di wp-admin per l’interfaccia umana.
Il ciclo di esecuzione ora può essere controllato prima, durante e dopo una Ability
WordPress 7.1 aggiunge quattro filtri che intervengono in momenti differenti dell’esecuzione:
| Filtro | A cosa serve |
|---|---|
wp_pre_execute_ability | può interrompere l’esecuzione prima del resto della pipeline |
wp_ability_normalize_input | può modificare o arricchire l’input prima della validazione |
wp_ability_permission_result | può applicare ulteriori regole di autorizzazione |
wp_ability_execute_result | può trasformare o gestire il risultato prima della validazione dell’output |
La dev note ufficiale sui lifecycle filter cita fra i possibili utilizzi rate limiting, approval workflow, caching, autorizzazioni aggiuntive e trasformazione dei risultati.
Questo significa che l’esecuzione non è una scatola nera del tipo:
agente chiede → WordPress esegue
Può diventare:
richiesta → policy → normalizzazione → validazione → permessi → esecuzione → controllo risultato → validazione output
Ed è una differenza sostanziale quando la chiamata arriva da un’automazione che potrebbe operare molte volte e senza un essere umano che conferma ogni singolo clic.
Permessi e auditing: il pezzo fondamentale quando a chiamare WordPress è un agente AI
Parlare di agenti AI senza parlare di autorizzazioni crea un’immagine incompleta del problema.
Un agente più capace non è automaticamente un agente a cui conviene dare più accesso.
Anzi: aumentando la capacità di automatizzare operazioni, aumenta anche l’importanza di delimitare esattamente quali operazioni sono consentite, a chi e in quali condizioni.
Un agente non ottiene automaticamente i privilegi di amministratore
Le Ability registrate in WordPress possono avere una permission_callback. Inoltre continuano a valere il sistema di ruoli e capabilities di WordPress e le ulteriori policy implementate dai plugin.
Con WordPress 7.1, il filtro wp_ability_permission_result permette anche di modificare il risultato del controllo di autorizzazione.
Immagina un’Ability perfettamente legittima per sincronizzare un catalogo.
Un plugin potrebbe permetterne normalmente l’esecuzione a un amministratore, ma aggiungere un secondo livello che impedisce all’integrazione automatica di avviarla durante una finestra di manutenzione o oltre una certa frequenza.
La capacità tecnica esiste; la policy decide quando utilizzarla.
Questo principio diventerà sempre più importante man mano che WordPress passerà da ability prevalentemente informative a operazioni che possono produrre modifiche reali.
wp_ability_invoked: sapere che cosa un agente ha tentato di eseguire
WordPress 7.1 introduce anche l’action wp_ability_invoked.
Viene eseguita all’inizio di WP_Ability::execute(), quindi prima di normalizzazione dell’input, validazione, controllo dei permessi ed eventuale interruzione anticipata.
Di conseguenza può intercettare anche una chiamata che verrà successivamente rifiutata.
La documentazione delle modifiche all’Abilities API la indica come adatta ad auditing, telemetry, tracing e contabilizzazione delle invocazioni.
È una distinzione molto utile.
Se un agente prova a chiamare cento volte un’Ability senza avere i permessi necessari, sapere soltanto quali operazioni sono state completate non basta. Può essere importante conoscere anche quali invocazioni sono state tentate e rifiutate.
La stessa documentazione avverte però di non registrare indiscriminatamente l’input grezzo: potrebbe contenere credenziali, dati personali o altre informazioni sensibili.
Rendere WordPress agent-ready non significa rendere tutto accessibile agli agenti
Questo è probabilmente il principio da ricordare più di tutti.
Una buona architettura agentica non consiste nel collegare un modello AI all’amministratore WordPress e concedergli tutto.
Consiste nel trasformare le operazioni realmente necessarie in capacità scopribili, delimitate, validate, autorizzate e osservabili.
Più l’interfaccia è strutturata, meno l’agente deve improvvisare.
Più i privilegi sono granulari, minore è il danno potenziale di una richiesta sbagliata, di un prompt ambiguo o di un comportamento inatteso.
WordPress 7.1 non risolve da solo il problema della sicurezza degli agenti. Ma l’evoluzione dell’Abilities API va nella direzione giusta: rendere il controllo parte del contratto tecnico, non un’aggiunta successiva.
core/read-settings, core/read-content e core/read-users: dove sono davvero
Qui serve una precisazione perché diverse anticipazioni su WordPress 7.1 rischiano di essere lette oggi come elenco delle funzionalità effettivamente incluse.
Il 2 luglio è stata pubblicata una merge proposal per espandere le Core Abilities con tre nuove ability read-only:
core/read-settings
core/read-content
core/read-users
L’obiettivo dichiarato era costruire una baseline con cui agenti e workflow potessero comprendere configurazione, contenuti e utenti di un sito.
Queste tre ability, però, non fanno parte del Core di WordPress 7.1 RC1.
Erano candidate per WordPress 7.1 Core
La proposta era concreta, non una semplice idea di roadmap.
Il problema era la maturità dell’interfaccia.
Durante la discussione sono emersi dubbi sul naming, sulla forma degli schemi, sul rapporto con le ability già introdotte in WordPress 6.9 e soprattutto sul costo futuro della backward compatibility una volta stabilizzata l’API nel Core.
Un’Ability inserita nel Core non è un esperimento che può cambiare liberamente il mese successivo.
Plugin e servizi possono iniziare a dipendere dal suo nome, dai suoi parametri e dalla struttura del risultato. Modificare tutto in seguito diventa molto più difficile.
Per questo i contributor hanno preferito sfruttare prima il plugin AI come area di maturazione. La release leadership ha infine indicato esplicitamente di rinviare l’integrazione nel Core e continuare l’iterazione verso WordPress 7.2.
Perché oggi sono nel plugin AI ufficiale e non nel Core 7.1
Il plugin AI permette al team di provare queste interfacce su installazioni reali senza assumere immediatamente tutti i vincoli di compatibilità del Core.
È esattamente ciò che è successo.
AI 1.2.0 include core/read-content e core/read-users, che si affiancano alla precedente core/read-settings.
La release note ufficiale di AI 1.2.0 le definisce una reference implementation per l’accesso permission-aware ai dati WordPress.
Non significa che siano esperimenti irrilevanti.
Al contrario: sono un’anticipazione molto concreta del modo in cui WordPress potrebbe fornire in futuro una superficie standard per far leggere il sito a sistemi esterni, ma la loro posizione attuale va raccontata correttamente.
Plugin AI ufficiale: sì.
WordPress 7.1 Core: no.
Cosa possono già leggere e quali controlli applicano
core/read-content permette di recuperare un singolo contenuto oppure collezioni di post, filtrando per elementi come stato, autore, parent o ID. La risposta predefinita è intenzionalmente compatta, mentre campi più pesanti o contenuto raw richiedono un’esplicita richiesta.
core/read-users può recuperare singoli utenti o collezioni filtrate. Anche qui i campi sensibili non vengono restituiti automaticamente e rimangono protetti dai permessi WordPress.
core/read-settings completa il primo gruppo fornendo accesso strutturato alle impostazioni previste.
Qui si vede bene la differenza tra “dare a un’AI accesso al database” e costruire un’Ability.
L’agente non riceve necessariamente tutto ciò che esiste. Riceve ciò che l’Ability espone, nelle condizioni previste e compatibilmente con i privilegi del chiamante.
Come potrebbe lavorare un AI Agent con un sito WordPress
Arrivati a questo punto possiamo collegare i pezzi.
Un agente non ha bisogno che WordPress diventi esso stesso un LLM. Ha bisogno di un modo affidabile per comprendere le funzioni disponibili e invocare quelle necessarie.
Il flusso concettuale è:
utente → agente → protocollo/adapter → Ability → validazione e permessi → WordPress → risultato
Questo è anche il punto in cui entra il Model Context Protocol.
Dal prompt alla Ability: cosa succede realmente
Supponiamo di chiedere a un agente:
“Trova gli articoli pubblicati negli ultimi mesi che parlano di WordPress e indicami quali andrebbero aggiornati.”
Per svolgere seriamente il compito l’agente deve prima ottenere i contenuti.
In un’architettura basata sulle Abilities, può scoprire una funzione appropriata, leggere lo schema, invocarla con i parametri richiesti e ricevere un risultato strutturato.
Successivamente può analizzare i contenuti utilizzando il proprio modello AI.
Notare la separazione:
WordPress recupera i dati attraverso una funzione controllata.
Il modello interpreta quei dati.
Sono due responsabilità differenti.
Con le attuali core/read-* del plugin AI, alcuni pezzi di questo scenario stanno già prendendo forma. Per operazioni di modifica, pubblicazione o amministrazione servirebbero invece ability specifiche con controlli adeguati.
Un esempio: chiedere a un agente di analizzare i contenuti del sito
Immagina un sito editoriale con migliaia di articoli.
Un agente potrebbe recuperare una selezione di contenuti, identificare pagine simili, confrontare date e argomenti e proporre una lista di aggiornamenti.
Ma non necessariamente dovrebbe avere anche il diritto di modificare o pubblicare quegli articoli.
Qui l’architettura a capacità separate diventa preziosa.
Puoi concepire un workflow in cui l’agente:
recupera i dati;
elabora una proposta;
restituisce il risultato;
attende un’approvazione umana;
soltanto dopo, se esiste un’Ability autorizzata per la modifica, esegue l’azione.
L’obiettivo non è eliminare l’intervento umano in ogni situazione. È poter scegliere dove serve e dove invece un’operazione può essere automatizzata in sicurezza.
MCP non è l’Abilities API: sono due livelli diversi
Il Model Context Protocol e l’Abilities API vengono spesso associati perché lavorano bene insieme, ma non vanno confusi.
L’Abilities API definisce le capacità disponibili in WordPress.
MCP definisce un protocollo attraverso cui applicazioni e agenti possono scoprire e utilizzare strumenti, risorse e prompt esposti da un server compatibile.
Il progetto WordPress mantiene un MCP Adapter ufficiale che fa da ponte: prende le WordPress Abilities e le rende accessibili nel formato previsto dal Model Context Protocol.
Per dirla in modo semplice:
Ability = cosa WordPress sa fare.
MCP Adapter = uno dei modi con cui un agente può raggiungere quella capacità.
Questa separazione è intenzionale. L’Ability non dovrebbe essere progettata esclusivamente per MCP: può essere utilizzata attraverso REST, WP-CLI, altri client o futuri transport layer.
Se vuoi capire la parte protocollare prima di entrare nell’implementazione WordPress, trovi un approfondimento dedicato su MCP Server e Model Context Protocol.
Streaming ed embeddings: cosa non è arrivato in WordPress 7.1
Anche qui il calendario di sviluppo è importante.
A giugno, la roadmap dell’AI Client per WordPress 7.1 indicava streaming ed embeddings fra le aree principali su cui il team voleva lavorare. Alcuni contenuti pubblicati in quel periodo li hanno quindi presentati come novità attese della release.
Durante luglio il quadro è cambiato.
Gli embeddings erano nel piano, ma l’integrazione WordPress è slittata
Un embedding rappresenta un contenuto attraverso valori numerici che permettono di confrontarne la vicinanza semantica.
Il punto utile non è la definizione matematica, ma cosa rende possibile.
Una ricerca tradizionale può dipendere molto dalla corrispondenza delle parole. Con gli embeddings, contenuti che utilizzano termini differenti possono risultare vicini perché esprimono concetti simili.
In un sito WordPress questo potrebbe permettere sistemi del tipo:
contenuto → embedding → confronto semantico → recupero dei contenuti pertinenti → elaborazione AI
È la base di molti sistemi RAG e di ricerca semantica.
Tuttavia, la sintesi ufficiale del team AI del 15 luglio conferma che l’integrazione WordPress per la generazione degli embeddings non ha superato il cutoff di Beta 1 ed è stata indirizzata a WordPress 7.2, mentre le API sottostanti erano già presenti nel PHP AI Client 1.4.0.
Nel Field Guide di RC1 gli embeddings non compaiono tra le funzionalità di WordPress 7.1.
Quindi, alla data di questa analisi, è scorretto presentarli come una feature WordPress 7.1 disponibile nel Core.
Anche lo streaming resta fuori dal quadro di WordPress 7.1 RC1
Lo streaming serve a ricevere una risposta generativa progressivamente invece di attendere che sia completata interamente.
Per una chat questo produce il comportamento che conosciamo: il testo compare mentre il modello lo genera.
Sembra semplice lato interfaccia, ma in WordPress coinvolge HTTP transport, infrastruttura server, timeout e librerie sottostanti.
Il piano iniziale prevedeva di partire dal PHP AI Client proprio perché il sistema HTTP di WordPress non supportava naturalmente quel modello. A metà luglio, però, lo streaming risultava ancora in revisione e non era entrato nel PHP AI Client 1.4.0.
Anche qui la lezione è utile: roadmap non significa feature rilasciata.
Per un articolo su una tecnologia che cambia a questa velocità, distinguere le due cose vale più di una lista lunga di “novità”.
Cosa cambia davvero per chi sviluppa o gestisce siti WordPress
Dopo tutta questa infrastruttura viene spontanea una domanda: cosa cambia il 19 agosto per un normale sito?
Probabilmente meno di quanto suggerirebbe un titolo sensazionalistico.
E allo stesso tempo più di quanto sembri guardando soltanto la dashboard.
Per gli sviluppatori di plugin, WordPress sta creando contratti condivisi
Prima che esistano API comuni, ogni plugin tende a inventare una propria integrazione.
Uno sviluppatore espone endpoint personalizzati, un altro crea funzioni proprietarie, un altro ancora implementa direttamente il collegamento con un provider AI.
Il rischio è un ecosistema frammentato.
Abilities API e AI Client cercano di creare primitive condivise.
Il primo definisce una forma comune per descrivere ciò che WordPress può fare.
Il secondo fornisce una forma comune per chiedere qualcosa a un modello AI.
L’MCP Adapter collega invece parte di quelle capacità al crescente ecosistema degli agenti compatibili con MCP.
La conseguenza interessante non è una singola feature di WordPress 7.1. È ridurre quante volte l’ecosistema deve reinventare lo stesso livello infrastrutturale.
Per agenzie e proprietari di siti, il cambiamento oggi è soprattutto infrastrutturale
Se aggiorni un sito da WordPress 7.0 a 7.1 non troverai improvvisamente un agente autonomo pronto a gestire il tuo business.
E non dovrebbe essere questo il criterio con cui valutare la release.
Gli utilizzatori finali vedranno soprattutto le altre novità dell’editor e dell’amministrazione. L’impatto delle modifiche all’Abilities API sarà inizialmente indiretto.
Saranno plugin, piattaforme di automazione e integrazioni future a trasformare queste API in esperienze visibili.
È lo stesso motivo per cui una nuova REST API può essere molto importante senza avere un pulsante dedicato nella dashboard.
Il vantaggio arriverà quando plugin e servizi inizieranno a costruire sopra queste API
La vera soglia da osservare sarà l’adozione.
Un registro di Abilities diventa molto più utile quando plugin importanti iniziano a dichiarare in modo coerente le proprie capacità.
Un adapter MCP diventa più interessante quando trova funzioni realmente utili da esporre.
Un agente WordPress diventa più affidabile quando può utilizzare funzioni standard invece di affidarsi a workaround specifici per ogni plugin.
Da qui in avanti il valore dipenderà quindi meno dalla quantità di codice già presente nel Core e più da quanto rapidamente l’ecosistema costruirà sopra quelle fondamenta.
Per una panoramica degli strumenti AI già utilizzabili direttamente nel CMS, invece, resta separato il tema dei plugin WordPress basati sull’intelligenza artificiale: lì l’intento è scegliere strumenti operativi, non analizzare l’infrastruttura agentica del Core.
WordPress sta passando da CMS utilizzato dagli umani a piattaforma utilizzabile anche dagli agenti?
È la domanda più interessante che lascia WordPress 7.1.
Per oltre vent’anni abbiamo pensato a WordPress soprattutto attraverso due interfacce: quella che vedono gli utenti sul frontend e quella che utilizza chi gestisce il sito nel backend.
Naturalmente API, WP-CLI e automazioni esistono da molto tempo. Il CMS non è mai stato limitato ai clic umani.
Con gli agenti cambia però la scala del problema.
Un agente deve poter capire da solo quali capacità sono disponibili, quali parametri utilizzare e quali limiti rispettare. Non basta che un programmatore sappia leggere la documentazione di una funzione.
Per questo stanno acquisendo valore metadata, schema, discovery, permessi e descrizioni machine-readable.
Il modello tradizionale è:
persona → dashboard → azione
Il modello agentico può diventare:
agente → discovery → Ability → permission check → azione o risultato
I due percorsi non si escludono.
La dashboard resta fondamentale per persone, controllo e supervisione. Le Abilities costruiscono invece una superficie che può essere consumata dal software.
È qui che WordPress 7.1 appare meno come una “release AI” e più come un altro passo nella trasformazione di WordPress in una piattaforma agent-ready.
Non perché consegni agli agenti il controllo del sito, ma perché inizia a dare loro un linguaggio più standardizzato per interagire con esso.
WordPress 7.1 è solo un passaggio: cosa osservare dopo il 19 agosto
La release del 19 agosto non chiude questa storia.
Le tre core/read-* dovranno dimostrare di avere interfacce abbastanza mature per sostenere i vincoli del Core.
Gli embeddings devono ancora completare il percorso di integrazione con WordPress.
Lo streaming richiede un’infrastruttura HTTP adeguata.
MCP continua a evolversi separatamente attraverso il relativo adapter.
E soprattutto resta aperto il passaggio più delicato: dalla lettura all’azione.
Quando le nuove read abilities saranno abbastanza mature per il Core
La scelta di rinviare core/read-settings, core/read-content e core/read-users non significa che il progetto sia stato abbandonato.
La discussione della merge proposal mostra praticamente il contrario: esiste un consenso ampio sul fatto che WordPress dovrebbe prima o poi offrire primitive comuni per queste operazioni.
La questione è in quale forma stabilizzarle.
Se il ciclo nel plugin AI produrrà abbastanza utilizzo, feedback e convergenza sul design, WordPress 7.2 è il candidato naturale da osservare. Ma fino a quando una feature non entra effettivamente nel Core, va trattata come roadmap e non come promessa.
Manage abilities: il salto dalla lettura all’azione
La proposta iniziale prevedeva in futuro coppie di ability read-* e manage-*.
La discussione ha però mostrato che anche questo modello non è ancora deciso.
Alcuni contributor hanno proposto ability più atomiche — per esempio creare, aggiornare o eliminare — invece di una singola manage-* capace di svolgere molte operazioni.
La questione sembra nominale, ma non lo è.
Un agente lavora meglio quando gli strumenti hanno scopi chiari. Allo stesso tempo l’Abilities API non deve essere progettata soltanto intorno ai limiti attuali degli LLM: deve rimanere una API funzionale utilizzabile anche da REST, CLI e altri consumer.
È uno dei trade-off più interessanti che il progetto dovrà risolvere.
Embeddings, streaming, MCP e AI Plugin: i tasselli da seguire verso WordPress 7.2
Il quadro complessivo comincia quindi ad assumere una forma riconoscibile.
Abilities API: descrive ciò che WordPress può fare.
AI Client: permette a WordPress di utilizzare modelli AI attraverso un’API comune.
MCP Adapter: rende le Abilities disponibili a client compatibili con Model Context Protocol.
AI plugin: è il laboratorio in cui possono maturare feature e ability prima di diventare abbastanza stabili per il Core.
Embeddings: potrebbero aggiungere una base comune per ricerca e retrieval semantico.
Streaming: servirà a rendere più naturali le interazioni AI che richiedono una risposta progressiva.
Nessuno di questi pezzi, preso singolarmente, trasforma WordPress in un agente.
Messi insieme, però, costruiscono qualcosa che fino a poche release fa non esisteva: un livello infrastrutturale comune per far comunicare WordPress, modelli AI e sistemi agentici senza costringere ogni sviluppatore a ricominciare da zero.
WordPress 7.1 non è “la release AI”, ed è proprio questo il punto
WordPress 7.1 non porta nel Core tutte le funzioni AI anticipate durante lo sviluppo.
Le nuove core/read-* rimangono per ora nel plugin AI. Gli embeddings non sono diventati una feature di WordPress 7.1. Lo streaming non è ancora l’esperienza nativa che alcuni potrebbero immaginare leggendo la roadmap di giugno.
Eppure la release conta.
L’Abilities API diventa più controllabile, più osservabile e più utilizzabile da client esterni. Validazione, lifecycle, discovery e permessi stanno formando un contratto tecnico più maturo.
Questo è il pezzo che può durare più della singola funzione del momento.
WordPress non sembra intenzionato a legare il Core a un chatbot, a un singolo modello o a un singolo protocollo. Sta costruendo primitive che plugin e servizi potranno usare per creare esperienze AI differenti.
Per chi sviluppa oggi è un’infrastruttura da iniziare a studiare.
Per chi gestisce siti è soprattutto un segnale di direzione.
E per chi immagina agenti capaci di lavorare realmente con WordPress, il passaggio decisivo non sarà quando un’AI saprà generare un altro paragrafo dentro Gutenberg.
Sarà quando potrà capire cosa il sito le consente di fare, scegliere la funzione corretta, rispettarne i permessi ed eseguirla attraverso un’interfaccia affidabile.
WordPress 7.1 ci porta un po’ più vicino a quel punto.