Negli ultimi mesi ho portato la mia infrastruttura Plesk a un livello che un anno fa avrei considerato fantascienza: più agenti AI specializzati che collaborano tra loro per gestire deploy, monitoring, sicurezza e manutenzione del server. Non un singolo bot che fa tutto, ma un vero team di agenti autonomi, ognuno con il suo ruolo, che si coordinano come una squadra DevOps reale. In questo articolo vi mostro come ho progettato e implementato un sistema multi-agente su un server Plesk Obsidian in produzione.
Se avete già letto il mio articolo su come integrare Agentic Workflows e MCP Protocol su Plesk, considerate questo il passo successivo: passare da un singolo agente a un’architettura multi-agente orchestrata, con governance, sicurezza e workflow DevOps completi. Il mercato degli agenti AI autonomi ha raggiunto gli 8,5 miliardi di dollari nel 2026, e il 40% delle applicazioni enterprise integra già agenti task-specific. È il momento di portare questo paradigma anche sulla nostra infrastruttura di hosting.
Cosa Sono i Multi-Agent Systems e Perché Servono su un Server Plesk
Un Multi-Agent System (MAS) è un’architettura in cui più agenti AI autonomi, ciascuno specializzato in un compito specifico, collaborano per raggiungere obiettivi complessi che nessun singolo agente potrebbe gestire da solo. La differenza rispetto a un workflow con un singolo agente è sostanziale: invece di un unico LLM che cerca di fare tutto, abbiamo agenti dedicati che comunicano tra loro, si scambiano contesto e si coordinano in tempo reale.
Su un server Plesk, questo si traduce in agenti specializzati per:
- Monitoring Agent — analisi continua di metriche, log e anomalie
- Security Agent — scansione vulnerabilità, analisi accessi sospetti, virtual patching
- Deploy Agent — gestione CI/CD, rollback automatici, testing pre-deploy
- Maintenance Agent — backup, pulizia DB, aggiornamenti, certificati SSL
- Orchestrator Agent — coordinamento tra tutti gli agenti, escalation e decisioni
Nella mia esperienza, il vantaggio più grande è la specializzazione: ogni agente ha un contesto ridotto e focalizzato, il che migliora drasticamente la qualità delle decisioni rispetto a un agente generalista che deve gestire tutto.
I Framework per Costruire Sistemi Multi-Agente nel 2026
Nel 2026 il panorama dei framework per multi-agent systems si è consolidato intorno a tre soluzioni principali, ognuna con caratteristiche diverse. Dopo averli testati tutti sul mio server, ecco cosa ho scelto e perché.
CrewAI: Il Mio Framework di Riferimento
CrewAI è il framework che uso quotidianamente. Con oltre 45.900 stelle su GitHub e la versione 1.10.1 rilasciata a marzo 2026, modella gli agenti come un team di lavoro dove ogni membro ha un Role, un Goal e un Backstory. Supporta nativamente il Model Context Protocol (MCP) e il protocollo Agent-to-Agent (A2A), fondamentali per far dialogare gli agenti con i servizi Plesk. Gestisce oltre 12 milioni di esecuzioni giornaliere in produzione a livello globale.
LangGraph: Per Workflow Complessi e Stateful
LangGraph di LangChain è ideale per pipeline stateful con durable execution: se un agente crasha durante un’operazione lunga (come un backup di 20 siti), può riprendere dal punto esatto dell’interruzione. Lo uso per i workflow di disaster recovery dove l’affidabilità è critica. Come ho descritto nel mio articolo su backup e disaster recovery con AI predictions su Plesk, la capacità di ripresa automatica è fondamentale.
Microsoft AutoGen e Semantic Kernel
Il Microsoft Agent Framework combina le astrazioni di AutoGen con le feature enterprise di Semantic Kernel: gestione dello stato basata su sessioni, type safety, middleware e telemetria integrata. Lo consiglio per chi opera in ambienti Azure ibridi, ma sul mio server Debian con Plesk ho trovato CrewAI più immediato e leggero.
Architettura Multi-Agente su Plesk: Il Mio Setup Pratico
Vi mostro l’architettura che ho implementato sul mio server Plesk Obsidian con Debian. L’idea è semplice: un Orchestrator centrale che coordina agenti specializzati, ciascuno con accesso limitato solo alle risorse di cui ha bisogno.
Struttura del Progetto
/opt/mas-plesk/
├── orchestrator/
│ ├── main.py # Entry point orchestratore
│ ├── config.yaml # Configurazione agenti e policy
│ └── escalation_rules.py # Regole di escalation
├── agents/
│ ├── monitoring_agent.py # Agent monitoring risorse
│ ├── security_agent.py # Agent sicurezza e WAF
│ ├── deploy_agent.py # Agent CI/CD e deploy
│ └── maintenance_agent.py # Agent manutenzione
├── tools/
│ ├── plesk_api.py # Wrapper Plesk XML API
│ ├── server_metrics.py # Raccolta metriche sistema
│ └── notification.py # Sistema notifiche
├── shared/
│ ├── memory.py # Memoria condivisa tra agenti
│ └── governance.py # Policy e permessi
└── logs/
└── agent_activity.jsonl # Log strutturato attività
Configurazione dell’Orchestrator con CrewAI
L’Orchestrator è il cervello del sistema. Decide quale agente attivare, gestisce le priorità e implementa le regole di escalation:
# orchestrator/main.py
from crewai import Agent, Task, Crew, Process
from tools.plesk_api import PleskAPITool
from tools.server_metrics import MetricsTool
# Definizione agenti specializzati
monitoring_agent = Agent(
role="Server Monitoring Specialist",
goal="Monitorare risorse, rilevare anomalie e prevenire downtime",
backstory="Esperto di performance Linux con 10 anni di esperienza su Plesk",
tools=[MetricsTool(), PleskAPITool()],
verbose=True,
allow_delegation=True # può delegare ad altri agenti
)
security_agent = Agent(
role="Security Operations Analyst",
goal="Proteggere il server da intrusioni, analizzare log sospetti",
backstory="Analista SOC specializzato in web hosting e WordPress",
tools=[PleskAPITool()],
verbose=True,
allow_delegation=False # decisioni critiche, niente deleghe
)
# Crew con processo gerarchico
server_crew = Crew(
agents=[monitoring_agent, security_agent, deploy_agent, maintenance_agent],
tasks=tasks,
process=Process.hierarchical,
manager_llm="claude-sonnet-4-6", # LLM per l'orchestratore
memory=True # memoria condivisa tra agenti
)
Il parametro Process.hierarchical è fondamentale: l’orchestratore assegna i task dinamicamente in base alla situazione, invece di seguire una sequenza rigida. Uso Claude Sonnet 4.6 come manager LLM per il rapporto costo-prestazioni, ma per gli agenti di security ho configurato modelli più piccoli e specializzati, come descritto nel mio articolo sui modelli AI open source e Small Language Model.
Il Monitoring Agent con Metriche Plesk
L’agente di monitoring è quello che lavora di più. Interroga le API Plesk, analizza i log di sistema e correla le anomalie:
# agents/monitoring_agent.py
import psutil
import subprocess
def check_server_health():
metrics = {
"cpu_percent": psutil.cpu_percent(interval=5),
"memory_percent": psutil.virtual_memory().percent,
"disk_usage": psutil.disk_usage('/').percent,
"load_avg": psutil.getloadavg(),
"active_connections": len(psutil.net_connections()),
}
# Analisi log Apache/Nginx ultimi 15 minuti
error_count = subprocess.run(
["grep", "-c", "error", "/var/log/apache2/error.log"],
capture_output=True, text=True
).stdout.strip()
metrics["recent_errors"] = int(error_count) if error_count else 0
return metrics
Quando il monitoring agent rileva un’anomalia — per esempio CPU sopra l’85% per più di 5 minuti — comunica all’orchestratore, che decide se attivare il maintenance agent per un cleanup o il security agent per verificare che non sia un attacco DDoS.
DevOps Workflow: CI/CD Gestito da Agenti AI
Uno dei workflow più potenti che ho implementato è il deploy automatizzato con validazione multi-agente. Quando pusho codice su un repository Git, il sistema attiva una catena di agenti:
- Deploy Agent — riceve il webhook Git, esegue il pull, crea un ambiente di staging su Plesk
- Security Agent — scansiona il codice per vulnerabilità note (SQL injection, XSS, dipendenze insicure)
- Monitoring Agent — esegue test di carico sullo staging e confronta le metriche con la baseline
- Orchestrator — raccoglie i risultati, decide se procedere con il deploy in produzione o bloccare
# Esempio di task pipeline CI/CD
security_scan = Task(
description="Scansiona il codice deployato per vulnerabilità OWASP Top 10",
agent=security_agent,
expected_output="Report con severity HIGH/MEDIUM/LOW e raccomandazioni"
)
performance_test = Task(
description="Esegui load test e confronta con baseline prestazionale",
agent=monitoring_agent,
expected_output="Confronto metriche: response time, throughput, error rate",
context=[security_scan] # dipende dal risultato della scansione
)
deploy_decision = Task(
description="Valuta i risultati e decidi se procedere con il deploy",
agent=orchestrator_agent,
expected_output="GO/NO-GO con motivazione dettagliata",
context=[security_scan, performance_test]
)
Questo workflow mi ha già salvato due volte: una dependency con una CVE critica è stata bloccata prima del deploy in produzione. Come ho spiegato nel mio articolo sulla protezione WordPress con virtual patching e monitoraggio CVE, automatizzare queste verifiche è fondamentale nel 2026.
Governance e Sicurezza dei Multi-Agent Systems
La governance è la parte più critica — e quella che molti sottovalutano. Nel gennaio 2026, il NIST ha lanciato l’AI Agent Standards Initiative per definire standard di interoperabilità e sicurezza per i sistemi ad agenti. L’EU AI Act entra in piena applicazione ad agosto 2026, e i controlli sugli accessi degli agenti AI sono già sotto scrutinio in audit SOC 2 e GDPR. Se gestite dati europei su Plesk, questo vi riguarda direttamente.
Principio del Minimo Privilegio per Agenti AI
Ogni agente deve avere accesso solo alle risorse necessarie per il suo compito. Nel mio setup:
- Monitoring Agent — accesso read-only a metriche e log, nessun permesso di scrittura
- Security Agent — può leggere log e configurazioni, può bloccare IP via firewall, non può modificare siti
- Deploy Agent — accesso ai repository Git e allo staging, richiede approvazione per il production deploy
- Maintenance Agent — può eseguire backup e pulizia, non può cancellare siti o database
# shared/governance.py
AGENT_PERMISSIONS = {
"monitoring": {
"allowed_actions": ["read_metrics", "read_logs", "send_alert"],
"denied_actions": ["modify_config", "delete_files", "restart_service"],
"requires_approval": []
},
"security": {
"allowed_actions": ["read_logs", "block_ip", "scan_files"],
"denied_actions": ["modify_site", "delete_database"],
"requires_approval": ["modify_firewall_rules"]
},
"deploy": {
"allowed_actions": ["git_pull", "create_staging", "run_tests"],
"denied_actions": ["delete_production"],
"requires_approval": ["deploy_production", "rollback_production"]
}
}
Ho approfondito la governance degli AI agents in azienda in un articolo dedicato, ma il concetto chiave è trattare ogni agente come un’identità di primo livello, con lo stesso rigore che applichereste a un utente umano.
Human-in-the-Loop: Quando l’Agente Si Ferma
Non tutto deve essere automatico. Ho configurato regole di escalation precise:
- Basso rischio (pulizia log, ottimizzazione cache) → esecuzione autonoma con report
- Medio rischio (aggiornamento plugin, modifica configurazione) → notifica prima dell’esecuzione, timeout 30 minuti per il veto
- Alto rischio (deploy produzione, modifica firewall, rollback) → approvazione esplicita via Telegram/email
- Critico (cancellazione dati, modifica DNS) → doppia approvazione obbligatoria
Il profilo Agentic AI Risk Management pubblicato da UC Berkeley nel febbraio 2026 raccomanda esattamente questo approccio: l’autonomia deve essere proporzionale al rischio dell’azione. Nel mio sistema, l’orchestratore valuta il rischio di ogni azione prima di autorizzarla.
Monitoring e Observability del Sistema Multi-Agente
Un aspetto che ho imparato a mie spese: monitorare gli agenti è tanto importante quanto monitorare il server. All’inizio non avevo un sistema di observability dedicato e mi sono trovato con un agente che generava loop infiniti di check senza che me ne accorgessi.
Log Strutturato delle Attività
Ogni azione degli agenti viene registrata in formato JSONL, con timestamp, agente, azione, risultato e tempo di esecuzione:
{"timestamp": "2026-03-18T14:23:01Z", "agent": "monitoring",
"action": "check_server_health", "result": "ok",
"duration_ms": 1250, "details": {"cpu": 34, "memory": 67}}
{"timestamp": "2026-03-18T14:23:45Z", "agent": "security",
"action": "block_ip", "result": "executed",
"duration_ms": 89, "details": {"ip": "192.168.x.x", "reason": "brute_force"}}
Questo log è essenziale per il troubleshooting ma anche per la compliance — come ho spiegato nel mio articolo sulla conformità NIS2 su Plesk, il logging delle attività automatizzate è un requisito normativo.
Dashboard e Alerting
Ho configurato un sistema di alerting a tre livelli: anomalie del server rilevate dagli agenti, anomalie degli agenti stessi (consumo risorse eccessivo, latenza nelle risposte, errori ripetuti) e conflitti tra agenti (due agenti che cercano di modificare la stessa risorsa contemporaneamente). L’orchestratore ha un meccanismo di circuit breaker: se un agente fallisce più di 3 volte consecutive, viene disattivato e ricevo una notifica immediata.
Ottimizzazione dei Costi: Modelli AI Giusti per Ogni Agente
Uno degli errori iniziali che ho commesso è stato usare lo stesso modello AI per tutti gli agenti. Il monitoring agent che gira ogni 5 minuti non ha bisogno di GPT-5.4 — un modello piccolo va più che bene. Ecco la mia configurazione attuale:
- Orchestrator — Claude Sonnet 4.6 (bilanciamento costo/qualità per decisioni complesse)
- Monitoring Agent — Granite 4.0 locale via Ollama (zero costi API, bassa latenza)
- Security Agent — Claude Haiku 4.5 (veloce e preciso per pattern matching)
- Deploy Agent — DeepSeek V4 (eccellente per analisi codice, costo contenuto)
- Maintenance Agent — Granite 4.0 locale via Ollama (task ripetitivi e prevedibili)
Con questa configurazione a modelli misti, ho ridotto i costi API del 70% rispetto all’uso di un unico modello premium per tutto. Ne ho parlato anche nell’articolo su come scegliere modelli AI open source nel 2026: i Small Language Model sono perfetti per task specializzati e ripetitivi.
Integrazione con le API Plesk e gli Strumenti Esistenti
La chiave per far funzionare tutto è l’integrazione nativa con l’ecosistema Plesk. Gli agenti comunicano con il server attraverso:
- Plesk XML API — per gestire domini, database, certificati SSL e configurazioni
- Plesk CLI (plesk bin) — per operazioni di basso livello e automazione
- WP-CLI — per gestire le installazioni WordPress (aggiornamenti, manutenzione DB)
- Webhook Git — per trigger automatici di deploy
- MCP Server — come bridge tra gli agenti e i servizi del server
Il Plesk Copilot extension promesso per il 2026 semplificherà ulteriormente questa integrazione, ma nel frattempo il wrapper sulle API XML funziona egregiamente. Se state pensando di configurare un server Plesk Obsidian da zero, vi consiglio di pianificare fin dall’inizio lo spazio per gli agenti AI.
Lezioni Apprese e Best Practices
Dopo mesi di utilizzo in produzione, ecco le lezioni più importanti che ho imparato:
- Partite con un solo agente — Non cercate di implementare tutto insieme. Iniziate con il monitoring agent, stabilizzatelo, poi aggiungete gli altri gradualmente.
- La memoria condivisa è cruciale — Senza un database vettoriale condiviso, gli agenti prendono decisioni contrastanti. Io uso Redis con il modulo di vector search.
- Testate i failure mode — Cosa succede se l’orchestratore va down? Se la connessione API cade? Ogni scenario deve avere un fallback.
- Limitate i loop — Impostate sempre un max_iterations per ogni task. Un agente senza limiti può consumare risorse e budget API in modo incontrollato.
- Versionamento delle policy — Le regole di governance devono essere in version control, non hardcodate. Quando cambiate una policy, dovete poter fare rollback.
FAQ
Quante risorse consuma un sistema multi-agente su un server Plesk?
Dipende dalla configurazione, ma nel mio caso l’intero sistema multi-agente consuma circa 1-2 GB di RAM e il 5-10% di CPU in condizioni normali. Gli agenti che usano modelli locali via Ollama richiedono più risorse (4-8 GB di RAM aggiuntivi). Per un server con almeno 16 GB di RAM e 4 core, il sistema funziona senza problemi accanto ai normali carichi di hosting.
È possibile usare Multi-Agent Systems senza API key a pagamento?
Sì, è possibile usare esclusivamente modelli open source locali tramite Ollama (Granite 4.0, DeepSeek, Llama). Le prestazioni saranno inferiori per compiti complessi come l’analisi di sicurezza, ma per monitoring e manutenzione di routine i modelli locali funzionano bene. Un approccio ibrido con modelli locali per i task frequenti e API per le decisioni critiche è il compromesso migliore.
Come gestisco i conflitti quando due agenti vogliono agire sulla stessa risorsa?
L’orchestratore implementa un meccanismo di resource locking: quando un agente inizia un’operazione su una risorsa (un sito, un database, il firewall), acquisisce un lock che impedisce agli altri agenti di intervenire finché non ha terminato. In caso di conflitto, l’orchestratore applica una gerarchia di priorità: security > monitoring > maintenance > deploy. In casi ambigui, il sistema richiede l’intervento umano.
Qual è la differenza rispetto a un singolo agente AI per la gestione server?
Un singolo agente deve avere un contesto enorme che copre sicurezza, performance, deploy e manutenzione, il che aumenta errori e allucinazioni. Con agenti specializzati, ognuno ha un contesto ridotto e focalizzato, risultando più preciso e veloce. Inoltre, gli agenti possono lavorare in parallelo: il security agent scansiona mentre il monitoring agent analizza le metriche, riducendo i tempi di risposta complessivi.
Il sistema multi-agente è compatibile con la NIS2 e il GDPR?
Sì, a patto di implementare correttamente il logging strutturato, il principio del minimo privilegio e le regole di escalation human-in-the-loop. Ogni azione degli agenti deve essere tracciata con timestamp, agente responsabile e risultato. L’EU AI Act in vigore da agosto 2026 richiede inoltre che i sistemi ad agenti abbiano meccanismi di supervisione umana proporzionali al livello di rischio, esattamente come il modello a quattro livelli che ho descritto sopra.
Conclusione
I Multi-Agent AI Systems rappresentano l’evoluzione naturale dell’automazione server nel 2026. Passare da un singolo agente a un team di agenti specializzati ha trasformato il modo in cui gestisco il mio server Plesk: meno interventi manuali, risposte più rapide agli incidenti, deploy più sicuri e una governance strutturata che soddisfa i requisiti normativi.
Il consiglio più importante che posso darvi è iniziare in piccolo: un monitoring agent con CrewAI, un paio di tool per le API Plesk, e un sistema di logging. Da lì, aggiungete agenti man mano che identificate esigenze concrete. La tentazione di costruire tutto subito è forte, ma l’affidabilità si costruisce un agente alla volta. Se volete approfondire come ho implementato l’Agentic AI in produzione, trovate tutti i dettagli nel mio articolo dedicato. Vi invito a condividere la vostra esperienza nei commenti: avete già testato sistemi multi-agente sulla vostra infrastruttura?