A giugno 2026, Automattic ha annunciato che l'accesso MCP di WordPress.com diventa servizio a pagamento per i siti self-hosted che vogliono connettersi al loro agent stack. La notizia ha messo in moto una valanga di traffico verso progetti alternativi: in 6 settimane il repository GitHub homgorn/wp-oss-AI-agent è passato da 1.200 a 14.000 star, Angie (Uncanny Automator) ha rilasciato un connector MCP nativo, e progetti come LangGraph-WordPress e CrewAI-WP Bridge hanno visto la loro prima release production-ready.

In questa guida mettiamo insieme l'intero stack open-source self-hosted che nel 2026 permette a un'agenzia o a un'azienda di orchestrare AI agent su WordPress e WooCommerce senza dipendere da WordPress.com, senza vendor lock-in, e con costi operativi pari a un VPS da 20€/mese. Vediamo i 7 componenti, l'architettura, il codice di setup, i pattern operativi per agenzie e un caso reale di e-commerce B2B che ha migrato da WordPress.com MCP a stack self-hosted in 11 giorni, con saving annuale di 8.700€.

Non è un articolo per chi parte da zero: assumiamo che tu sappia cosa sono MCP e le Abilities API e che tu abbia già esperienza con WP-CLI. Per il quadro complessivo dell'enterprise con AI, leggi anche WordPress AI Bridge layer production-ready, che copre l'aspetto plugin.

I 7 componenti dello stack open-source

Lo stack self-hosted AI agent su WordPress nel 2026 ha sette componenti che si parlano. Non sono tutti obbligatori, ma per un setup production-ready devi averne almeno cinque.

1. WordPress Agent OS (homgorn/wp-oss-AI-agent)

È il sistema operativo di orchestrazione. Espone un gateway unico che parla MCP, OpenAPI, e REST classico. Sostituisce il gateway WordPress.com MCP managed. Il progetto è in PHP 8.2+ nativo, gira come plugin o come container Docker separato, ed è compatibile con tutti i LLM che parlano MCP (Claude, GPT, Gemini, Llama). Il fork attivo è homgorn, ma esistono almeno 4 fork attivi (compreso wp-foundation/wp-agent-os).

2. Angie (Uncanny Automator 6.4)

Uncanny Automator nella versione 6.4 (luglio 2026) include Angie, un agente nativo che gestisce workflow multi-step. Angie sa:

• Parlare con WordPress (post, taxonomies, utenti, media).
• Connettersi a 200+ servizi (Zapier-like, ma locale).
• Eseguire prompt LLM con context grounding (RAG leggero).
• Schedulare azioni ricorrenti con cron WordPress.

La differenza chiave rispetto a MCP puro: Angie mantiene state fra le chiamate, quindi può orchestrare workflow a più step senza che l'LLM debba ricordare tutto.

3. WordPress Abilities API (core 7.0)

Cuore architetturale del pattern agent. Permette di registrare abilities (= tool) che l'agente può chiamare. Il registro è persistente, versionato, e supporta capability check WP permission. Il core WP 7.0 lo include nativamente, e i plugin possono aggiungere le proprie abilities senza conflitti.

4. LangGraph-WordPress bridge

Bridge fra LangGraph (framework Python per agent stateful) e WordPress. Si installa come servizio Python separato, espone endpoint MCP, e permette di scrivere agent complessi in Python (che è più espressivo di PHP per state machine). Bridge bidirezionale: LangGraph può chiamare abilities WordPress, e WordPress può notificare LangGraph di eventi.

5. WP-RAG (Retrieval Augmented Generation)

Layer RAG leggero per dare context all'agente. Quando l'utente chiede "trova articoli che parlano di X e fanne un sommario", l'agente deve poter cercare nei contenuti, estrarre i pezzi rilevanti, e iniettarli nel prompt. WP-RAG fa esattamente questo, con backend vettoriale (Qdrant, Weaviate, pgvector). Open-source, licenza MIT.

6. Ollama / vLLM (LLM runtime locale)

Per il layer inferenza LLM, due opzioni: Ollama (più semplice, single-binary) o vLLM (più performante, richiede GPU). Per la maggior parte degli use case WordPress agent, Ollama è sufficiente. Modelli consigliati: llama-3.3-70b-instruct, qwen-2.5-coder-32b, mistral-large-2.

7. n8n (workflow orchestration)

Per trigger non-LLM (webhook, schedule, eventi WordPress), n8n self-hosted orchestra i workflow. n8n parla MCP dal 2026, quindi può chiamare abilities WordPress e ricevere notifiche. È l'OSS sostituto di Zapier.

Architettura del pattern self-hosted

Il pattern architetturale self-hosted è un layer cake con quattro livelli logici.

Layer 1: WordPress core + plugin agent

A livello WordPress hai il core 7.0 (Abilities API), il plugin Agent OS (homgorn), e Angie come orchestratore di workflow. Questo layer gestisce la registrazione dei tool, l'autenticazione, e la state machine base.

Layer 2: Gateway MCP

Un servizio che espone MCP endpoint pubblico. Può essere lo stesso Agent OS (PHP) o un container Python separato (più performante). Il gateway:

• Autentica la richiesta (token utente, API key).
• Risolve l'agent ID e verifica permessi.
• Instrada la chiamata all'ability corretta.
• Logga azione, response, durata, errori.

Layer 3: LLM + RAG

Il layer inferenza. Ollama o vLLM servono i modelli. WP-RAG indicizza i contenuti WordPress in vettori. L'agent LLM riceve prompt con context retrieval dal RAG.

Layer 4: Storage + observability

• Database: WordPress MySQL classico + Postgres per RAG (se usi pgvector) o Qdrant self-hosted.
• Cache: Redis object cache, edge cache Nginx differenziata AI bot (vedi articolo dedicato).
• Observability: Prometheus + Grafana per metriche, Loki per log, Jaeger per distributed tracing.

Setup completo in 11 giorni: il caso B2B e-commerce

Un'azienda con 3 store WooCommerce B2B (complessivi 14.000 SKU, 28.000 ordini/anno) ha migrato da WordPress.com MCP a stack self-hosted in 11 giorni. La timeline reale:

Giorni 1-2: discovery e procurement

• Identificati i 38 tool agent usati dal sito WordPress.com MCP.
• Mappati 1-a-1 con abilities WordPress Agent OS + Angie.
• 6 tool mancanti, sviluppati internamente in 2 giorni.

Giorni 3-5: setup infrastruttura

• VPS Hetzner AX102 (64 GB RAM, 16 vCPU, 2x1TB NVMe) a 35€/mese + backup 5€/mese.
• Docker Compose con 7 container: WordPress, MySQL, Redis, WordPress Agent OS, Ollama, Qdrant, n8n.
• Nginx reverse proxy con cache AI-aware differenziata.

Giorni 6-8: training modelli e RAG

• Indicizzati 14.000 SKU + 6.000 articoli blog in Qdrant.
• Custom prompt template per il dominio B2B (tono tecnico, focus specifiche, no enfasi vendita).
• Test 200 query reali, 92% soddisfazione, 8% da raffinare.

Giorni 9-10: parallel run

• Stack self-hosted e WordPress.com MCP attivi in parallelo 48 ore.
• A/B testing su 1.200 sessioni reali.
• Zero regression, 4% response time migliore sul self-hosted.

Giorno 11: cutover

• Switch DNS + wp-config: site ora usa self-hosted.
• WordPress.com MCP disattivato, costo -870€/mese.

Costi e saving

Quando il self-hosted non conviene

Da onesti: per un singolo blog o un sito vetrina sotto le 5.000 visite/mese, il self-hosted è overkill. Il break-even è a circa 6 mesi, e serve un DevOps o uno sviluppatore che mantiene il setup. Per sotto quella soglia, resta su WordPress.com MCP o su un piano managed come Pressable, che è nello stesso segmento diAutomattic ma con pricing diverso.

Codice: setup Docker Compose per stack self-hosted

Il setup minimo production-ready in Docker Compose. Puoi adattarlo al tuo caso.

File docker-compose.yml per lo stack self-hosted base.

version: '3.9'

services:
  wordpress:
    image: wordpress:7.0-php8.3
    restart: always
    ports:
      - 8080:80
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: changeme
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_DEBUG', false);
        define('WP_MEMORY_LIMIT', '512M');
        define('WP_HOME', 'https://example.com');
        define('WP_SITEURL', 'https://example.com');
        define('DISABLE_WP_CRON', true);
    volumes:
      - wp_data:/var/www/html
      - ./wordpress/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
    depends_on:
      - db
      - redis

  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp
      MYSQL_PASSWORD: changeme
      MYSQL_ROOT_PASSWORD: rootpw
    volumes:
      - db_data:/var/lib/mysql
    command: --default-authentication-plugin=mysql_native_password

  redis:
    image: redis:7.2-alpine
    restart: always
    volumes:
      - redis_data:/data

  agent-os:
    image: homgorn/wp-agent-os:latest
    restart: always
    ports:
      - 7000:7000
    environment:
      WP_API_URL: http://wordpress/wp-json/wp/v2
      WP_JWT_SECRET: changeme_random_64
      LOG_LEVEL: INFO
      MCP_TRANSPORT: streamable-http
    depends_on:
      - wordpress

  ollama:
    image: ollama/ollama:latest
    restart: always
    ports:
      - 11434:11434
    volumes:
      - ollama_data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

  qdrant:
    image: qdrant/qdrant:latest
    restart: always
    ports:
      - 6333:6333
    volumes:
      - qdrant_data:/qdrant/storage

  n8n:
    image: n8nio/n8n:latest
    restart: always
    ports:
      - 5678:5678
    environment:
      N8N_HOST: n8n.example.com
      WEBHOOK_URL: https://n8n.example.com/
      GENERIC_TIMEZONE: Europe/Rome
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  wp_data:
  db_data:
  redis_data:
  ollama_data:
  qdrant_data:
  n8n_data:

Setup WordPress Agent OS come plugin

In alternativa al container separato, Agent OS può essere installato come plugin WordPress. Più semplice, meno scalabile.

Installazione plugin tramite WP-CLI.

# installa plugin Agent OS
wp plugin install wp-agent-os --activate --allow-root

# configura abilities base
wp option update wp_agent_os_enabled 1 --allow-root
wp option update wp_agent_os_jwt_secret "$(openssl rand -hex 32)" --allow-root
wp option update wp_agent_os_mcp_transport streamable-http --allow-root

# verifica health
wp agent-os status --allow-root

# lista abilities registrate
wp ability list --allow-root

Configurazione Ollama + WP-RAG

Il setup inferenza LLM + indicizzazione vettoriale richiede un'ora circa. Ecco i passi operativi.

Script bash per setup Ollama + Qdrant + WP-RAG.

#!/bin/bash
# setup-llm-rag.sh
set -e

# 1. Pull modello LLM (richiede ~30min su GPU A100)
ollama pull llama-3.3-70b-instruct
ollama pull qwen-2.5-coder-32b  # per task tecnici

# 2. Avvia Qdrant container (vedi docker-compose)

# 3. Indicizza contenuti WordPress in Qdrant
wp wp-rag index --source=posts --source=products --batch-size=100 --allow-root

# 4. Verifica stato indicizzazione
wp wp-rag status --allow-root

# 5. Test query
wp wp-rag query "articoli su WordPress e AI agent" --top-k=5 --allow-root

Plugin Angie: installazione e primo workflow

Angie è un layer sopra Uncanny Automator. Si installa come plugin aggiuntivo.

Setup Angie con primo workflow di esempio.

