I 5 pattern agentici di Claude Code che nessuno ti ha spiegato

I 5 pattern agentici di Claude Code che nessuno ti ha spiegato

Se usi Claude Code solo per "scrivi questo file" o "risolvi questo bug", stai usando un Ferrari per andare al supermercato. Claude Code supporta cinque pattern architetturali per orchestrare agenti in modo strutturato — e la scelta del pattern giusto determina se il tuo workflow scala o collassa.

Questa guida li spiega tutti e cinque con una decision table pratica e scenari reali.

---

Cosa sono i pattern agentici (e perché contano)

Un pattern agentico è un modo di strutturare come Claude coordina il lavoro: se procede passo dopo passo, delega a sotto-agenti, esegue in parallelo o gira in autonomia completa senza che tu sia presente.

Scegliere il pattern sbagliato ha conseguenze concrete:

• un workflow Sequential applicato a task indipendenti spreca tempo
• un workflow Agent Teams usato per task semplici introduce complessità inutile
• un workflow Headless senza guardrail adeguati produce output incontrollabili

Il principio base: usa il pattern più semplice che risolve il problema.

---

Pattern 1 — Sequential: uno step alla volta

Come funziona: Claude esegue i task in sequenza lineare. L'output di ogni step diventa l'input del successivo. Struttura:

Task A → Task B → Task C → Output finale

Quando usarlo:

• Il task successivo dipende dall'output del precedente
• Il flusso è prevedibile e lineare
• Non hai bisogno di parallelismo

Caso reale italiano: Stai costruendo un report settimanale per un cliente. Il workflow è: scrape dei dati → analisi → formattazione → invio email. Ogni step dipende dal precedente: non puoi formattare prima di analizzare, non puoi inviare prima di formattare. Limite principale: È lento. Se i task sono indipendenti tra loro, stai aspettando inutilmente.

---

Pattern 2 — Operator: un orchestratore, più sotto-agenti

Come funziona: Un agente "operatore" riceve il task principale, lo scompone, delega le parti ai sotto-agenti e sintetizza i risultati. Struttura:

Operatore (orchestratore)
├── Sotto-agente A
├── Sotto-agente B
└── Sotto-agente C → Sintesi finale

Quando usarlo:

• Il task supera la finestra di contesto di un singolo agente
• Hai bisogno di specializzazione: un agente per la ricerca, uno per la scrittura, uno per la revisione
• Vuoi separare la logica di orchestrazione dalla logica di esecuzione

Caso reale italiano: Stai sviluppando un'analisi competitiva per una startup italiana nel fintech. L'operatore coordina: un agente che analizza i competitor, uno che studia la normativa PSD2, uno che esamina il mercato italiano. L'operatore sintetizza tutto in un documento coerente. Limite principale: Richiede una progettazione attenta del contratto tra operatore e sotto-agenti. Se le istruzioni sono ambigue, il risultato è incoerente.

---

Pattern 3 — Split-and-Merge: parallelismo controllato

Come funziona: Un task grande viene suddiviso in sotto-task indipendenti, eseguiti in parallelo, poi i risultati vengono uniti. Struttura:

Task principale
├── Sotto-task 1 ─┐
├── Sotto-task 2 ─┤→ Merge → Output finale
└── Sotto-task 3 ─┘

Quando usarlo:

• Hai un volume elevato di task simili e indipendenti
• Vuoi ridurre il tempo totale di esecuzione
• I sotto-task non dipendono l'uno dall'altro

Caso reale italiano: Hai 50 descrizioni prodotto da tradurre e ottimizzare per SEO per un e-commerce italiano. Invece di processarle una alla volta (Sequential), le dividi in batch e le processi in parallelo. Il tempo si riduce drasticamente. Differenza chiave da Operator: nello Split-and-Merge i sotto-agenti fanno la stessa cosa su dati diversi. Nell'Operator fanno cose diverse sullo stesso problema. Limite principale: Non funziona quando i sotto-task si influenzano a vicenda (es. stai scrivendo capitoli di un libro: il tono del capitolo 3 dipende dal capitolo 2).

---

Pattern 4 — Agent Teams: specializzazione per progetti complessi

Come funziona: Un team di agenti specializzati collabora in modo sostenuto su un progetto complesso, con ruoli definiti e memoria condivisa. Struttura:

