Prompt chaining: workflow multi-step affidabili 2026

Il prompt chaining è la tecnica con cui spezziamo un task complesso in step più piccoli, ognuno gestito da un prompt dedicato, con il risultato di uno step che alimenta il successivo. È il pattern operativo che separa workflow giocattolo da workflow production-grade nel 2026. Tradotto: invece di chiedere a un singolo prompt monolitico di “analizzare un contratto e segnalare clausole problematiche”, spezziamo in estrazione clausole → classificazione rischio → generazione report. Ogni step è testabile, ottimizzabile, sostituibile individualmente.

Single-shot vs prompt chain: la differenza che conta

Un prompt single-shot tenta di risolvere un task complesso in una sola chiamata API. Un prompt chain spezza il task in N chiamate sequenziali coordinate. La differenza non è solo tecnica: è di affidabilità in produzione.

I benchmark pubblicati su task multi-step complessi mostrano gap consistenti. Su task con 3-5 passaggi logici, la qualità output di un prompt chain è 35-55% superiore rispetto allo stesso task in single-shot (Wei et al., Chain-of-Thought Prompting Elicits Reasoning, NeurIPS 2022, aggiornato con benchmark 2025).

Le ragioni operative del gap:

Attention dilution: in single-shot il modello deve “tenere a mente” tutto il task, perdendo focus
Error compounding: errori intermedi propagano nel single-shot, mentre nel chain si possono isolare
Debuggability: con il chain vediamo esattamente dove va male, in single-shot è black box
Cost optimization: step più semplici si possono risolvere con modelli più piccoli (gpt-4o-mini, claude-haiku) abbattendo il costo

Pattern 1 — Sequential chain

Il pattern più semplice. N step in sequenza, output di N alimenta N+1.

STEP 1 — Estrazione clausole
Input: documento contratto
Output: lista clausole strutturate con {testo, posizione, tipo}

STEP 2 — Classificazione rischio
Input: lista clausole da step 1
Output: clausole arricchite con {rischio: basso/medio/alto, motivazione}

STEP 3 — Generazione report
Input: clausole classificate da step 2 + metadati contratto
Output: report markdown strutturato con executive summary, criticità, raccomandazioni

Quando funziona: workflow lineari dove ogni step ha un output ben definito che alimenta il successivo. Failure mode tipico: errore in uno step propaga senza recovery automatico.

Pattern 2 — Branching chain

Il flow si biforca in base a una decisione condizionale presa da un LLM-router.

STEP 1 — Router
Input: documento da analizzare
Output: classificazione tipo {contratto, fattura, email, altro}

BRANCH:
  if contratto → chain analisi contratto (3 step)
  if fattura → chain estrazione fattura (2 step)
  if email → chain triage email (1 step)
  if altro → fallback umano

Quando funziona: pipeline che processa input eterogenei. Critico avere fallback per casi non classificati: l’LLM-router può sbagliare e finire in branch errato. Per applicazioni B2C il branching richiede telemetria attenta perché silent failures degradano la user experience.

Lo stesso step viene ripetuto N volte fino a soddisfare un criterio di accettazione, raffinando l’output ad ogni iterazione.

STEP 1 — Genera bozza
Output: prima bozza testo

STEP 2 — Critica
Input: bozza step 1
Output: lista feedback miglioramento

STEP 3 — Revisiona
Input: bozza + feedback
Output: bozza revisionata

LOOP: ripeti step 2-3 fino a criterio (max 3 iterazioni o quality_score > 8.5/10)

Quando funziona: task creativi (scrittura, content generation) dove la qualità iniziale è insufficiente. Attenzione al costo: ogni iterazione raddoppia consumo token. Limit massimo di iterazioni è obbligatorio per evitare runaway loops.

Il paper di riferimento storico è ReAct (Yao et al., ReAct: Synergizing Reasoning and Acting, ICLR 2023), oggi consolidato come pattern standard per agenti che alternano reasoning e action.

State management tra step