# installa Uncanny Automator + Angie
wp plugin install uncanny-automator --activate --allow-root
wp plugin install angie-connector --activate --allow-root

# abilita MCP
wp option update automator_mcp_enabled 1 --allow-root

# assicurati che il connettore sia attivo
wp eval '
if ( class_exists( "Angie\\Connector" ) ) {
    \Angie\Connector::init();
    echo "Angie connector attivato\n";
}
' --allow-root

Dopo l'attivazione, configura il primo workflow dalla UI WordPress: quando un utente pubblica un commento, Angie legge il sentiment via Ollama e tagga il commento come positive/neutral/negative in modo automatico.

Pattern operativi per agenzie

Per le agenzie WordPress che vogliono offrire stack AI-agent self-hosted ai clienti, tre pattern operativi si sono affermati.

Pattern 1: managed self-hosted per cliente singolo

Un VPS per cliente, stack completo. Costo: 35-80€/mese per cliente, fatturato al cliente a 250-450€/mese. Margine: 60-70%. Tempo di setup iniziale: 1-2 giorni. Manutenzione mensile: 2-4 ore. Ideale per clienti con 3+ store WooCommerce o con necessità di compliance (no dati su cloud non-EU).

Pattern 2: shared stack multi-tenant

Un cluster Kubernetes self-hosted (K3s su bare metal) con 1 WordPress per cliente ma Agent OS + Ollama + Qdrant condivisi. Costo per cliente: 15-30€/mese. Complessità setup: 3-5 giorni. Manutenzione: 8-12 ore/mese. Ideale per agenzie con 10+ clienti che vogliono centralizzare. Richiede DevOps senior.

Pattern 3: ibrido self-hosted + managed

Stack agent self-hosted (Agent OS, RAG) ma LLM inference su Anthropic API o OpenAI API. Costo: 30-100€/mese per LLM (dipende da volume). Vantaggio: qualità LLM top-tier, no GPU da gestire. Svantaggio: dati escono dall'azienda. Per clienti enterprise con compliance leggero.

Le 4 trappole più grandi

Trappola 1: pensare che Ollama sia production-ready

Ollama è ottimo per sviluppo e per carichi bassi. In produzione con centinaia di richieste/giorno, ha memory leak noti su llama 70b. Per produzione, usa vLLM o un servizio cloud (Anthropic, OpenAI). Ollama va bene per dev/test.

Trappola 2: non backuppare il vettoriale

Il database vettoriale (Qdrant, pgvector) contiene il "knowledge" del tuo agente. Se lo perdi, l'agente riparte da zero. Backuppare quotidianamente Qdrant su S3 o Hetzner Storage Box. Costo: 2-5€/mese. Costo di non averlo: settimane di reindicizzazione.

Trappola 3: ignorare la sicurezza del gateway MCP

Il gateway MCP è esposto pubblicamente. Se non lo metti dietro autenticazione forte (token firmato, rate limit per IP, mTLS per servizi interni), diventa un vettore di attacco. Il caso B2B sopra ha subito 3 tentativi di prompt injection nei primi 30 giorni. Tutti respinti da un middleware di validazione. Mai aprire MCP senza autenticazione.

Trappola 4: non avere un fallback umano

Il 5-10% delle richieste agent fallisce (modello sbaglia, context troppo lungo, abilità mancante). Devi avere un fallback umano automatico: se l'agent score < 0.7 di confidenza, trasferisci la richiesta a un operatore umano con notifica email. Risultato: recuperi 70% della UX.

Le 5 metriche operative da monitorare

1. Agent success rate (target >85%)

% di richieste che l'agent risolve senza fallback umano. Misurato via Angie analytics o plugin custom Agent OS stats.

2. Response time P95 (target <3s)

Tempo medio del 95° percentile per la risposta. Dipende dal modello LLM: llama 70b self-hosted >2s, Claude API <1s.

3. Cost per request (target <0,05€)

Costo medio per singola richiesta agent. Include inferenza LLM + retrieval RAG + storage. Da ottimizzare se sopra 0,10€.

4. RAG retrieval precision (target >0.8)

Su 100 query di test, quante sono risposte correttamente con il primo chunk retrieved. Se sotto 0.7, migliora chunking o embeddings.

5. Agent uptime (target >99.5%)

Tempo in cui l'agent è disponibile. Dipende da Ollama uptime, Qdrant uptime, WordPress uptime. Monitoring con Prometheus + Alertmanager.

FAQ su stack AI agent WordPress self-hosted

Quali sono i vantaggi reali del self-hosted rispetto a WordPress.com MCP managed?

I vantaggi sono tre: (1) controllo totale dei dati (no dati su cloud non-EU, compliance GDPR semplificata), (2) no lock-in (se domani Automattic alza il prezzo 5x, cambi stack in 2 settimane), (3) modelli custom (puoi fine-tunare su dati tuoi, cosa che con Claude API non puoi). Svantaggi: richiede DevOps, costo setup iniziale più alto.

Ollama o vLLM per uso produzione?

Ollama per dev/test, vLLM per produzione. vLLM ha throughput 10-20x superiore e memory management migliore. Richiede GPU NVIDIA con 24+ GB VRAM (es. RTX 4090, A5000). Su CPU-only Ollama è la sola opzione realistica.

Quanto costa realisticamente il setup self-hosted?

Setup minimo: 35-50€/mese VPS + 0€ per Ollama se CPU-only. Setup medio (GPU on-demand): 150-300€/mese. Setup enterprise (cluster K8s self-hosted): 800-1500€/mese. Comparato con WordPress.com MCP a 870€/mese per 3 store, il break-even dello stack self-hosted è 6-12 mesi.

Posso usare il mio provider hosting attuale (es. SiteGround, Kinsta)?

Parzialmente. Kinsta e SiteGround non permettono di installare Ollama o container Docker custom sui loro piani managed. Le uniche opzioni sono: (1) hosting con root (Hetzner, OVH, DigitalOcean), (2) servizio agent separato (es. Anthropic API), (3) Pressable managed MCP che è un compromesso.

Quale modello LLM scegliere per uso WordPress agent?

Dipende dal use case. Per task generici (testi, analisi): llama-3.3-70b-instruct. Per task tecnici (codice, query): qwen-2.5-coder-32b. Per task vision (analisi immagini prodotto): llama-3.2-vision-90b. Per task multilinguali (italiano + inglese): mistral-large-2. Sperimenta con 3-4 modelli prima di scegliere.

Il self-hosted regge il carico di un'agenzia con 30+ clienti?

Sì, ma serve il pattern multi-tenant (Pattern 2 sopra). Un cluster K3s con 3 nodi (32 GB RAM, 8 vCPU ciascuno) regge 30+ clienti WordPress con agent. Tempo risposta medio 1.8s. Costo 250-400€/mese totali, fatturati a 30×80€/mese = 28.800€/anno lordi. Margine 80%+.

Cosa fare se smette di funzionare un componente (es. Qdrant)?

Tre cose: (1) monitoring attivo Prometheus + Alertmanager su soglie uptime <99%, (2) runbook documentato per ogni componente (Qdrant, Ollama, Agent OS, WordPress), (3) failover automatico: se Qdrant è giù, fallback a ricerca full-text MySQL (peggiore ma funziona). Il pattern circuit breaker è tuo amico.

Riferimenti utili per approfondire

• homgorn/wp-oss-AI-agent - GitHub repository - WordPress Agent OS, fork attivo con 14k+ star
• Uncanny Automator 6.4 changelog - Angie MCP - release notes Angie e connector MCP
• WordPress Abilities API 2026 reference - specifica tecnica abilities, base del pattern agent
• Ollama documentation - runtime LLM single-binary per dev/test
• vLLM production inference - runtime LLM ad alte prestazioni per produzione
• Qdrant vector database self-hosted - vector store usato da WP-RAG, open-source MIT
• LangGraph WordPress bridge - framework Python agent stateful che parla MCP
• n8n self-hosted workflow - orchestrazione workflow con MCP, alternativa OSS a Zapier
• WP Rocket best practices AI agent - caching layer utile per stack agent
• Pressable MCP managed - mrtux.it - alternativa managed allo stack self-hosted
• Plugin AI WordPress con MCP abilities - mrtux.it - pattern architetturale Plugin Team, base per il pattern self-hosted
• WordPress self-hosted LLM locale Ollama - mrtux.it - approfondimento Ollama + WP 7.0
• WordPress AI Bridge layer - mrtux.it - bridge layer production-ready lato plugin

L'agentic commerce non è più un'anteprima relegata ai keynote. A luglio 2026 un numero crescente di acquirenti non è più un umano che clicca un bottone, ma un AI agent che confronta specifiche, valuta alternative e conclude il checkout al posto dell'utente. Se il tuo WooCommerce non espone un'interfaccia che un agente può leggere e rispettare, di fatto non esiste per quella fetta di mercato. La buona notizia è che l'ecosistema 2026 offre tutti i pezzi pronti per usare questo canale in settimane, non in trimestri.

In questa guida mettiamo insieme i tre protocolli che rendono il pattern operativo — MCP (Model Context Protocol), Stripe Agent Toolkit e le API commerce standard (Product, Cart, Checkout) — con un caso reale di store WooCommerce tecnico con 1.200 SKU e 17 clienti B2B che ora riceve il 9% del fatturato da agent. Vediamo architettura, codice PHP, prompt di test, guardrail di sicurezza e le trappole che nessuno ti dice prima che lo scopri in produzione.

Non è una guida per chi parte da zero: se non hai mai toccato WP-CLI o non hai mai integrato WooCommerce con tool esterni, parti prima da quei due articoli. Qui assumiamo che tu abbia uno store WooCommerce funzionante e che tu voglia esporlo a un pubblico non umano.

Cosa cambia davvero con l'agentic commerce su WooCommerce

Quando parliamo di agentic commerce su WooCommerce intendiamo un pattern preciso: un cliente umano delega a un AI agent (ChatGPT, Claude, Perplexity, Gemini, agenti verticali di comparison shopping) il compito di acquistare un prodotto. L'agente usa un'interfaccia tecnica per esplorare il catalogo, leggere le specifiche, valutare il prezzo, e dove autorizzato, completare il checkout. WooCommerce non vede un browser: vede una sequenza di chiamate API firmate, potenzialmente con una carta virtuale single-use emessa dal wallet dell'utente.

Le 3 interfacce che un agente deve poter usare

Un WooCommerce agentic-ready deve esporre tre superfici:

1. Lettura del catalogo: API REST o GraphQL che restituisca prodotto, variante, prezzo, disponibilità, specifiche tecniche, immagini, documenti. Deve essere leggibile sia da umani che da LLM, quindi JSON pulito, niente HTML frammentato.
2. Composizione del carrello: API che permetta all'agente di sapere se un carrello è valido, totale, tasse, spedizioni, eventuali vincoli (quantità minima, paese).
3. Checkout delegato: supporto a Stripe Agent Toolkit o equivalente per tokenizzazione carta single-use, indirizzo di spedizione, conferma ordine.

Differenza fra agentic commerce e bot "acquirente"

C'è una distinzione che il 90% dei post 2026 oscura: l'agentic commerce è un consenso esplicito e tracciabile fra utente umano e agente. L'agente agisce con un mandato (cosa cercare, quanto spendere, entro quando), usa strumenti di pagamento delegati (carta virtuale, wallet limitato), e spesso deve riferire all'utente cosa ha fatto. Non è un bot che compra scalando alla cieca. Se gestisci questo come "bot blocca o lascia passare" perdi il business legittimo.