Progetto complesso
├── Agente Ricercatore
├── Agente Sviluppatore
├── Agente Revisore
└── Agente Project Manager (coordinamento)

Quando usarlo:

• Il progetto è multi-dominio e richiede expertise diverse
• Il lavoro dura più sessioni (memoria persistente richiesta)
• Hai bisogno di specializzazione profonda, non solo divisione del lavoro

Caso reale italiano: Stai costruendo una piattaforma SaaS per la gestione delle fatture elettroniche italiane (SDI). Il progetto richiede: un agente esperto delle specifiche XML FatturaPA, uno per il backend Python/FastAPI, uno per il frontend React, uno per la compliance fiscale italiana. Lavorano insieme per settimane. Limite principale: È il pattern più complesso da progettare e mantenere. Richiede un sistema robusto di coordinamento e gestione degli stati. Non usarlo per task che durano ore, non settimane.

---

Pattern 5 — Headless: autonomia totale

Come funziona: Claude opera in background, senza interazione umana, attivato da trigger automatici (schedulati, eventi, webhook). Struttura:

Trigger (orario / evento / webhook)
→ Claude Headless
→ Azione (file, API, notifica)
→ Log

Quando usarlo:

• Il task è ben definito e ripetibile
• Hai guardrail chiari (cosa può e non può fare l'agente)
• Vuoi il massimo livello di automazione
• L'errore è recuperabile (nessuna azione irreversibile senza supervisione)

Caso reale italiano: Ogni mattina alle 7, un agente headless legge le news dal Sole 24 Ore e da MF, identifica gli articoli rilevanti per il settore bancario, produce un digest in italiano e lo invia via email al team. Zero intervento umano. Limite principale: È il pattern con il rischio più alto. Senza guardrail adeguati, un agente headless può fare cose che non volevi. Regola pratica: inizia sempre con un "dry run" (log senza azioni reali) prima di abilitare le azioni effettive.

---

Decision Table: quale pattern usare

Scenario	Pattern consigliato
Task lineari con dipendenze sequenziali	Sequential
Task che supera la finestra di contesto	Operator
Molti task simili e indipendenti	Split-and-Merge
Progetto multi-dominio, lunga durata	Agent Teams
Automazione ricorrente senza supervisione	Headless
Non sai da dove iniziare	Sequential (poi ottimizza)

Regola d'oro: i pattern si combinano. Un workflow Headless che usa un Operator per orchestrare agenti Split-and-Merge è perfettamente legittimo — e spesso è la soluzione a problemi reali complessi.

---

Come scegliere nella pratica: 3 domande

1. I task dipendono l'uno dall'altro?

• Sì, in sequenza → Sequential
• Sì, ma diversi specialisti → Operator
• No → Split-and-Merge

2. Il progetto dura più di una sessione?

• Sì, con ruoli distinti → Agent Teams
• No → uno dei tre sopra

3. L'esecuzione deve essere automatica?

• Sì, con trigger e nessun intervento umano → Headless (wrapper su qualsiasi pattern)

---

Errori comuni da evitare

Sovra-ingegnerizzare: non usare Agent Teams per task che si completano in 20 minuti. Il 70% dei casi reali si risolve con Sequential o Operator. Headless senza dry run: prima di abilitare azioni reali, fai sempre girare il workflow in modalità log-only per verificare che l'agente faccia esattamente quello che vuoi. Split-and-Merge su task dipendenti: se stai scrivendo un documento coerente, i capitoli si influenzano a vicenda. Usare Split-and-Merge produce testo frammentato e incoerente. Operatori senza contratto chiaro: l'operatore deve sapere esattamente cosa può delegare e cosa no. Istruzioni ambigue producono sotto-agenti che "interpretano" in modo creativo — raramente nel senso che volevi.

---

Conclusione

I cinque pattern agentici di Claude Code non sono tecnologia futura: sono disponibili oggi e risolvono problemi reali. La differenza tra chi ottiene risultati concreti e chi resta bloccato non è la complessità del setup — è la chiarezza nella scelta del pattern giusto per il task giusto.

Inizia da Sequential. Aggiungi complessità solo quando il pattern più semplice mostra i suoi limiti.