8 agenti, 21 skill, 15 job schedulati, sembra un sistema L3. Ma la domanda giusta non è "quanti componenti hai", è "come interagiscono". Questo articolo analizza dove si posiziona OpenClaw nella scala di autonomia agentica, cosa offre già out-of-the-box, e cosa serve costruire sopra per passare da L2 a L3.
Cos'è OpenClaw e perché parte già da L2?
OpenClaw è un framework Node.js open-source per agenti AI persistenti. LangChain, CrewAI e AutoGen orchestrano catene LLM come script one-shot. OpenClaw costruisce agenti always-on con identità separate, ciascuno con il proprio workspace, le proprie sessioni, i propri canali di comunicazione.
Out-of-the-box, il framework include un gateway che ospita N agenti come processi embedded, ognuno con workspace isolato e auth profile proprio. Ogni agente ha un sistema di skill con router e routing table che mappa input a workflow. I job schedulati usano sintassi cron standard e girano in sessioni isolate. La memory è persistente tra sessioni. I connettori coprono Telegram, WhatsApp e webchat. Playwright è integrato per l'automazione browser.
Questo non è L1. Un chatbot che risponde a domande è L1. Un sistema con agenti multipli, skill routing, esecuzione schedulata e memoria è già L2, semi-autonomo, secondo i framework NVIDIA e Sema4.ai.
L2 significa che l'agente prende decisioni a punti predeterminati in un flusso. Ha gli strumenti, sa usarli, ma li attiva a trigger fissi. Un cron job che esegue una skill alle 08:00 è L2. Decide cosa fare dentro la skill, ma non quando o se eseguirla in risposta a condizioni dinamiche.
Cosa distingue L3 da L2 secondo i framework di riferimento?
Tre framework indipendenti convergono su una scala a 4-5 livelli: NVIDIA, Sema4.ai e Dextra Labs.
| Livello | Nome | Comportamento | Discriminante architetturale |
|---|---|---|---|
| L1 | Assistente | Risponde a comandi singoli, nessuna pianificazione, stateless | Nessun loop. Input/output singolo |
| L2 | Semi-autonomo | Decide a punti fissi in un flusso predefinito, branching limitato | Grafo aciclico (DAG). Nessun ciclo di feedback |
| L3 | Autonomia condizionata | Pianifica, esegue, riflette, corregge. Sceglie strumenti liberamente | Cicli di esecuzione. L'agente può tornare indietro, ripianificare, riprovare |
La differenza chiave: a L2 i percorsi decisionali sono enumerabili (un DAG). A L3 compaiono cicli. L'agente può rifiutare un output, tornare a una fase precedente, riprovare con parametri diversi. NVIDIA definisce L3 così: il modello AI decide liberamente se, quando e come invocare strumenti, e può rivedere il proprio piano durante l'esecuzione.
Il discriminante tecnico non è il numero di agenti o skill. È la topologia del flusso. Se il grafo di esecuzione contiene loop, sei a L3. Se è lineare o ramificato senza cicli, sei a L2.
Qual è il gap tra OpenClaw L2 e un sistema L3?
OpenClaw OOB fornisce i mattoni. Mancano tre layer per chiudere il gap verso L3.
| Capacità | OpenClaw OOB (L2) | Cosa serve per L3 |
|---|---|---|
| Esecuzione skill | Trigger fisso (cron o comando utente) | Orchestrazione dinamica: un agente sceglie quale skill invocare in base allo stato del task |
| Flusso di esecuzione | Lineare (DAG): trigger → skill → output | Ciclico: trigger → skill chain → review gate → feedback loop → retry/advance |
| Knowledge loading | Tutto il contesto caricato in ogni chiamata | Selettivo: resolver che assembla solo i moduli necessari per il workflow specifico |
| Cross-skill coordination | Ogni skill è indipendente | Pipeline multi-fase: lo stato passa tra skill via file JSON condiviso |
| Self-maintenance | Manuale: editing skill = rischio di rompere dipendenze | Automatica: dependency map, validation script, auto-reindex knowledge base |
| Knowledge base | Memory testuale dell'agente | RAG vettoriale: embedding + ricerca semantica su tutti i workflow e procedure |
Layer 1: Orchestrazione con feedback loop
Il salto architetturale da L2 a L3 è la pipeline orchestrata. Un agente-orchestratore coordina N skill specializzate in sequenza, passando lo stato tramite file JSON condiviso. Ogni skill legge lo stato attuale, esegue il suo compito, scrive il risultato.
Il Reviewer funziona da review gate. Può bloccare la pubblicazione e rimandare il contenuto a una fase precedente. Questo ciclo di feedback è la caratteristica architetturale che rende il flusso non-DAG e quindi L3.
Ogni transizione è una decisione dinamica. L'orchestratore seleziona il workflow corretto leggendo il tipo di task dallo stato. Il Copywriter sceglie tra modalità diverse in base allo scheduling. Il Publisher decide se usare API o browser automation in base alla piattaforma di destinazione.
Layer 2: Knowledge management selettivo
L'approccio standard ai sistemi multi-agente è caricare tutto il contesto in ogni chiamata: tutte le procedure operative, tutti i riferimenti API, tutte le configurazioni. Con 8+ agenti e 20+ workflow, questo significa 25-35K token di contesto per ogni singola chiamata, in gran parte irrilevante per il task specifico.
La soluzione: un resolver che assembla il contesto on-demand. Ogni workflow dichiara esplicitamente le sue dipendenze tramite marker (READ modulo-x). Quando l'agente esegue un workflow, il resolver trova tutti i marker, li risolve inlining solo i moduli referenziati, e produce un documento autonomo e completo. L'agente riceve 3-8K token di contesto chirurgico invece di 30K+ di contesto generico.
A questo si aggiunge una knowledge base vettoriale (RAG): tutti i workflow e le procedure vengono indicizzati con embedding semantici. Quando un agente ha bisogno di informazioni non coperte dal workflow corrente, può cercare semanticamente nella base di conoscenza senza caricare tutto in contesto.
Layer 3: Self-maintenance
Un sistema L3 che richiede intervento umano per la manutenzione ordinaria non è veramente L3. Due meccanismi chiudono il gap.
Uno script genera un grafo di dipendenze completo che mappa quali workflow usano quali moduli condivisi e quali skill invocano quali altre skill. Prima di modificare un modulo condiviso, il grafo mostra esattamente chi ne dipende. Un secondo script di validazione verifica che ogni riferimento punti a un file reale e che ogni entry nella routing table sia valida.
Sul fronte del reindex, un servizio monitora la directory dei workflow. Quando un file cambia, dopo debounce indicizza il contenuto aggiornato nella knowledge base vettoriale e rigenera il grafo delle dipendenze. Gli agenti lavorano sempre su informazioni aggiornate senza intervento manuale.
Quali sono i numeri di performance del passaggio L2 → L3?
Non abbiamo benchmark formali su dataset standardizzati. Quelle che seguono sono stime basate sul confronto tra l'approccio standard (pre-ottimizzazione) e la configurazione attuale, misurate sulle operazioni reali del sistema.
| Metrica | Approccio standard (context dump) | Configurazione L3 (skill resolution) | Delta |
|---|---|---|---|
| Token per chiamata agente | 25-35K (tutto il contesto caricato) | 3-8K (solo moduli necessari) | -75/80% |
| Tempo di risposta medio | 12-18s (contesto lungo = inferenza lenta) | 4-8s (contesto corto = inferenza veloce) | -55/60% |
| Precisione procedurale | ~70% (l'agente ignora parti del contesto rumoroso) | ~92% (contesto chirurgico = meno errori) | +22pp |
| Intervento umano per errori | 3-5 volte/giorno (step saltati o mal interpretati) | 0-1 volta/giorno (procedure seguite con precisione) | -80% |
| Manutenzione sistema | Manuale: ogni modifica richiede verifica a mano | Automatica: validation + auto-reindex | ~0h/settimana vs ~2h |
Come si spiega il miglioramento di precisione?
Il problema del context dump è la diluizione dell'attenzione. Quando un agente riceve 30K token di contesto misto (procedure per 8 piattaforme diverse, API reference che non servono per il task corrente, configurazioni di altri agenti), il modello deve decidere cosa è rilevante. Con i modelli attuali questo funziona "quasi sempre", ma quel 30% di errori si concentra sui dettagli procedurali: step saltati, parametri confusi tra piattaforme, formati sbagliati.
Con il contesto selettivo, l'agente riceve solo la procedura per la piattaforma specifica e i riferimenti API che servono per quel workflow. Non c'è nulla da ignorare. La precisione sale perché il problema diventa più semplice per il modello, non perché il modello è più bravo.
Queste stime sono basate su osservazione operativa, non su benchmark controllati. I numeri variano in base alla complessità del workflow, al modello usato, e al volume di contesto. Il pattern (meno contesto = più precisione) è robusto, ma i numeri esatti sono indicativi.
Come si spiega il risparmio di token?
L'aritmetica è diretta. Un sistema con 9 moduli condivisi (configurazione piattaforme, API reference, pattern di stato, procedure operative) totalizza ~18-20K token. Una singola chiamata standard carica tutto. Con il resolver, un workflow medio referenzia 2-3 moduli per ~2-4K token, più il workflow stesso (~1-3K). Il risparmio scala linearmente con il numero di chiamate: su 50-80 chiamate/giorno il delta è di ~1-2M token/giorno.
Come si replica questa architettura?
Tre principi guidano il design. Sono applicabili a qualsiasi framework multi-agente, non solo OpenClaw.
Principio 1: Separare orchestrazione da esecuzione
L'orchestratore non esegue nulla, coordina. Ogni fase è delegata a una skill specializzata con il suo routing, i suoi workflow, le sue dipendenze. L'orchestratore passa un identificatore di task e ogni skill legge/scrive il proprio pezzo di stato in un file JSON condiviso.
Principio 2: Stato esplicito, mai implicito
Ogni task ha un file JSON con struttura completa: tipo, piattaforme target, fasi completate, output intermedi. Ogni skill legge lo stato attuale, aggiorna solo i campi di sua competenza (pattern read-modify-write), e scrive il risultato. Nessuna informazione passa "in memoria" tra un agente e l'altro. Tutto è su disco, ispezionabile, debuggabile.
Principio 3: Guardrail architetturali, non solo prompt
I confini dell'autonomia non sono nelle system prompt. Sono nella struttura: routing table che limita quali workflow un agente può eseguire, review gate che blocca la pubblicazione senza approvazione, procedure operative per piattaforma che definiscono regole non negoziabili (lunghezza testo, formato, orari di pubblicazione). L'agente ha libertà dentro questi confini. Non può uscirne per design, non per istruzione.
Qual è il prossimo step verso L4?
L3 è autonomia condizionata. L4, secondo Sema4.ai, è self-refinement, dove il sistema migliora i propri strumenti, crea nuove skill, modifica le proprie procedure in base ai risultati osservati.
Alcuni elementi sono già presenti in embrione: un report settimanale analizza i risultati dei contenuti pubblicati e identifica pattern: quali formati performano meglio, quali orari generano più engagement. Il passo concreto verso L4: fare in modo che quei pattern aggiornino automaticamente le procedure operative e i parametri di scheduling. Quando il sistema non solo esegue ma migliora le proprie regole basandosi sui dati, il confine tra L3 e L4 inizia a sfumare.
Cosa ottieni iscrivendoti:
- Accesso a tutti gli episodi della newsletter
- Guide e corsi completi sull'AI per marketer
- Strumenti AI professionali (BrandPix, Short Video Suite)
- Crediti gratuiti per iniziare subito