Quando il chain ha più di 3-4 step, gestire lo stato condiviso diventa complesso. Tre approcci dominanti nel 2026:

Approccio 1 — Stato implicito nei prompt. L’output completo di ogni step viene passato come parte del prompt allo step successivo. Semplice ma costoso (token sprecati ripetendo informazioni) e fragile (LLM può perdere info importante nel verbose).

Approccio 2 — Stato esplicito strutturato. Un oggetto stato (JSON) viene aggiornato ad ogni step. Solo i campi rilevanti vengono passati come contesto al prompt successivo. È il pattern usato da LangChain LCEL e dust.tt nei loro flow graph.

Approccio 3 — Stato in storage esterno. Per chain lunghi (>10 step) o agenti che operano su orizzonti temporali estesi, lo stato vive in storage esterno (Redis, Postgres). Ogni step legge/scrive lo stato. Permette resume di chain interrotti e auditability completa.

Code block: esempio completo workflow analisi contratto

# Pseudo-codice flow analisi contratto in 4 step

from langchain.prompts import PromptTemplate
from langchain.schema.runnable import RunnableLambda

# Step 1: Estrazione clausole
estrai_clausole_prompt = PromptTemplate.from_template("""
Sei un analista contrattuale. Estrai dal seguente contratto tutte le clausole 
in formato JSON strutturato.

CONTRATTO:
{contratto_text}

OUTPUT JSON:
[
  {{"id": int, "tipo": str, "testo": str, "posizione_pagina": int}}
]
""")

# Step 2: Classificazione rischio per ogni clausola
classifica_rischio_prompt = PromptTemplate.from_template("""
Per ogni clausola, classifica il rischio per la parte {parte_cliente}.

CLAUSOLE:
{clausole_json}

OUTPUT JSON:
[
  {{"id": int, "rischio": "basso|medio|alto", "motivazione": str}}
]
""")

# Step 3: Raccomandazioni per clausole a rischio medio/alto
raccomandazioni_prompt = PromptTemplate.from_template("""
Per le clausole a rischio MEDIO o ALTO, genera raccomandazione operativa.

CLAUSOLE A RISCHIO:
{clausole_a_rischio}

OUTPUT JSON:
[
  {{"id": int, "raccomandazione": str, "priorita": "alta|media|bassa"}}
]
""")

# Step 4: Generazione report executive
genera_report_prompt = PromptTemplate.from_template("""
Genera un report executive in markdown italiano formale.
Sezioni: Sommario, Clausole critiche, Raccomandazioni prioritarie.

DATI:
- Metadati contratto: {metadata}
- Clausole classificate: {clausole_classificate}
- Raccomandazioni: {raccomandazioni}

LIMIT: 800 parole.
""")

# Composizione chain con LCEL
chain = (
    estrai_clausole_prompt | llm | parse_json
    | classifica_rischio_prompt | llm | parse_json
    | filter_rischio_alto_medio
    | raccomandazioni_prompt | llm | parse_json
    | genera_report_prompt | llm
)

Notare che ogni step ha responsabilità chiara e output schema definito. Il debugging diventa banale: se il report finale è scadente, sappiamo esattamente in quale step intervenire.

Error handling: il pattern che fa la differenza

In produzione, ogni step può fallire. Le cause: API timeout, rate limit del provider, output JSON malformato, contenuto che viola policy LLM, contesto oversized rispetto al context window.

Il pattern di error handling consigliato 2026:

PER OGNI STEP:
1. Try: chiamata LLM con timeout 60s
2. Catch timeout: retry con exponential backoff (max 3 tentativi)
3. Catch rate limit: backoff + switch su provider secondario (fallback model)
4. Catch JSON malformato: retry con prompt che chiede correzione esplicita
5. Catch policy violation: log evento + escalation umana
6. Catch context overflow: trigger summarization step + retry

Senza error handling esplicito, un chain in produzione fallisce silently nel 5-15% dei casi, con conseguenze operative serie.

State of the art tooling

