web analytics

Stack AI agent WordPress self-hosted 2026: guida completa

18/08/2026

Contenuto articolo

Stack AI agent WordPress self-hosted 2026: l'alternativa al lock-in gestito

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

Voce di costoPre-stack (WordPress.com MCP)Post-stack self-hosted

MCP subscription/mese — 870€ — 0€

VPS Hetzner/mese — 0€ — 35€

Backup S3/mese — 0€ — 5€

GPU LLM (RunPod on-demand)/mese — 0€ — 120€

DevOps contractor (1g setup, 1g/mese maintenance) — 0€ — 1.100€

Totale anno 1 — 10.440€ — 15.210€ (anno 1, include setup)

Totale anno 2+ — 10.440€ — 15.120€ (run cost)

Saving anno 2 — baseline — -4.680€ (manca il break-even)

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

Autore articolo: Emilio Petrozzi

🌐 Creazione siti web dinamici e di commercio elettronico 🛍 assistenza WordPress 🌐 Con oltre 20 anni di esperienza nel settore, esperto nella realizzazione di soluzioni digitali personalizzate per il tuo business. 🚀

🔧 Offro assistenza WordPress completa, garantendo che il tuo sito sia sempre aggiornato e funzionante al meglio. 📈 Inoltre mi occupo dell'ottimizzazione per motori di ricerca (SEO), assicurando che il tuo sito sia sempre facilmente rintracciabile dai tuoi clienti. 💻

📢 Le mie campagne pubblicitarie web sono progettate per aumentare la visibilità del tuo brand e generare traffico di qualità verso il tuo sito. 🔒 Inoltre la sicurezza informatica è una priorità in modo tale da garantire i tuoi dati e quelli dei tuoi clienti.

🤝 Affidati a mrtux.it per un servizio professionale e di qualità, e porta il tuo business al successo nel mondo digitale! 🎯

🔑 #CreazioneSitiWeb #Ecommerce #AssistenzaWordPress #OttimizzazioneSEO #SicurezzaInformatica

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *


Aricoli correlati

Emilio Petrozzi  P. I.V.A. IT03080230604 - Professionista ai sensi della Legge 4/2013