Architettura: MCP, Stripe Agent Toolkit e REST commerce

Il pattern architetturale che funziona in produzione nel 2026 ha tre gambe, ognuna con un compito preciso.

MCP come punto di contatto fra LLM e WooCommerce

Model Context Protocol è diventato nel 2026 lo standard de facto per esporre strumenti a un LLM. Un MCP server WooCommerce espone strumenti (tools) dichiarati, ognuno con descrizione testuale leggibile dal modello, un JSON schema per i parametri, e un handler che esegue la chiamata. Quando un utente chiede a Claude "trovami un caricatore USB-C da 100W sotto 30€ compatibile con il mio MacBook Pro 14" 2023", l'agente:

1. Riceve il prompt con il contesto utente.
2. Identifica che servono i tool woo_search_products e woo_get_product.
3. Chiama woo_search_products con i parametri estratti.
4. Verifica compatibilità (keyword, attributi).
5. Eventualmente compone un carrello e chiede conferma.

Per fare quello non servono centinaia di righe: WP 7.0 include già un MCP server nativo simile a quello che abbiamo già coperto per WPVibe, con un adapter PHP che permette di wrappare le REST API WooCommerce in tools.

Stripe Agent Toolkit: pagamento delegato con carta virtuale

Stripe Agent Toolkit è il componente che gestisce la parte pagamento. Espone all'agente:

• Creazione di un Payment Intent con amount, currency, metadata.
• Conferma pagamento con un token di carta virtuale (il cliente umano ha generato una carta usa-e-getta sul proprio wallet, l'agente la usa una sola volta).
• Webhook firma-verificata per evento payment_intent.succeeded.

Sul WooCommerce il flusso operativo è: l'agente chiama un endpoint REST autenticato che crea l'ordine WooCommerce in stato pending, genera il Payment Intent su Stripe, restituisce all'agente un client_secret. L'agente completa il pagamento con la carta virtuale. Sul ritorno del webhook, WooCommerce promuove l'ordine a processing.

Le parti più delicate — idempotenza, gestione doppio pagamento, scadenza carrello agente — le vediamo nel codice qui sotto.

API commerce REST WooCommerce

La terza gamba è la classica REST API WooCommerce, esposta sotto /wp-json/wc/v3/. Qui le cose da curare sono: performance (cataloghi grandi devono avere un endpoint di ricerca dedicato che non enumeri tutti i prodotti), filtri e attributi (esposti in modo che l'LLM li possa leggere), disponibilità real-time (cache invalidation se usi Redis o transient).

Codice: MCP server WooCommerce operativo in 30 minuti

Vediamo il codice PHP reale per costruire un MCP server WooCommerce che espone 4 strumenti: ricerca prodotti, dettaglio prodotto, composizione carrello, creazione ordine con Stripe Agent Toolkit. Il codice è compatibile con WP 7.0+ (richiede il package wp-ai-client 1.4+) e funziona con qualsiasi LLM che parla MCP, da Claude a Cursor a Goose.

Plugin base: registrazione abilities MCP

Crea un plugin woo-agentic-commerce con un file principale che dichiara le abilities. Il pattern è lo stesso visto nella guida alle Abilities API WordPress 6.9+, applicato però con la registrazione specifica del connector MCP.

Codice che puoi adattare al tuo store WooCommerce. Salvalo come woo-agentic-commerce.php nella cartella del plugin.

<?php
/**
 * Plugin Name: WooCommerce Agentic Commerce
 * Description: Esposizione MCP + Stripe Agent Toolkit per WooCommerce
 * Version: 1.0.0
 * Requires PHP: 8.1
 * Requires at least: 7.0
 */

if ( ! defined( 'ABSPATH' ) ) { exit; }

add_action( 'wp_abilities_register', function() {
    // 1. Ricerca prodotti
    wp_register_ability( 'woo_search_products', array(
        'label'       => 'Cerca prodotti nel catalogo WooCommerce',
        'description' => 'Cerca prodotti per keyword, categoria o attributo. Restituisce fino a 20 risultati con ID, nome, prezzo, disponibilità, SKU.',
        'input_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'query'    => array( 'type' => 'string', 'description' => 'Keyword di ricerca' ),
                'category' => array( 'type' => 'integer', 'description' => 'ID categoria WordPress' ),
                'in_stock' => array( 'type' => 'boolean', 'description' => 'Solo prodotti disponibili' ),
            ),
        ),
        'output_schema' => array(
            'type'  => 'array',
            'items' => array(
                'type'       => 'object',
                'properties' => array(
                    'id'         => array( 'type' => 'integer' ),
                    'name'       => array( 'type' => 'string' ),
                    'price'      => array( 'type' => 'string' ),
                    'in_stock'   => array( 'type' => 'boolean' ),
                    'sku'        => array( 'type' => 'string' ),
                ),
            ),
        ),
        'execute_callback' => 'woo_ac_search_products_callback',
    ) );

    // 2. Dettaglio prodotto
    wp_register_ability( 'woo_get_product', array(
        'label'       => 'Recupera dettagli prodotto WooCommerce',
        'description' => 'Restituisce tutti i metadati di un prodotto per valutazione compatibilità.',
        'input_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'product_id' => array( 'type' => 'integer' ),
            ),
            'required' => array( 'product_id' ),
        ),
        'execute_callback' => 'woo_ac_get_product_callback',
    ) );

    // 3. Composizione carrello agente
    wp_register_ability( 'woo_create_cart', array(
        'label'       => 'Crea un carrello WooCommerce per un agente',
        'description' => 'Crea un carrello con uno o più prodotti. Restituisce ID carrello, totale, spese spedizione stimate.',
        'input_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'items'       => array( 'type' => 'array', 'items' => array( 'type' => 'object' ) ),
                'agent_id'    => array( 'type' => 'string', 'description' => 'ID univoco agente LLM' ),
                'user_token'  => array( 'type' => 'string', 'description' => 'Token utente che delega' ),
            ),
            'required' => array( 'items', 'agent_id' ),
        ),
        'output_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'cart_id'            => array( 'type' => 'string' ),
                'subtotal'           => array( 'type' => 'string' ),
                'shipping_total'     => array( 'type' => 'string' ),
                'total'              => array( 'type' => 'string' ),
                'expires_at'         => array( 'type' => 'integer' ),
            ),
        ),
        'execute_callback' => 'woo_ac_create_cart_callback',
    ) );

    // 4. Checkout con Stripe Agent Toolkit
    wp_register_ability( 'woo_checkout_with_stripe', array(
        'label'       => 'Completa checkout WooCommerce con Stripe Agent Toolkit',
        'description' => 'Finalizza un ordine agente usando un payment intent Stripe. Validazione token, idempotenza, scadenza carrello.',
        'input_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'cart_id'          => array( 'type' => 'string' ),
                'stripe_token'     => array( 'type' => 'string', 'description' => 'Token carta virtuale usa-e-getta' ),
                'shipping_address' => array( 'type' => 'object' ),
                'agent_id'         => array( 'type' => 'string' ),
            ),
            'required' => array( 'cart_id', 'stripe_token', 'shipping_address' ),
        ),
        'execute_callback' => 'woo_ac_checkout_stripe_callback',
    ) );
} );

require_once __DIR__ . '/includes/callbacks.php';
require_once __DIR__ . '/includes/stripe-agent.php';
require_once __DIR__ . '/includes/security.php';

Handler woo_ac_search_products_callback

La callback che esegue la ricerca. La parte interessante è il filtro combinato che sfrutta l'indice di ricerca WooCommerce + meta query, evitando l'enumerazione che farebbe esplodere il context window di un LLM dopo poche chiamate.

Aggiungi includes/callbacks.php con la logica di ricerca ottimizzata.

<?php
function woo_ac_search_products_callback( $input ) {
    $query    = sanitize_text_field( $input['query'] ?? '' );
    $category = absint( $input['category'] ?? 0 );
    $in_stock = (bool) ( $input['in_stock'] ?? true );

    $args = array(
        'status'   => 'publish',
        'limit'    => 20,
        'orderby'  => 'relevance',
        'order'    => 'DESC',
    );

    if ( $query !== '' ) {
        $args['s'] = $query;
    }

    if ( $category > 0 ) {
        $args['category'] = array( $category );
    }

    if ( $in_stock ) {
        $args['stock_status'] = 'instock';
    }

    $products = wc_get_products( $args );

    $results = array();
    foreach ( $products as $p ) {
        $results[] = array(
            'id'         => $p->get_id(),
            'name'       => $p->get_name(),
            'price'      => $p->get_price(),
            'in_stock'   => $p->is_in_stock(),
            'sku'        => $p->get_sku(),
        );
    }

    return $results;
}

function woo_ac_get_product_callback( $input ) {
    $product_id = absint( $input['product_id'] );
    $product = wc_get_product( $product_id );
    if ( ! $product ) {
        return new WP_Error( 'woo_not_found', 'Prodotto non trovato', array( 'status' => 404 ) );
    }

    return array(
        'id'             => $product->get_id(),
        'name'           => $product->get_name(),
        'description'    => $product->get_description(),
        'price'          => $product->get_price(),
        'in_stock'       => $product->is_in_stock(),
        'sku'            => $product->get_sku(),
        'attributes'     => $product->get_attributes(),
        'weight'         => $product->get_weight(),
        'dimensions'     => array(
            'length' => $product->get_length(),
            'width'  => $product->get_width(),
            'height' => $product->get_height(),
        ),
    );
}

Integrazione Stripe Agent Toolkit: la parte delicata

Il codice di checkout con Stripe Agent Toolkit ha tre particolari che isolano il tuo store dai problemi classici dell'agentic commerce.

File includes/stripe-agent.php — gestione payment intent con idempotenza e scadenza.

<?php
function woo_ac_create_cart_callback( $input ) {
    $items     = $input['items'] ?? array();
    $agent_id  = sanitize_text_field( $input['agent_id'] );
    $user_token = sanitize_text_field( $input['user_token'] ?? '' );

    if ( empty( $items ) || empty( $agent_id ) ) {
        return new WP_Error( 'woo_bad_input', 'items e agent_id obbligatori', array( 'status' => 400 ) );
    }

    // Validazione items
    $line_items = array();
    foreach ( $items as $item ) {
        $product_id = absint( $item['product_id'] ?? 0 );
        $qty        = absint( $item['quantity'] ?? 1 );
        $product    = wc_get_product( $product_id );
        if ( ! $product || ! $product->is_in_stock() ) {
            return new WP_Error( 'woo_invalid_item', "Prodotto {$product_id} non disponibile", array( 'status' => 409 ) );
        }
        $line_items[] = array( 'product_id' => $product_id, 'quantity' => $qty );
    }

    $cart_id = wp_generate_uuid4();
    $expires_at = time() + ( 15 * MINUTE_IN_SECONDS ); // 15 minuti scadenza

    // Persiste carrello transient WooCommerce-style
    set_transient( 'woo_ac_cart_' . $cart_id, array(
        'items'      => $line_items,
        'agent_id'   => $agent_id,
        'user_token' => $user_token,
        'created_at' => time(),
    ), 15 * MINUTE_IN_SECONDS );

    // Calcola totali
    $total = 0;
    foreach ( $line_items as $li ) {
        $p = wc_get_product( $li['product_id'] );
        $total += floatval( $p->get_price() ) * $li['quantity'];
    }

    return array(
        'cart_id'        => $cart_id,
        'subtotal'       => number_format( $total, 2, '.', '' ),
        'shipping_total' => '0.00', // calcolato in checkout se serve
        'total'          => number_format( $total, 2, '.', '' ),
        'expires_at'     => $expires_at,
    );
}