Per chain semplici (2-4 step), uno script Python con OpenAI SDK è sufficiente. Per chain complessi production-grade serve un orchestratore.

LangChain rimane lo standard 2026 per Python e TypeScript. Curva di apprendimento media, libreria di integrazioni vastissima, copertura completa di pattern (sequential, branching, recursive, agentic). Documentazione docs LangChain molto matura.

dust.tt è alternativa molto valida per chain orientati al business user con interfaccia visuale, deployment cloud gestito, focus su agentic workflow per knowledge work.

LangGraph (dello stesso team LangChain) è il framework per chain con state management complesso, conditional edges, human-in-the-loop. Sta diventando standard per agenti production-grade.

Per casi d’uso più complessi vediamo che il nostro team interno usa la rete italiana professionisti IA per benchmark e best practice — il network è uno dei pochi luoghi in Italia dove queste pipeline vengono discusse con rigore tecnico. Le competenze richieste per affrontare prompt chain di produzione si sovrappongono ampiamente con quelle del prompt engineer e in parte con quelle del prompt designer per la componente di scrittura template singoli step.

Quando NON usare prompt chaining

Il prompt chaining ha overhead: più chiamate API significa più latency e più costo. Non sempre vale la pena.

Casi dove single-shot è preferibile:

Task semplici risolvibili in <500 token output
Sistemi real-time dove latency totale <2 secondi è critica
Volumi alti dove costo per task domina (chat customer service B2C ad alto traffico)
Task creativi puri dove la struttura step-by-step deteriora la fluidità output

Per casi limite, la decisione single-shot vs chain è sperimentale: si testano entrambi su test set rappresentativo, si misurano metriche tecniche e di business, si sceglie il pattern dominante. Le aziende che fanno scelta architetturale sbagliata spesso non lo sanno perché manca evaluation strutturata.

Una prima consulenza operativa di un’ora aiuta tipicamente a chiarire quale pattern conviene per workflow specifici, prima di investire in implementazione.

Domande frequenti

Quanto costa in più un chain rispetto a single-shot? Dipende dal numero di step e dalla quantità di stato condiviso tra essi. Un chain a 4 step su task analitico tipicamente costa 2.5-4x un single-shot equivalente in termini di token consumati. Il costo aggiuntivo è giustificato dalla qualità superiore solo su task complessi dove single-shot fallirebbe. Per task semplici, single-shot resta il pattern dominante.

Si può mischiare LLM diversi nello stesso chain? Sì, è il pattern multi-model routing. Tipico: step di estrazione semplice con gpt-4o-mini (economico, veloce), step di analisi complessa con Claude Sonnet 4.6 (qualità superiore su long-context), step di generazione report con gpt-4o. La logica di routing va testata: in alcuni casi un solo modello forte su tutti gli step batte la combinazione.

Come si gestiscono le credenziali sicure in un chain? Tutti i tool moderni (LangChain, dust) supportano injection di credentials runtime tramite environment variables o secret manager (AWS Secrets Manager, Vault, GCP Secret Manager). Mai hardcoded in codice o nei prompt. Per chain che processano dati sensibili, considerare audit log dettagliato con tracing distribuito (OpenTelemetry).

Quanto può durare un singolo chain in produzione? Dipende dal pattern. Chain sincrono real-time: target sotto 30 secondi end-to-end. Chain asincrono (batch processing): può durare minuti o ore. Per chain >5 minuti consigliamo architettura event-driven con queue (SQS, Pub/Sub) per resilienza e capacità di resume in caso di failure intermedio.

Differenza tra prompt chain e agentic AI? Un prompt chain è statico: il flow di step è definito a priori dall’engineer. Un agent è dinamico: il modello decide step-by-step quale azione prendere prossima, in base al contesto. Il chain è più affidabile e prevedibile, l’agent più flessibile ma anche più difficile da debuggare. Per workflow ad alta criticità (compliance, finanza), preferiamo chain espliciti. Per assistenti conversazionali, agenti AI sono più appropriati.