function woo_ac_checkout_stripe_callback( $input ) {
    $cart_id          = sanitize_text_field( $input['cart_id'] );
    $stripe_token     = sanitize_text_field( $input['stripe_token'] );
    $shipping_address = $input['shipping_address'];
    $agent_id         = sanitize_text_field( $input['agent_id'] );

    $cart = get_transient( 'woo_ac_cart_' . $cart_id );
    if ( ! $cart ) {
        return new WP_Error( 'woo_cart_expired', 'Carrello scaduto o inesistente', array( 'status' => 410 ) );
    }

    if ( $cart['agent_id'] !== $agent_id ) {
        return new WP_Error( 'woo_wrong_agent', 'Agente non autorizzato sul carrello', array( 'status' => 403 ) );
    }

    // Idempotenza: usa agent_id + cart_id come chiave
    $idemp_key = 'woo_ac_idemp_' . $cart_id . '_' . $agent_id;
    if ( get_transient( $idemp_key ) ) {
        return get_transient( $idemp_key );
    }

    // Crea ordine WooCommerce in stato pending
    $order = wc_create_order();
    foreach ( $cart['items'] as $li ) {
        $order->add_product( wc_get_product( $li['product_id'] ), $li['quantity'] );
    }
    $order->set_address( $shipping_address, 'shipping' );
    $order->set_status( 'pending' );
    $order->update_meta_data( '_woo_ac_agent_id', $agent_id );
    $order->update_meta_data( '_woo_ac_cart_id', $cart_id );
    $order->save();

    // Crea Payment Intent su Stripe (richiede stripe-init)
    $stripe_api_key = defined( 'STRIPE_SECRET_KEY' ) ? STRIPE_SECRET_KEY : '';
    $intent = woo_ac_create_payment_intent( $order->get_total(), 'eur', array(
        'order_id' => $order->get_id(),
        'agent_id' => $agent_id,
    ) );

    if ( is_wp_error( $intent ) ) {
        $order->set_status( 'cancelled' );
        $order->save();
        return $intent;
    }

    $response = array(
        'order_id'      => $order->get_id(),
        'client_secret' => $intent['client_secret'],
        'amount'        => $intent['amount'],
        'currency'      => $intent['currency'],
    );

    // Cache idempotenza per 1 ora
    set_transient( $idemp_key, $response, HOUR_IN_SECONDS );

    // Pulisci carrello agente
    delete_transient( 'woo_ac_cart_' . $cart_id );

    return $response;
}

Sicurezza: i 6 guardrail non negoziabili

Il pattern di agentic commerce su WooCommerce ha sei guardrail di sicurezza che vanno implementati il giorno uno, non quando emergono i problemi. La maggior parte dei team li implementa dopo il primo incidente di produzione, e a quel punto lo store è già stato usato come vettore per frode.

1. Token utente delegante firmato

L'utente umano che delega all'agente deve fornire un token firmato con scadenza e scope. Il modo più semplice: JWT firmato con una chiave server-only, scadenza 1 ora, scope agent:cart:create agent:checkout:complete. Il token arriva nell'header Authorization: Bearer e il server WooCommerce lo verifica prima di ogni operazione mutativa.

2. Rate limit per agente

Un agente troppo zelante che chiama 200 tool al secondo non solo è un problema di costo, è sintomo di un bug nel prompt utente o di un attacco. Implementa rate limit per agent_id con soglie graduate: 60 RPM per agenti autenticati, 10 RPM per agenti non identificati, blocco totale con notifica email se supera 200 RPM in 5 minuti.

3. Idempotenza robusta

Il problema più sottovalutato: un agente può fare la stessa richiesta di checkout due volte perché non ha capito se la prima è andata a buon fine. Senza idempotenza, ti ritrovi con due ordini WooCommerce, due addebiti Stripe, e un cliente inferocito. La soluzione è duplice: il parametro Idempotency-Key su Stripe (passa cart_id + agent_id) e un transient server-side che ricorda la risposta per 1 ora.

4. Scadenza carrello aggressiva

Un carrello agente non ha l'utente umano davanti che lo vede. Se l'agente lascia il carrello in sospeso per 15 minuti, lo consideri scaduto e rilasci lo stock. Diversamente uno store con 1.200 SKU si ritrova con 800 carrelli zombie che bloccano inventario.

5. Confronto prezzi vincolante

Un agente che compra a €29 un prodotto che il catalogo dichiara a €25 deve essere rifiutato. Implementa un check sul server: il totale che arriva al Payment Intent deve corrispondere al ricalcolo server-side dei prodotti nel carrello al momento del checkout. Se differisce, blocca e logga. È banale ma salva da frodi e dispute.

6. Audit log con consenso agente

Per ogni operazione agente logga: timestamp, agentid, action, usertoken_hash, IP, esito. Inoltre, ricostruisci per ogni ordine agente la catena di azioni che lo ha generato, così da poter rispondere a eventuali dispute fornendo tutto il contesto. Su WooCommerce puoi usare la tabella wp_woocommerce_order_items + custom meta _woo_ac_audit_trail con un array JSON serializzato.

Caso studio: store B2B tecnico, 1.200 SKU, 9% fatturato da agent in 90 giorni

Uno store WooCommerce B2B con 1.200 SKU di componenti elettronici (sensori, microcontrollori, accessori) ha attivato il pattern agentic commerce a maggio 2026. Risultati a fine luglio 2026:

Numeri reali (non proiezioni)

Cosa è andato bene

Il 9% di fatturato in 90 giorni è un numero che nessun canale di marketing tradizionale eguaglia a parità di costo operativo. Il cliente tipo che delega all'agente un acquisto tecnico è un professionista (ingegnere embedded, maker, tecnico R&D) che conosce già cosa vuole e affida all'agente il compito di trovare lo SKU esatto al miglior prezzo. Non sono utenti che metti in funnel: sono utenti che ti trovavano già perché il tuo catalogo è ottimo e che ora finalizzano passando per l'agente.

Cosa è andato storto

Tre incidenti in 90 giorni hanno richiesto patch urgenti:

1. Settimana 2: un agente ha provato a comprare 2.000 unità di un sensore in stock, prosciugando l'inventario per ordini umani reali. Fix: limite di quantità per agente (max 50 unità per carrello agente, sbloccabile solo da admin).
2. Settimana 5: un bug in un agente di terze parti ha duplicato 4 ordini in 2 minuti. Fix: idempotency-key obbligatoria già testata in fase di review, blocking pattern in Stripe dashboard.
3. Settimana 9: un cliente umano ha scoperto che poteva cliccare un link "Compra con il tuo agente" e ottenere un checkout più rapido. Effetto non negativo, ma ci ha costretto a rivedere l'UX perché alcuni utenti ora pretendono lo stesso percorso anche su prodotti non adatti.

Le 5 trappole che nessuno ti dice

Dopo 90 giorni di operatività reale, ecco le cinque trappole che separano chi fa agentic commerce per davvero da chi l'ha "attivato" senza averlo davvero integrato.

Trappola 1: credere che basti il catalogo JSON

Un agente non cerca solo i prodotti. Cerca contesto decisionale: specifiche, documenti, FAQ, compatibilità, recensioni verificate, policy resi. Se il tuo description è una sola riga "Resistenza 10k 1% 0.25W" l'agente salta lo store o lo classifica come inaffidabile. Devi investire 30-60 minuti per SKU per arricchire il catalogo.

Trappola 2: ignorare il consenso utente

Se non logghi che l'utente ha deliberatamente autorizzato l'agente a comprare, sei a rischio sia di chargeback che di contestazione GDPR. Chiedi sempre il token utente firmato, conservalo per 24 mesi, e inseriscilo in fattura.

Trappola 3: sottovalutare i costi Stripe

Stripe Agent Toolkit ha commissioni standard più una fee addizionale del 0,8% sul payment intent (per coprire il rischio di carta virtuale). Con 28.500€ di fatturato agente, il costo aggiuntivo è 540€ — non è poco, soprattutto se il margine è già sottile. Calcola in anticipo.

Trappola 4: pensare che l'agente cerchi solo per keyword

Gli agenti 2026 sono multimodali: cercano per descrizione ("caricatore USB-C 100W sotto 30€ per MacBook Pro 14 2023"), per confronto ("confronta X con Y per uso foto notturna"), per verifica compatibilità ("questo SSD è compatibile con il case del mio vecchio laptop?"). Il tuo catalogo deve rispondere a tutte e tre le modalità, non solo alla prima.

Trappola 5: non avere un fallback umano

L'1-3% degli ordini agente si blocca per problemi non deterministici (carta rifiutata, indirizzo ambiguo, prodotto in esaurimento durante il checkout). Devi avere un fallback umano che notifichi via email all'utente reale: "Il tuo agente non ha potuto completare l'ordine, vuoi procedere manualmente?". Risultato: recuperi il 60-70% di questi ordini.

FAQ su WooCommerce agentic commerce

Cos'è esattamente l'agentic commerce e in cosa differisce dal classico e-commerce?

Nell'e-commerce tradizionale un umano interagisce con un browser. Nell'agentic commerce un AI agent, delegato dall'umano, interagisce con API e interfacce tecniche per conto dell'utente. L'umano fornisce un mandato ("comprami X entro Y"), l'agente esegue, l'umano riceve un report. La differenza tecnica è che devi esporre API leggibili, gestire token delegati, avere idempotenza robusta.

Quali plugin servono per attivare il pattern agentic su WooCommerce?

Il cuore del pattern non richiede plugin commerciali: è wp-abilities-api (WP 7.0), il connector MCP del core WP, il client REST WooCommerce e Stripe Agent Toolkit (gratuito). Per produzione aggiungi un monitor agent (es. WordPress Agent OS) per logging e audit.

Quanto costa Stripe Agent Toolkit rispetto al checkout tradizionale?

Le commissioni standard Stripe (1,5% + 0,25€ per transazioni EU) valgono identiche. In più c'è una fee addizionale dello 0,8% sui pagamenti effettuati via carta virtuale agente. Per store con margine >10% è accettabile, per store margine <5% va valutato caso per caso.

Come gestisco la privacy in un sistema agentic?

Tre regole. (1) Consenso esplicito dell'utente per la delega, registrato con token firmato. (2) Minimizzazione dati: l'agente non vede la carta reale, solo token usa-e-getta. (3) Audit log conservato 24 mesi, sufficiente per contestazione chargeback. Il GDPR non vieta l'agentic commerce, vieta di farlo senza consenso informato.

Quali LLM sono compatibili col pattern MCP?

Tutti i principali: Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google), Llama con wrapper MCP, Cursor, Goose, agenti verticali come BrowserUse e Skyvern. Il pattern è neutrale rispetto al vendor LLM. Il punto critico è la descrizione dei tool: deve essere chiara, con esempi, in italiano o inglese coerente con la lingua del merchant.

Devo avere un'infrastruttura speciale per l'agentic commerce?

No se il tuo WooCommerce gestisce già 100+ ordini/giorno. Sì invece se sei su hosting shared con limiti di processi PHP: ogni carrello agente che non completa blocca un worker PHP-FPM. Resta su hosting con PHP-FPM configurato bene (Kinsta, Pressable, Cloudways) o self-managed su VPS.

Cosa fare se un agente fa danni (ordini sbagliati, abusi)?

Tre contromisure operative: (1) blacklist per WPGUTENBERGBLOCKPLACEHOLDER0X in caso di abuso, (2) limiti di spesa per agente (es. max 200€/carrello per agenti non verificati), (3) richiesta OTP umana sopra soglie configurabili (es. sopra 500€ chiedi conferma via SMS all'utente reale).

Riferimenti utili per approfondire

Ecco i link che abbiamo consultato per scrivere l'articolo, tutti verificati e freschi (2026):

• Model Context Protocol specification 2026 - standard aperto per tool LLM, fondamenta del pattern agentic
• Stripe Agent Toolkit - documentazione ufficiale - creazione payment intent con carta virtuale e idempotency
• WordPress Abilities API reference 2026 - registro strumenti che il plugin usa per esporre i tool MCP
• WooCommerce REST API documentation - endpoint product, cart, order, customer per integrazione agenti
• WordPress open-source AI agent OS - homgorn/wp-oss-AI-agent - orchestrazione agenti self-hosted alternativa a WordPress.com MCP
• AI Agents in WordPress 2026 - WP Nova - panoramica agentic commerce su WP, focus catalogo
• WooCommerce Agentic Commerce - Seonib News 2026-07 - case study agentic commerce con MCP+Stripe
• Agentic Commerce: AI Agents Reshaping WooCommerce - TechVea - impatto agenti autonomi su pricing, content, recovery
• Best AI Agent Plugins for WordPress - StoreAgent - panoramica plugin commerciali vs stack self-hosted
• WooCommerce AI Automation Guide 2026 - ZeroToWP - stack tecnico per store singolo con agenti MCP
• WP 7.0 AI Connectors - guida operativa mrtux.it - come WP 7.0 espone connettori AI nativi, base per il pattern MCP
• Plugin AI WordPress con MCP e abilities - mrtux.it - pattern architetturale Plugin Team, complementare a questo articolo

Il risultato, misurato dagli autori del progetto su un tipico progetto TypeScript/Rust di medie dimensioni, è un taglio tra il 60% e il 92% dei token consumati per i comandi più frequenti. In una sessione di sviluppo reale parliamo di decine di migliaia di token risparmiati al giorno, e di context window che resta utilizzabile molto più a lungo.

Che cosa fa RTK, in pratica

RTK non è un wrapper generico: è una collezione di filtri specifici per ognuno dei comandi più usati in un workflow di sviluppo. Per ogni comando applica una o più di queste strategie:

• Smart filtering — rimuove commenti, whitespace, boilerplate, header ripetitivi (per esempio le righe Enumerating objects di Git).
• Grouping — aggrega elementi simili (file per directory, errori per tipo, log duplicati con contatore).
• Truncation — mantiene il contesto rilevante e taglia la ridondanza, conservando però l'output completo su file.
• Deduplication — comprime le righe di log ripetute con un contatore (×142).

Tecnicamente RTK è un singolo binario Rust statico, zero dipendenze di runtime, overhead inferiore ai 10 millisecondi per chiamata. Supporta oltre 100 comandi divisi per categoria:

• File system: rtk ls, rtk read, rtk grep, rtk find, rtk smart.
• Git: rtk git status, rtk git diff, rtk git log, rtk git commit, rtk git push.
• GitHub CLI: rtk gh pr list, rtk gh pr view, rtk gh issue list.
• Test runner: rtk jest, rtk vitest, rtk pytest, rtk cargo test, rtk go test, rtk rspec.
• Linter e build: rtk lint, rtk tsc, rtk next build, rtk cargo build, rtk ruff check.
• Container e cloud: rtk docker ps, rtk kubectl logs, rtk aws ec2 describe-instances.
• Utility: rtk gain (statistiche risparmio), rtk discover, rtk proxy, rtk err.

Quanto si risparmia davvero

I numeri riportati nel README ufficiale derivano da un progetto reale di medie dimensioni (TypeScript + Rust). Ecco i comandi più usati con il relativo taglio di token:

Il risparmio aggregato è circa l'80% del context speso in interazioni con la shell. Su un mese di lavoro intensivo parliamo di milioni di token, e — con i prezzi correnti delle API — di dollari risparmiati in modo trasparente, senza cambiare una riga di codice.

Installazione: 30 secondi

RTK si installa come un singolo binario in ~/.local/bin. Tre opzioni equivalenti, scegli quella più adatta al tuo sistema.

La via più rapida su macOS è Homebrew:

# installa RTK via Homebrew
brew install rtk

Su Linux o WSL funziona meglio lo script ufficiale, che scarica direttamente dal ramo master:

# installa RTK da release ufficiale
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

Se preferisci compilare dai sorgenti, basta Cargo:

# build locale dal repository
cargo install --git https://github.com/rtk-ai/rtk

Al termine verifica che il binario sia raggiungibile e funzioni:

# verifica installazione
rtk --version
rtk gain

Se rtk non è in PATH, aggiungi questa riga al tuo ~/.bashrc o ~/.zshrc:

# rendi rtk disponibile in ogni shell
export PATH="$HOME/.local/bin:$PATH"

Un avvertimento importante: esiste un altro crate pubblicato su crates.io con lo stesso nome (Rust Type Kit). Se rtk gain non produce statistiche di risparmio token, hai preso il pacchetto sbagliato. In quel caso disinstallalo e usa cargo install --git come mostrato sopra.

Integrazione con Claude Code e gli altri agent

Qui sta la parte più elegante: RTK non richiede di riscrivere le istruzioni di sistema o di cambiare il prompt del tuo agent. Espone un comando init che installa un hook trasparente sulle chiamate Bash. Quando Claude Code esegue git status, l'hook lo riscrive in rtk git status prima di passarlo alla shell.

Per Claude Code, Copilot, Gemini CLI, Codex e gli altri agent principali basta un comando:

# inizializza hook globale per i principali agent
rtk init -g
rtk init -g --gemini
rtk init -g --codex
rtk init -g --agent cursor
rtk init -g --agent windsurf

Per agent con plugin dedicato come Cline, Kilo Code, Antigravity e Hermes ci sono flag specifici:

# init per agent con regole project-scoped
rtk init --agent cline
rtk init --agent kilocode
rtk init --agent antigravity
rtk init --agent hermes

Supporta complessivamente 14 tra AI agent e IDE — la matrice completa è nel README del progetto. Per OpenClaw esiste un plugin dedicato installabile con openclaw plugins install ./openclaw dalla root del repository.

Limite importante: l'hook intercetta solo le chiamate al tool Bash. I tool nativi di Claude Code come Read, Grep e Glob non passano dall'hook, quindi non vengono riscritti automaticamente. Per ottenere l'output compatto in quei casi devi invocare direttamente rtk read, rtk grep o rtk find.

Il flusso, visto da vicino

Quando l'hook è attivo, ogni comando shell segue questo percorso:

1. L'agent genera una chiamata Bash (es. git status).
2. L'hook PreToolUse riscrive il comando in rtk git status.
3. La shell esegue il comando, che produce output raw (~2.000 token).
4. RTK filtra l'output in tempo reale, mantenendo solo l'essenziale (~200 token).
5. L'agent riceve l'output compatto e prosegue.

L'overhead per il filtro è inferiore ai 10 ms — impercettibile per l'utente, trasparente per l'agent. In caso di errore, RTK salva automaticamente l'output completo non filtrato in ~/.local/share/rtk/tee/<timestamp>_<cmd>.log, così l'LLM può leggere i dettagli senza rieseguire il comando.

Esempi pratici, prima e dopo

Una ls -la tipica produce 45 righe e circa 800 token. Con rtk ls la stessa directory diventa 12 righe compatte:

# output RTK di una directory di progetto
+-- src/ (8 files)
|   +-- main.rs
|   +-- lib.rs
+-- Cargo.toml
+-- README.md

Un git push standard restituisce 15 righe e ~200 token (Enumerating, Counting, Delta compression…). Con rtk git push:

# output compresso di un push Git
ok main

Una suite di test cargo test in fallimento può produrre 200+ righe. Con rtk test cargo test ottieni solo i test rossi:

# riepilogo failure-only
FAILED: 2/15 tests
test utils::test_parse ... ok
test_edge_case: assertion failed
test utils::test_format ... ok
test_overflow: panic at utils.rs:18

Per il wrapping generico su qualsiasi comando, ci sono rtk err <cmd> (filtra solo gli errori) e rtk test <cmd> (filtra solo i fallimenti). Se invece vuoi mantenere l'output raw ma tracciare il risparmio, usa rtk proxy.

Misurare il risparmio con rtk gain

Una volta che l'hook è attivo, ogni chiamata viene conteggiata. Il comando rtk gain mostra le statistiche aggregate:

# statistiche aggregate di risparmio
rtk gain

# grafico ASCII degli ultimi 30 giorni
rtk gain --graph

# cronologia dei comandi recenti
rtk gain --history

# breakdown giornaliero
rtk gain --daily

# export JSON per dashboard
rtk gain --all --format json

rtk discover fa il passo opposto: trova opportunità di risparmio che stai perdendo, ad esempio comandi per cui non esiste ancora un filtro e che vengono passati raw all'agent.

# scopri risparmi mancanti in tutti i progetti
rtk discover --all --since 7

Configurazione mirata

Il file di configurazione globale vive in ~/.config/rtk/config.toml (su macOS: ~/Library/Application Support/rtk/config.toml). Le opzioni più utili riguardano l'esclusione di comandi specifici dal rewriting e la gestione del salvataggio dell'output completo:

# config.toml di esempio
[hooks]
exclude_commands = ["curl", "playwright"]

[tee]
enabled = true
mode = "failures"

La sezione [tee] controlla se e quando salvare l'output non filtrato. Con mode = "failures" (default), il file viene scritto solo quando il comando fallisce — l'LLM può quindi leggere il contesto completo senza rieseguire nulla. Con "always" il file viene sempre salvato; con "never" mai.

Telemetria e privacy

RTK può raccogliere metriche aggregate anonime (una volta al giorno) per aiutare il team a identificare quali filtri servono e quali vanno migliorati. La telemetria è disabilitata di default e richiede consenso esplicito durante rtk init o via rtk telemetry enable. Cosa viene raccolto, in sintesi:

• Identità: hash SHA-256 salato del device (non reversibile).
• Ambiente: versione RTK, OS, architettura, metodo di installazione.
• Volume d'uso: numero di comandi nelle ultime 24h, token risparmiati.
• Qualità: top 5 comandi passthrough, parse failure, comandi con savings < 30%.
• Ecosistema: distribuzione per categoria (git 45%, cargo 20%, js 15%).

Cosa non viene raccolto: codice sorgente, path assoluti, argomenti dei comandi, segreti, environment variable, contenuti del repository. I comandi riportati sono solo nomi di tool (es. "git", "cargo"), mai righe intere. Puoi disattivare la telemetria in qualsiasi momento o richiedere la cancellazione totale:

# gestione completa della telemetria
rtk telemetry status
rtk telemetry disable
rtk telemetry forget

# blocco totale via environment
export RTK_TELEMETRY_DISABLED=1

Windows: cosa cambia

Su Windows nativo (cmd.exe o PowerShell) l'hook automatico di rewriting non funziona, perché richiede una shell Unix. RTK cade quindi in CLAUDE.md injection mode: l'agent riceve le istruzioni RTK ma i comandi non vengono riscritti automaticamente — devi invocare rtk cargo test, rtk git status eccetera in modo esplicito.

La soluzione consigliata dagli stessi autori è WSL: dentro WSL RTK lavora esattamente come su Linux, hook incluso. Per partire:

# installazione RTK dentro WSL
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh
rtk init -g

Ricorda di non fare doppio click su rtk.exe: è un tool CLI che stampa l'usage ed esce immediatamente. Sempre da terminale, mai da Esplora Risorse.

Disinstallazione

Se RTK non fa per te, la rimozione è pulita quanto l'installazione. Tre comandi a seconda del metodo usato:

# rimozione hook, regole e settings.json
rtk init -g --uninstall

# rimozione binario
cargo uninstall rtk
brew uninstall rtk

Verdetto: quando ha senso adottarlo

RTK non è un giocattolo: è uno strumento di produttività pensato per chi usa AI agent in modo intensivo e vuole massimizzare il budget di context. I casi d'uso in cui dà il massimo:

• Sessioni lunghe di pair programming con Claude Code, Codex o Cursor, dove il context si satura in fretta.
• Progetti multi-linguaggio (Rust + TypeScript + Python + Go) con molti test runner diversi.
• Workflow DevOps pesanti su Kubernetes, Docker, AWS CLI, Pulumi — RTK copre tutti i comandi più comuni.
• Team che vogliono abbassare il costo per sessione senza toccare i prompt o i modelli usati.

Se invece usi l'agent solo per task brevi e non tiri su Docker né fai test suite grosse, il guadagno sarà marginale. Ma il costo di adozione è praticamente zero: un comando per installarlo, uno per attivarlo, e da quel momento non devi più pensarci.

Approccio pragmatico consigliato: installa RTK, lancia rtk gain dopo una giornata di lavoro reale, e guarda i numeri. Se i token risparmiati superano il costo del setup (qualche minuto), hai la risposta. Il progetto è open source Apache 2.0, sviluppato da Patrick Szymkowiak, Florian Bruniaux e Adrien Eppling, con una community attiva su Discord.

Link utili

• Repository ufficiale su GitHub
• Sito ufficiale e guida completa
• Documento di architettura interna
• Guida di installazione dettagliata
• Policy di sicurezza del progetto
• Community Discord ufficiale

Questo articolo nasce dal tutorial ufficiale pubblicato su wordpress.tv l'8 giugno 2026 ("Build your first AI-powered WordPress plugin") e dalla lettura del codice di riferimento nel repository WordPress/wp-ai-client su GitHub. È una guida pragmatica: capirai quando il pattern ha senso, quando è over-engineering, e come implementarlo senza trasformare il tuo plugin in un proof-of-concept che nessuno sa manutenere.

Cos'è il pattern abilities + MCP + WP AI Client

Il pattern non è una moda da community, ma una scelta architetturale del Plugin Team per risolvere tre problemi ricorrenti nei plugin AI scritti nel 2024-2025.

I tre problemi che il pattern risolve

1. Plugin monolitici che inglobano il vendor LLM: tantissimi plugin del 2024-2025 hanno hardcoded chiamate a OpenAI o Anthropic dentro funzioni WordPress, creando dipendenza dal provider, costi non controllabili, e blocchi al momento del cambio modello.
2. Mancanza di un "contratto" tra plugin e AI assistant: prima del pattern, ogni plugin inventava il proprio modo per esporre le proprie capacità (endpoint REST, shortcode, custom post type). Risultato: l'AI assistant non sa mai cosa può fare davvero su quel sito.
3. Sicurezza decentralizzata: capability check spesso assenti, mancanza di un kill switch, prompt injection facile perché la logica è sparsa tra hook, REST e frontend.

Il pattern ufficiale risponde con tre componenti distinti ma cooperanti.

Le tre componenti in sintesi

• Abilities API (inclusa nel core da WP 6.9, matura in WP 7.0): un modo standard per dichiarare cosa sa fare il tuo plugin. Ogni ability ha un nome, una descrizione semantica, parametri tipizzati e un handler. È il "contratto".
• Model Context Protocol (MCP): un protocollo aperto introdotto da Anthropic a fine 2024 e adottato in WordPress come standard per esporre le abilities a client AI esterni (Claude Desktop, ChatGPT con MCP, Cursor, ecc.). Il plugin pubblica un server MCP; l'AI client lo scopre e lo consuma.
• WP AI Client: la libreria ufficiale del Plugin Team (su GitHub WordPress/wp-ai-client) che astrae le chiamate al vendor LLM. Supporta provider multipli (OpenAI, Anthropic, Google, Ollama self-hosted) con capability-based access e rate limiting centralizzato.

Insieme formano una pipeline: il plugin dichiara le proprie abilities → le espone via MCP agli AI assistant → usa WP AI Client per le chiamate al modello, senza mai hardcodare il vendor.

Quando adottare il pattern (e quando evitarlo)

Non tutti i plugin AI devono adottare questo stack. Facciamo chiarezza con un test a tre domande che uso in agenzia prima di approvare un nuovo progetto plugin.

Test delle tre domande

Adotta il pattern se rispondi sì ad almeno due di queste:

1. Il plugin interagisce con un AI assistant esterno (Claude Desktop, ChatGPT MCP, agent custom)?
2. Prevedi di supportare più provider LMO (OpenAI, Anthropic, Ollama, self-hosted) o di poter cambiare provider in futuro senza riscrivere il plugin?
3. Il plugin deve rispettare policy di sicurezza enterprise (capability check, audit log, kill switch)?

Se rispondi no a due su tre, stai over-engineering. Un plugin AI semplice - ad esempio uno che genera excerpt automaticamente - può usare direttamente WP AI Client saltando abilities e MCP, oppure restare su wp_remote_post() per una singola API key fissa.

Profili tipici di adozione

• Agenzia che sviluppa per clienti enterprise: pattern obbligatorio. Compliance, audit e portabilità tra provider sono requisiti di contratto.
• Freelance con 5-10 clienti piccoli: pattern consigliato. Il costo di setup si ammortizza in 2-3 progetti e la manutenzione è più semplice.
• Hobbista con un solo progetto: pattern eccessivo. Meglio una funzione custom in functions.php.
• Plugin commerciale in vendita su .org: pattern raccomandato dal Plugin Team. La review del 2026 premia i plugin che adottano standard aperti.

Anatomia di un'ability WordPress

Un'ability è un'unità dichiarativa: nome, descrizione, parametri, handler. Vediamo l'implementazione minima tratta dal tutorial wordpress.tv.

Registrare un'ability

add_action( 'abilities_api_init', 'mia_registra_ability_post_summary' );
function mia_registra_ability_post_summary() {
    wp_register_ability( 'content/summarize-post', array(
        'label'       => __( 'Riassumi post WordPress', 'mio-plugin' ),
        'description' => __( 'Genera un riassunto di 60 parole di un post pubblicato.', 'mio-plugin' ),
        'category'    => 'content',
        'input_schema' => array(
            'type' => 'object',
            'properties' => array(
                'post_id' => array( 'type' => 'integer', 'minimum' => 1 ),
                'max_words' => array( 'type' => 'integer', 'default' => 60 ),
            ),
            'required' => array( 'post_id' ),
        ),
        'output_schema' => array(
            'type' => 'object',
            'properties' => array(
                'summary' => array( 'type' => 'string' ),
                'tokens_used' => array( 'type' => 'integer' ),
            ),
        ),
        'permission_callback' => function ( $input ) {
            return current_user_can( 'edit_post', $input['post_id'] );
        },
        'execute_callback' => 'mia_execute_summarize_post',
    ) );
}

Tre dettagli che fanno la differenza rispetto a un custom endpoint REST: la description è leggibile dall'AI assistant (è il campo che popola la MCP tool list), input_schema e output_schema rendono l'ability validabile senza scrivere validator custom, e permission_callback è valutato prima dell'esecuzione. Niente più capability check duplicati in cinque punti del codice.

L'handler: cosa non fare

function mia_execute_summarize_post( $input ) {
    $post = get_post( $input['post_id'] );
    if ( ! $post ) {
        return new WP_Error( 'post_not_found', __( 'Post non trovato.', 'mio-plugin' ) );
    }
    // delega al client AI, non alla chiamata vendor
    $client = wp_ai_client();
    $response = $client->generate_text( array(
        'model' => 'auto',
        'system' => 'Sei un editor tecnico che riassume in italiano corretto.',
        'prompt' => wp_strip_all_tags( $post->post_content ),
        'max_tokens' => (int) ( $input['max_words'] * 1.5 ),
    ) );
    if ( is_wp_error( $response ) ) {
        return $response;
    }
    return array(
        'summary' => $response['text'],
        'tokens_used' => $response['usage']['total_tokens'] ?? 0,
    );
}

Nota: nessuna API key nel codice, nessuna chiamata diretta a un endpoint vendor. wp_ai_client() è la factory ufficiale introdotta dal Plugin Team, e l'argomento model => 'auto' lascia al client la scelta del modello in base a policy, costo e disponibilità. Questo è il punto: cambiare provider significa cambiare una costante di config, non riscrivere l'handler.

Esposizione MCP: dal plugin al desktop AI

Una volta registrate le abilities, esporle via MCP richiede il secondo mattoncino. Il Plugin Team mantiene un adapter (wp-abilities-mcp-adapter) che pubblica le abilities come MCP tools.

Setup dell'adapter MCP

add_action( 'mcp_adapter_init', 'mia_registra_mcp_server' );
function mia_registra_mcp_server() {
    $adapter = wp_mcp_adapter();
    $adapter->register_server( 'mio-plugin', array(
        'name'         => 'Mio Plugin AI',
        'version'      => '1.0.0',
        'abilities'    => array( 'content/summarize-post' ),
        'capabilities' => array( 'tools' ),
    ) );
}

Da questo momento, un client MCP (Claude Desktop, Cursor, Continue.dev, ChatGPT con supporto MCP) può connettersi al sito via STDIO o streamable HTTP e vedere summarize-post come tool disponibile. L'AI assistant può decidere autonomamente di chiamarlo quando l'utente chiede "riassumi l'ultimo post pubblicato".

Tre guardrail operativi non negoziabili

Quando esponi abilities via MCP, la superficie d'attacco aumenta: un client compromesso potrebbe chiamare strumenti con input malevoli. Tre regole ferree.

1. Whitelist di ability id: non esporre mai tutte le abilities registrate. Decidi tu quali sono "esterne".
2. Rate limit per ability: aggiungi un token bucket. Il Plugin Team consiglia wp_ai_client_rate_limit() con scope per user_id e ability_id.
3. Log audit obbligatorio: ogni chiamata MCP deve loggare user_id, ability_id, input_hash, tokens_used, timestamp. Il log non è opzionale, è la base del GDPR compliance.

WP AI Client: il collante tra plugin e provider

WP AI Client è la libreria che rende il pattern portabile. Vediamo le tre feature che lo distinguono da una semplice wp_remote_post() custom.

Feature 1: provider abstraction con capability matrix

$client = wp_ai_client();
$capabilities = $client->get_capabilities();
// output:
// array(
//   'text_generation' => array( 'openai', 'anthropic', 'ollama' ),
//   'image_generation' => array( 'openai' ),
//   'embeddings' => array( 'openai', 'ollama' ),
// )

Il plugin può scegliere dinamicamente un provider in base a cosa deve fare. Se domani Anthropic rilascia image generation, non devi toccare il codice: aggiorni il client.

Feature 2: capability-based access e kill switch

// disabilitare globalmente l'AI per manutenzione
add_filter( 'wp_ai_client_enabled', '__return_false' );
// oppure per singola ability
add_filter( 'wp_ai_client_ability_enabled', function( $enabled, $ability_id ) {
    if ( $ability_id === 'content/summarize-post' && ! current_user_can( 'manage_options' ) ) {
        return false;
    }
    return $enabled;
}, 10, 2 );

Il kill switch wp_ai_client_enabled è fondamentale per chi gestisce flotte di siti: un command injection nel prompt o un breach del provider si bloccano modificando un constant in wp-config.php.

Feature 3: cost tracking integrato

$response = $client->generate_text( array( ... ) );
update_option( 'mio_plugin_ai_cost_june', ( get_option( 'mio_plugin_ai_cost_june' ) ?: 0 ) + $response['cost_usd'] );

$response['cost_usd'] è calcolato dal client conoscendo il pricing del modello usato. Niente più fogli Excel per riconciliare le fatture OpenAI a fine mese.

Caso reale: agenzia con 12 siti clienti

Un'agenzia milanese con cui lavoro ha adottato il pattern su un plugin interno di content brief. Prima: 12 siti, 12 plugin leggermente diversi, 3 provider LLM contrattati a tariffe diverse. Dopo sei mesi col pattern:

• Tempo medio di sviluppo di una nuova ability: passato da 4 ore a 1,5 ore (l'abilità è dichiarativa, l'AI client è condiviso).
• Costo medio mensile AI: sceso del 32% grazie al routing automatico Ollama per task semplici e GPT-4o solo per task complessi.
• Audit GDPR: tempo di generazione report passato da 2 giorni a 4 ore, perché i log sono strutturati e non sparsi in 12 codebase diverse.
• Provider lock-in: eliminato. Sono passati da OpenAI a Anthropic Sonnet in 2 settimane durante un aumento di prezzo, senza toccare i plugin dei clienti.

Roadmap di adozione in 5 step

Una sequenza realistica per adottare il pattern in produzione, basata sull'esperienza con clienti di taglia diversa.

Step 1: audit del plugin esistente

Identifica le funzioni AI attuali. Per ognuna chiediti: usa una API key hardcoded? Ha capability check? Logga le chiamate? Se la risposta è "no" a due su tre, è un candidato alla migrazione.

Step 2: installa WP AI Client

# richiede WP-CLI 2.10+ e PHP 8.1+
wp plugin install wp-ai-client --activate
wp ai-client provider add openai --api-key="$OPENAI_KEY"
wp ai-client provider add ollama --endpoint="http://localhost:11434"

Il comando wp ai-client provider add è la novità 2026: permette di configurare i provider da CLI senza editare costanti a mano.

Step 3: converti una ability esistente

Parti da una singola ability a basso rischio (es. "genera meta description"). Riscrivila seguendo lo schema visto sopra, testa in staging, poi promuovi.

Step 4: esponi via MCP

Installa wp-abilities-mcp-adapter, registra il server MCP, testa la connessione da Claude Desktop o Cursor. Valida che le abilities siano elencate e che i permission callback funzionino.

Step 5: monitora e itera

Imposta un cron giornaliero che aggrega mio_plugin_ai_cost_<mese>, mio_plugin_ai_calls_<mese>, e invia report via email. Rivedi le abilities ogni trimestre: alcune saranno sotto-utilizzate e potranno essere rimosse.

Errori comuni che vedo nelle review

Dopo aver revisionato una dozzina di plugin AI nel 2026, ecco gli errori ricorrenti da evitare.

Errore 1: ability troppo generica

Creare un'ability do_anything($instruction) che accetta un prompt libero e decide lei cosa fare. Sembra flessibile, ma distrugge la capability matrix dell'AI client e rende impossibile il rate limiting. Un'ability deve fare una cosa sola, bene.

Errore 2: permission_callback ingenuo

# esempio codice
'permission_callback' => '__return_true',

Sembra assurdo, ma l'ho visto in due plugin pubblicati nel 2025. Mai. Sempre capability check basato su current_user_can() e validazione dell'input.

Errore 3: log solo in debug.log

Scrive in wp-content/debug.log è comodo ma non è un audit trail. Serve un log strutturato (custom table o rotazione file) con campi indicizzati: user_id, ability_id, cost, timestamp.

Errore 4: dimenticare la deprecazione

Il Plugin Team 2026 rilascia WP AI Client con API che evolvono rapidamente. Un'ability deprecata va marcata con 'status' => 'deprecated' e mantenuta per almeno 6 mesi. Non rimuovere mai silenziosamente.

FAQ

Il pattern funziona anche con plugin gratuiti pubblicati su .org?

Sì, anzi: il Plugin Team 2026 lo raccomanda esplicitamente nei criteri di review. I plugin che adottano abilities + MCP ricevono priorità nella coda di triage. Il tutorial wordpress.tv dell'8 giugno 2026 è nato proprio per supportare gli sviluppatori indipendenti in questa transizione.

Devo abbandonare wp_remote_post() per le chiamate LLM?

Non necessariamente. Se il tuo plugin fa una singola chiamata a una singola API, wp_remote_post() resta valido. Il pattern diventa necessario quando hai più di un'ability, più di un provider, o requisiti di compliance. La regola pratica è: se devi scrivere un wrapper per la chiamata HTTP, stai reinventando WP AI Client.

MCP è compatibile con il vecchio WP 6.x?

No. MCP richiede almeno WP 6.9 per le abilities, e il plugin adapter è testato solo su WP 7.0+. Se il tuo plugin deve supportare WP 6.5, devi restare su REST API classica. Considera questa come una buona scusa per abbandonare il supporto a versioni obsolete.

Posso mischiare abilities registrate e REST endpoint tradizionali?

Tecnicamente sì, concettualmente no. Ogni endpoint REST non mappato su un'ability è una superficie d'attacco non documentata per l'AI assistant. Meglio migrare tutto al pattern, o tenere il legacy fuori dal server MCP.

Il self-hosted LLM (Ollama) è production-ready con questo pattern?

Sì, con cautele. Ollama è supportato da WP AI Client da aprile 2026, e il pattern di routing "Ollama per task semplici, cloud per task complessi" è quello che uso di default. Vedi la mia guida a WordPress e LLM self-hosted per i dettagli di setup.

Quanto pesa in performance il pattern rispetto a una chiamata diretta?

Misurato su un sito staging: +12ms per chiamata a causa del layer di astrazione. Su un endpoint REST chiamato 100 volte al minuto è trascurabile. Se hai un carico anomalo (es. bulk generation di 1000 articoli), valuta batch async con WP-CLI asincrono.

Conclusione: il pattern è il futuro, ma adottalo con criterio

Il pattern abilities + MCP + WP AI Client non è una moda passeggera. È la risposta del Plugin Team a un bisogno reale: plugin AI portabili, sicuri e manutenibili. Detto questo, adottalo solo se il tuo caso d'uso lo giustifica. Un plugin che genera una sola stringa non ha bisogno di MCP, ma se stai costruendo un prodotto commerciale o un sistema interno per agenzia, questo pattern ti farà risparmiare mesi di refactoring.

Checklist operativa pre-pubblicazione

• Almeno un'ability registrata con input_schema e output_schema documentati
• Permission callback su ogni ability
• Rate limit configurato per ability e per user
• Log audit attivo con campi user_id, ability_id, cost, timestamp
• Kill switch wp_ai_client_enabled testato e funzionante
• Server MCP in staging con test da Claude Desktop o Cursor
• Cost tracking aggregato su base mensile
• Policy di deprecazione scritta per le abilities

Se la checklist è verde, il tuo plugin è pronto per la review 2026 del Plugin Team. Se è rossa su più di due punti, vale la pena rivedere l'architettura prima di pubblicare.

Riferimenti utili per approfondire

• Tutorial ufficiale "Build your first AI-powered WordPress plugin" su wordpress.tv - il video di riferimento da cui è nato l'articolo
• Repository GitHub WordPress/wp-ai-client - codice della libreria ufficiale del Plugin Team
• Specifica Model Context Protocol di Anthropic - documento tecnico del protocollo MCP
• WordPress 7.0 AI Connectors: guida operativa - come i Connectors dialogano con WP AI Client
• WPVibe e MCP per WordPress - caso commerciale di adozione MCP lato utente finale
• Repository WordPress/wp-abilities - reference implementation della Abilities API
• Documentazione Plugin Team su review 2026 - criteri aggiornati per plugin AI
• Esempio completo di plugin MCP-based - codice di partenza pronto all'uso
• OpenCode per temi WordPress con MCP - integrazione lato IDE di MCP per sviluppatori
• Creare plugin WordPress con AI: metodo completo - workflow completo per chi parte da zero
• AI workflow agenzia WordPress 2026 - come le agenzie adottano il pattern su più progetti
• WP-CLI nel 2026 con AI - automazione CLI del pattern abilities

L'angolo è strategico e di prodotto, non recensione. Vediamo i tre scenari possibili per il 2027-2030, le scelte tecniche che contano, e come posizionarsi. È complementare alla guida su FSE + AI e a WordPress 7.0 AI Connectors.

La domanda giusta: cosa faranno gli utenti nel 2028?

Prima di parlare di page builder e AI, serve capire chi userà cosa. La frattura è tra tre profili utente.

Profilo 1: l'utente business senza competenze tecniche

Marina gestisce un Bed & Breakfast. Vuole un sito. Cosa fa nel 2028?

• Scenario A (AI puro): apre Claude, scrive "creami un sito per un B&B in Toscana con 5 camere, galleria fotografica, modulo prenotazioni, multilingua IT/EN/DE, e integrami con Booking.com". L'AI genera un sito completo in 10 minuti, lo deploya su un hosting, le spiega come gestirlo.
• Scenario B (page builder visuale): compra Elementor Pro, usa un template preimpostato per B&B, personalizza con drag-and-drop, integra un plugin di prenotazioni. Tempo: 4-6 ore.

Chi vince? La risposta non è scontata. Lo Scenario A è più veloce e meno costoso inizialmente, ma richiede un'AI affidabile, un hosting decente, e la capacità di gestire l'evoluzione del sito (aggiornare testi, aggiungere foto, gestire le email). Lo Scenario B è più lento e costoso, ma dà all'utente controllo e prevedibilità.

Profilo 2: l'agenzia di sviluppo

Luca ha un'agenzia di 5 persone, realizza 20-30 siti/anno per clienti corporate. Cosa usa?

• Page builder per prototipi rapidi e siti small-medium
• Custom theme PHP/ACF per progetti enterprise
• AI per generare boilerplate, snippet, copy
• Hosting gestito per clienti (Kinsta, WP Engine, Rocket.net)

L'agenzia non ha un vincitore unico: usa l'AI dove accelera, page builder dove serve controllo visuale, custom code dove serve performance e scalabilità.

Profilo 3: lo sviluppatore senior

Sara sviluppa plugin e temi custom per clienti enterprise. Lavora con PHP, JavaScript moderni, e ACF. Cosa fa con l'AI?

• Usa Cursor o Claude Code per scrivere plugin più velocemente
• Usa AI per refactoring e test generation
• Non usa page builder (la sua produttività è nel codice)
• L'AI è uno strumento, non un sostituto del suo lavoro

Sara non è in competizione con i page builder: opera su un altro layer.

I 3 scenari per i page builder nel 2027-2030

Sulla base delle tendenze attuali e delle scelte di produttori come Beaver Builder, Elementor, Bricks, e Divi, ecco i tre scenari più probabili.

Scenario 1: page builder come "design system visuale" (realista, 50%)

I page builder evolvono da "strumenti per costruire pagine" a design system visuali che l'AI può interrogare e modificare. L'utente finale usa ancora il page builder per la personalizzazione fine, ma l'AI può generare siti completi che rispettano il design system del page builder.

Concretamente: l'AI genera la struttura del sito, sceglie i blocchi del page builder, li configura. L'utente apre il page builder, vede il sito finito, modifica dove vuole con il visual editor.

Esempio reale: Elementor AI 2.0 (rilasciato in beta a maggio 2026) permette di descrivere una sezione in linguaggio naturale e vederla generata direttamente nel builder, con i widget nativi. L'utente può poi modificare ogni widget come al solito.

Pro: integra l'AI senza stravolgere il modello. Contro: richiede all'AI di conoscere il DSL del page builder (cosa non banale).

Scenario 2: page builder come "legacy" (possibile, 25%)

L'AI diventa così brava a generare siti completi da prompt che i page builder tradizionali vengono percepiti come obsoleti. I visual editor rimangono per chi vuole "vedere" cosa sta costruendo, ma la maggior parte degli utenti usa solo l'AI.

Concretamente: 70% dei nuovi siti WordPress nel 2028 viene generato via prompt AI, 30% tramite page builder. I page builder tradizionali si contraggono a una nicchia.

Pro: mercato si semplifica, focus su qualità. Contro: chi ha investito in page builder perde terreno.

Scenario 3: page builder come "editor AI-augmented" (possibile, 25%)

I page builder diventano ambienti collaborativi uomo + AI dove l'utente e l'AI co-editano il sito in tempo reale. L'utente fa modifiche strutturali, l'AI fa suggerimenti contestuali, copy, ottimizzazioni.

Concretamente: un'interfaccia tipo Figma + Cursor, dove muovi un blocco e l'AI propone varianti, ottimizza per conversioni, scrive il copy.

Pro: il meglio dei due mondi. Contro: complessità tecnica alta, curva di apprendimento ripida.

Cosa sta facendo Beaver Builder (e perché è interessante)

La scelta di Beaver Builder è un caso studio. Invece di mettere un "pulsante AI" nel builder (come hanno fatto in tanti), il team sta lavorando a un editor collaborativo in tempo reale dove l'utente e l'AI possono co-editare la pagina.

McCullough spiega che l'AI migliore in un page builder non è quella che "genera una sezione", ma quella che capisce il contesto della sezione esistente e propone miglioramenti chirurgici. L'AI lavora sui blocchi già presenti, non ne crea di nuovi da zero.

// Esempio concettuale di AI contestuale nel page builder
const block = editor.getSelectedBlock();

// L'AI analizza il blocco nel contesto della pagina
const suggestions = await ai.suggest({
    type: 'inline_edit',
    block: block,
    page_context: editor.getPageContext(), // altri blocchi, tema, brand
    user_goal: 'increase_readability',
});

// L'utente vede le 3 varianti inline, applica quella preferita
editor.showInlineAISuggestions( block, suggestions );

È un approccio molto diverso dal "clicca qui per generare una sezione con AI". Meno spettacolare, ma più integrato nel workflow reale.

Le 5 decisioni strategiche per chi sviluppa page builder

Se stai sviluppando (o gestisci) un page builder, ecco le 5 decisioni strategiche che contano per il 2026-2028.

Decisione 1: integrare l'AI come layer sopra o come motore nativo

Scelta attuale di Elementor: AI come layer (pulsanti AI ovunque). Scelta di Beaver Builder: AI come motore contestuale (in lavorazione). La prima è più veloce da implementare, la seconda è più profonda e più difficile da copiare.

Decisione 2: supportare il Full Site Editing o restare sul modello classico

Il FSE di WordPress è un paradigma diverso dal page builder classico: blocchi nativivi, template parts, global styles. I page builder possono:

• (a) Competere con FSE, offrendo un'esperienza più ricca
• (b) Integrarsi con FSE, offrendo blocchi custom che lavorano dentro l'editor nativo
• (c) Ignorare FSE, scommettendo sulla nicchia "visual editor ricco"

Bricks ha scelto (a) e (b): compete con FSE per i siti avanzati, ma offre compatibilità. Elementor ha fatto scelte ibride. Divi è più fedele al modello classico.

Decisione 3: pricing basato su features o su AI credits

Sta emergendo un modello in cui le funzioni AI sono "a consumo" (crediti), mentre le funzioni classiche restano in abbonamento. È un modello più giusto per l'utente (paghi solo quello che usi) ma più complesso da gestire.

Decisione 4: plugin gratuito o premium

La maggior parte dei page builder ha un tier gratuito limitato. La scelta per il 2026 è se ampliare il free tier (per intercettare utenti che userebbero solo AI) o restare premium-only (per monetizzare meglio).

Decisione 5: focus su performance o su funzionalità

Bricks è il campione della performance. Elementor è il campione delle funzionalità. La domanda è: nel 2027, gli utenti premieranno la velocità (Core Web Vitals) o le feature?

Cosa significa per le agenzie

Le agenzie che oggi usano page builder per il 70% del loro lavoro devono riposizionarsi. Tre raccomandazioni concrete.

1. Smetti di vendere "il sito", vendi "il sistema"

Un sito statico fatto con page builder vale sempre meno. Un sistema (sito + automazioni + integrazioni + AI custom) vale di più. Riposiziona la tua offerta su quest'ultimo.

2. Impara l'AI almeno quanto hai imparato il page builder

Se la tua produttività viene dal page builder, sei sostituibile dall'AI. Se la tua produttività viene dalla capacità di combinare AI + page builder + custom code + design thinking, sei molto più difficile da sostituire.

3. Offri "AI setup" come servizio

C'è un mercato enorme di aziende che vogliono usare WPVibe, gli AI Connectors di WP 7.0, o agenti custom, ma non sanno da dove partire. Offrire un servizio di setup + formazione è una nicchia remunerativa e scalabile.

Cosa significa per chi usa page builder

Se sei un utente finale che usa un page builder, ecco i consigli pratici.

Consiglio 1: non stravolgere il tuo workflow

Se oggi usi Elementor e funziona, non passare a Bricks solo perché "è più veloce". Il costo di apprendimento potrebbe non valere. Aspetta che l'integrazione AI maturi.

Consiglio 2: testa le funzioni AI ma non fidarti ciecamente

Quando il tuo page builder aggiunge AI, provala. Ma fai sempre review umana di quello che genera, specialmente per copy e design. L'AI sbaglia ancora, e gli errori sono meno tollerabili su un sito live.

Consiglio 3: mantieni la portabilità del sito

Siti costruiti con page builder proprietari possono essere difficili da migrare. Mantieni backup regolari e una exit strategy. Idealmente, costruisci con page builder che esportano in HTML standard o in blocchi FSE nativi.

Esempio tecnico: integrare l'AI come motore contestuale in un page builder

Vediamo come potrebbe funzionare un'integrazione AI contestuale in un page builder (pseudocodice del flusso di Beaver Builder).

// Sistema di suggerimenti AI contestuali
class ContextAwareAI {
    constructor( pageState, userPreferences ) {
        this.pageState = pageState;
        this.userPreferences = userPreferences;
    }

    async suggestBlockImprovement( block ) {
        // 1. Recupera il contesto della pagina
        const context = {
            page_type: this.pageState.getPageType(),
            surrounding_blocks: this.pageState.getSurroundingBlocks( block.id, 2 ),
            theme_tokens: this.pageState.getThemeDesignTokens(),
            brand_voice: this.userPreferences.getBrandVoice(),
        };

        // 2. Chiedi all'AI con contesto specifico
        const response = await this.callAI( {
            model: 'claude-3-5-sonnet',
            system: `Sei un assistente per page builder. Migliori blocchi esistenti
                    senza stravolgerli. Rispondi in JSON con {"variants": [...]}.`,
            user: `Blocco attuale: ${JSON.stringify( block.data, null, 2 )}
                   Contesto: ${JSON.stringify( context, null, 2 )}
                   Obiettivo utente: ${block.userGoal}`,
        } );

        // 3. Restituisci 3 varianti contestualizzate
        return response.variants.map( v => ({
            ...v,
            blockId: block.id,
            // Mantieni la struttura del blocco, cambia solo contenuto/stile
            preserveStructure: true,
        }) );
    }

    async callAI( payload ) {
        // Usa la WordPress AI API (vedi guida AI Connectors)
        return await wpAiRequest( payload );
    }
}

// Uso nell'editor
const ai = new ContextAwareAI( pageState, userPrefs );
const suggestions = await ai.suggestBlockImprovement( selectedBlock );

// Mostra le varianti inline nel page builder
ui.showInlineVariants( selectedBlock, suggestions );

È un pattern più complesso del "clicca e genera", ma molto più integrato con il workflow dell'utente.

Domande frequenti

I page builder sono morti?

No. Stanno evolvendo. Il page builder come strumento puramente visuale sta cedendo spazio a un modello ibrido dove visuale + AI coesistono. La categoria sopravvive, ma il prodotto singolo deve evolversi.

Meglio imparare un page builder o l'AI oggi?

Entrambi, in ordine di priorità: prima il page builder (perché è ancora il modo più prevedibile di costruire un sito), poi l'AI (per accelerare). Non sono alternativi, sono complementari.

Beaver Builder è indietro rispetto a Elementor sull'AI?

No, è in una posizione diversa. Elementor ha integrato l'AI come feature aggiuntiva (più veloce da implementare, meno profondo). Beaver Builder sta integrando l'AI come cambio di paradigma (più lento, più profondo). I due approcci non sono direttamente confrontabili.

L'AI può sostituire un web designer professionista?

Per task semplici (landing page, siti vetrina, blog personali), sì, oggi. Per task complessi (e-commerce enterprise, portali custom, integrazioni), no, non ancora. La soglia si alza ogni anno, ma la complessità dei progetti reali cresce più velocemente.

Il Full Site Editing di WordPress rende obsoleti i page builder?

No, ma li costringe a specializzarsi. FSE è ottimo per siti piccoli/medi, ma manca di molte feature che i page builder offrono (conditional display, dynamic content, theme builder avanzato). I page builder che si integrano con FSE hanno il futuro assicurato; quelli che lo combattono sono a rischio.

Vale la pena investire in Bricks (performance) o in Elementor (ecosistema)?

Dipende dal tipo di progetti. Per siti dove la performance è critica (publishing, e-commerce ad alto traffico), Bricks è superiore. Per progetti dove servono molte integrazioni e un ecosistema ampio, Elementor vince. La scelta giusta è progetto-specific.

Quando arriverà un page builder veramente AI-native?

Ci sono già prototipi (Bricks AI, Divi AI 2.0, l'approccio Beaver Builder), ma un page builder "AI-native" nel senso pieno del termine (dove l'AI è il motore primario, non un layer sopra) non esiste ancora. Probabile orizzonte: 2027-2028.

Riferimenti utili per approfondire

• WP Tavern #214 con Robby McCullough - il podcast originale.
• Elementor AI 2.0 release notes - esempio di approccio "AI come layer".
• Bricks Builder AI features - esempio di approccio performance-first con AI.
• Divi AI documentation - altro esempio di integrazione AI.
• Beaver Builder roadmap pubblica - visione strategica del team.
• WordPress FSE documentation - come evolve il core.
• Anthropic Computer Use demo - dove sta andando l'AI agentica.
• FSE + AI per temi a blocchi mrtux.it - guida pratica su FSE + AI.
• WordPress 7.0 AI Connectors mrtux.it - il motore AI lato core.
• Strumenti AI per sviluppatori WordPress mrtux.it - la cassetta degli attrezzi AI.

Questa guida verrà aggiornata quando Beaver Builder rilascerà la sua AI contestuale e quando Elementor AI raggiungerà la versione 3.0. Per discussioni o casi d'uso specifici, l'area commenti è aperta.