Pattern workflow per agenti AI: 7 pattern e quando ognuno vince davvero (2026)

Pattern workflow per agenti AI: 7 pattern e quando ognuno vince davvero (2026)

I pattern workflow per agenti AI hanno finalmente dei numeri attaccati: a gennaio 2026, Google Research ha valutato 180 configurazioni di agenti e ha scoperto che lo stesso cambiamento di coordinamento migliorava il ragionamento finanziario parallelizzabile dell'80,9% mentre schiacciava la pianificazione sequenziale fino al 70% su PlanCraft. Stessa leva, esiti opposti. La variabile che decide è la decomponibilità del compito, non il numero di agenti, e i sette pattern qui sotto vengono giudicati sui dati pubblicati, non sui diagrammi dei vendor.

• Sette pattern contano: sequenziale, routing, parallelizzazione, orchestrator-workers, reflection, ReAct, plan-and-execute.
• La decomponibilità del compito decide il vincitore. Il lavoro parallelizzabile guadagna; il lavoro sequenziale peggiora.
• Parti con un agente. Aggiungine un secondo solo quando un singolo agente ristagna sotto circa l'85% di accuratezza.

Pattern workflow per agenti AI in sintesi: cosa dicono i dati

I sette pattern per agenti AI sono sequenziale (prompt chaining), routing (handoff), parallelizzazione (fan-out/fan-in), orchestrator-workers, reflection (valutatore-ottimizzatore), ReAct e plan-and-execute. Cinque documenti di vendor li chiamano in modi diversi, ma queste sette forme coprono ogni tassonomia che Anthropic, OpenAI, Vercel, Microsoft e Google Cloud pubblicano oggi. Human-in-the-loop non è una delle sette: è un livello di controllo che avvolge una qualsiasi di esse.

Leggi la colonna delle misurazioni con scetticismo. Tre righe hanno numeri veri; quattro riportano "nessuna misurazione pubblica", che è lo stato onesto del settore nel 2026. Cinque vendor pubblicano cinque nomi diversi per quelle che in realtà sono tre o quattro forme sottostanti. L'ultima colonna esiste perché tu possa ricondurre uno qualsiasi di quei nomi alla forma sottostante, che il resto dell'articolo sviscera una famiglia alla volta.

Due colonne che nessuno in SERP discute sono il costo in token e il budget di latenza. Sequenziale e routing spendono il minimo di entrambe; orchestrator-workers spende il massimo di entrambe; la parallelizzazione scambia spesa in token con tempo reale. Scegli il pattern in base alla risorsa che il tuo compito vincola davvero, non in base al diagramma che fa più scena.

Cosa sono i pattern workflow per agenti AI (e quali sono le 4 fasi di un workflow AI)?

I pattern di progettazione workflow per agenti AI sono forme riutilizzabili per organizzare chiamate LLM, uso di tool e logica di controllo in un sistema. Le sette che ricorrono in ogni tassonomia dei vendor sono sequenziale, routing, parallelizzazione, orchestrator-workers, reflection, ReAct e plan-and-execute. Ognuna scambia in modo diverso costo in token, latenza e accuratezza, quindi la scelta giusta dipende dalla struttura del compito più che dal framework che capita di usare.

Un tipico workflow di un agente AI attraversa quattro fasi, in ciclo:

1. Pianifica: il modello decide cosa fare dopo, dati l'obiettivo e lo storico fin qui.
2. Agisce: chiama un tool, che nel 2026 di solito significa un server MCP o una function call. Model Context Protocol (MCP) standardizza quel livello di tool tra i modelli.
3. Osserva: il risultato del tool rientra nel contesto come nuovo messaggio.
4. Riflette / ripete: il modello giudica se il risultato è abbastanza buono, poi ripete o si ferma.

Ogni pattern in questo articolo è un modo diverso di cablare queste quattro fasi. Il sequenziale fissa l'ordine nel codice. ReAct lascia che il modello scelga la fase successiva a ogni turno. Orchestrator-workers divide il ciclo tra diversi modelli.

Una distinzione conta prima del catalogo. Un workflow è un percorso di codice predeterminato; un agente consegna il controllo al modello. Anthropic traccia il confine così in Building Effective Agents: "I workflow offrono prevedibilità e coerenza per compiti ben definiti, mentre gli agenti sono l'opzione migliore quando servono flessibilità e decisioni guidate dal modello su larga scala."

Se sei arrivato cercando i tipi classici di agenti nell'AI (riflesso semplice, basato su modello, basato su obiettivi, con apprendimento), quella tassonomia è precedente agli LLM; i sette pattern qui sopra sono quelli che decidono se il tuo sistema va in produzione.

I pattern deterministici: sequenziale, routing e parallelizzazione

Tre pattern mantengono il controllo nel tuo codice invece che nel modello. Sono i più economici da eseguire e i più facili da debuggare, e il consiglio del team Claude da marzo 2026 è diretto su dove partire: "Parti dal pattern più semplice che risolve il tuo problema. Per impostazione predefinita, sequenziale."

Sequenziale (prompt chaining)

Una chiamata alimenta la successiva. Dividi un compito difficile in passi ordinati e ogni passo riceve l'output del passo precedente come input. Il vantaggio è la leggibilità: puoi ispezionare ogni risultato intermedio e mettere in cache ogni passo. Evitalo quando i sottocompiti sono indipendenti, perché stai pagando latenza per un ordinamento che non ti serve. Se lo stato deve sopravvivere tra i passi o tra le sessioni, quello è un problema di memoria, non di concatenazione; vedi la nostra guida sulla memoria degli agenti per la distinzione. Il suo unico avallo pubblicato è un valore predefinito: nessuno studio misura un guadagno dal chaining in sé, perché è la baseline che ogni altro pattern paga extra per battere.

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

Routing (handoff)

Un classificatore economico legge l'input e lo smista a un prompt o un modello specialista. OpenAI lo inquadra nella documentazione dell'Agents SDK: "Un agente di triage instrada la conversazione verso uno specialista, e quello specialista diventa l'agente attivo per il resto del turno." Evita il routing quando il classificatore è meno affidabile che eseguire semplicemente un percorso generale unico, perché ogni instradamento sbagliato è una risposta sbagliata silenziosa. La modalità di guasto qui ha un nome: perdita di contesto durante l'handoff. Lo specialista vede solo ciò che il router gli inoltra. Portarsi dietro l'intera traccia è una decisione di context engineering, e sbagliarla è il motivo per cui i sistemi con routing sembrano smemorati. Il conto dei token favorisce comunque il routing: il classificatore gira su un modello piccolo (gpt-4o-mini qui sopra), quindi un router aggiunge qualche centinaio di token economici per richiesta invece di una seconda chiamata costosa.

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

Parallelizzazione (fan-out/fan-in)

I sottocompiti indipendenti vengono eseguiti in parallelo, poi un passo di unione li combina. Anthropic la divide in sectioning (dividere il lavoro) e voting (eseguire lo stesso compito più volte e confrontare). Questa è la forma che Google Research ha misurato a +80,9% rispetto a un singolo agente sul ragionamento finanziario parallelizzabile a gennaio 2026, proprio perché il compito si scomponeva in modo pulito. Evitala nel momento in cui il passo n+1 dipende dall'output del passo n: parallelizzare una catena di dipendenze riordina solo le risposte sbagliate più in fretta. La latenza è l'altra metà del guadagno: le chiamate indipendenti girano in concorrenza, quindi il tempo reale cala più o meno con il numero di worker mentre la spesa totale in token resta piatta.

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct vs plan-and-execute: quale pattern di ragionamento dovresti usare?

ReAct alterna ragionamento e azione: il modello pensa, chiama un tool, osserva il risultato e solo allora decide il passo successivo. Plan-and-execute scrive il piano completo prima che qualsiasi tool venga eseguito, poi esegue i passi in ordine. ReAct si adatta alle sorprese durante l'esecuzione; plan-and-execute paga una grande chiamata di pianificazione in anticipo e si fida del percorso.

ReAct decide il passo successivo dopo ogni osservazione; plan-and-execute si impegna sull'intero percorso prima della prima chiamata a un tool.

ReAct nasce da Yao et al. (arXiv 2210.03629, v1 ottobre 2022, v3 marzo 2023), che riportava +34% assoluto di successo su ALFWorld e +10% su WebShop rispetto alle baseline di imitation e reinforcement learning, usando solo uno o due esempi in-context. È il ciclo predefinito dietro la maggior parte degli agenti che usano tool, ed è una lacuna nel terzo risultato in SERP: il documento di orchestrazione di Microsoft Learn, 7.133 parole, omette del tutto ReAct. Quel ritmo osserva-decidi è il motivo per cui ReAct gestisce i compiti aperti ("naviga finché non trovi X") meglio di qualsiasi piano precostruito: il piano dovrebbe indovinare cosa contengono le pagine prima di leggerle.

Plan-and-execute nasce da Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), che prima elabora un piano dividendo il compito in sottocompiti, poi li porta a termine. L'articolo riporta di battere la chain-of-thought zero-shot su tutti e dieci i dataset valutati; non citiamo un singolo valore perché l'abstract non ne pubblica nessuno. Usalo quando il percorso è prevedibile e ripianificare dopo ogni passo sprecherebbe token. Il compromesso è la fragilità: se il passo tre fallisce, un ciclo plan-and-execute richiede un hook esplicito di ripianificazione, mentre ReAct ripianifica per costruzione.

La riga dell'evidenza misurata è la spia onesta. ReAct ha un articolo del 2022 con numeri a livello di compito; plan-and-execute ha una passata su dieci dataset e nessun valore di punta, ed è uno dei motivi per cui viene citato più spesso di quanto venga misurato.

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

Quel limite di iterazioni non è opzionale. Un ciclo ReAct senza uscita brucia token finché il tuo budget non si esaurisce; max_steps è il guardrail più economico di tutto questo articolo. Plan-and-execute richiede la stessa protezione un livello più su: limita le ripianificazioni, non solo i passi, oppure un piano fallimentare si rigenererà all'infinito.

I pattern di qualità: reflection, valutatore-ottimizzatore e human-in-the-loop

I pattern di qualità spendono token extra per alzare la qualità dell'output, e ripagano solo quando la qualità è misurabile. La reflection (Anthropic la chiama valutatore-ottimizzatore) esegue un generatore e un critico in un ciclo: un modello butta giù la bozza, un altro la critica, la bozza migliora. Se non puoi dare un punteggio all'output con un test, una rubrica o un modello valutatore, il critico è solo token extra che discutono con sé stessi. Costruire quel valutatore è la parte difficile; la nostra guida su come valutare gli agenti in produzione copre cosa richiede una funzione di punteggio utilizzabile. Dove la precondizione regge, il pattern è un'assicurazione economica: Anthropic descrive il valutatore-ottimizzatore come due chiamate LLM in un ciclo, una che genera e una che critica, il che compra un miglioramento di qualità misurabile per qualche secondo di latenza in più.

La modalità di guasto che nessuno mette nei diagrammi è la reflection fuori controllo: il critico e il generatore girano in ciclo per sempre, o peggio, oscillano. La soluzione è un limite rigido di iterazioni più un'interruzione in assenza di miglioramenti, scritta nel codice invece che richiesta nel prompt:

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

Human-in-the-loop è un livello di controllo, non un ottavo pattern. Avvolge una qualsiasi delle sette: un umano approva prima che un passo irreversibile venga eseguito. Solo 2 dei 6 migliori risultati in SERP la coprono anche solo di sfuggita. Piazza il gate sulle azioni irreversibili, sulla spesa reale e su qualsiasi cosa lasci il tuo sistema come comunicazione esterna. Tutto il resto dovrebbe girare senza presidio o non girare affatto. Il gate stesso dovrebbe essere codice stupido, non un altro LLM: una coda di approvazione, una soglia di spesa, una allowlist di domini. Mettere un modello a capo della decisione se un umano debba guardare vanifica lo scopo.

Il multi-agente vale 15× i token? Cosa dicono davvero i benchmark

Orchestrator-workers è il settimo pattern: un agente principale decompone un compito, delega pezzi ad agenti worker e unisce ciò che restituiscono. "Multi-agente" è questo pattern portato all'estremo, non una forma separata, quindi la domanda vera è quando l'orchestratore si guadagna il suo overhead.

Quando dovresti usare il multi-agente invece di un singolo agente? Solo quando un singolo agente ristagna sotto circa l'85% di accuratezza sul compito. Questa regola pratica circolava su r/AI_Agents (2026-04-23) insieme allo studio di Google Research, e combacia con i dati misurati: sopra quell'asticella, agenti aggiuntivi aggiungono costo e amplificazione degli errori senza aggiungere accuratezza.

Ecco ogni numero pubblicato che siamo riusciti a verificare, affiancato:

Una avvertenza prima di approfondire: ogni valore di Google Research qui sopra viene dal post del blog del 2026-01-28, e l'articolo che ci sta dietro (arXiv 2512.08296) è stato revisionato da allora, quindi la sua versione attuale riporta 260 configurazioni e R² = 0,373 invece dei 180 e 0,513 del blog. La direzione regge in entrambi i casi; i valori esatti dipendono da quale versione stai leggendo.

Due di queste righe vengono citate male di routine, quindi ecco i calcoli. Il valore 15× di Anthropic è misurato rispetto a un'interazione di chat, e il suo valore per l'agente singolo è 4×. Quindi il multi-agente costa circa 15 / 4 = 3,75× i token di un singolo agente, non 15×. E l'amplificazione degli errori di Google Research, 17,2× per gli agenti indipendenti contro 4,4× per quelli centralizzati, significa che un orchestratore contiene circa 17,2 / 4,4 = 3,9× meno amplificazione degli errori rispetto a lasciare gli agenti liberi senza supervisione.

Leggendo la descrizione di Anthropic accanto ai numeri di Google Research, la nostra lettura è che la decomponibilità, non il numero di agenti, è la variabile che decide. Il compito di ricerca di Anthropic si divideva in modo pulito in sotto-ricerche parallele, quindi più agenti aiutavano. I compiti di pianificazione sequenziale di Google non si dividevano, quindi più agenti si intralciavano a vicenda.

Questo combacia con ciò che dicono i practitioner quando i sistemi arrivano in produzione. Su r/AI_Agents, un thread intitolato "I sistemi multi-agente sono un incubo totale in produzione" (2026-04-23, 56 punti, 68 commenti) veniva da un OP che ha rilasciato oltre 20 sistemi per clienti: "Quelli che restano davvero in funzione... sono quasi imbarazzantemente semplici," e "ogni volta che un agente parla con un altro, perdi contesto. È come quel gioco del telefono." Il commento in cima riassume l'intera sezione: "prova a risolvere il tuo problema con un singolo agente. Se questo agente ha >85% di accuratezza, un sistema multi-agente non aggiungerà altro valore."

Prima di aggiungere un agente, prova le soluzioni economiche che Anthropic ha misurato: una descrizione di tool migliorata ha prodotto un calo del 40% nel tempo di completamento del compito, e le chiamate ai tool in parallelo hanno tagliato il tempo di ricerca fino al 90%. Entrambe battono un secondo agente sul costo. Se poi vai davvero sul multi-agente in un tool reale, i subagenti di Claude Code sono orchestrator-workers che puoi ispezionare riga per riga.

Stesso pattern, cinque nomi: una tabella Rosetta dei framework

Le stesse quattro forme compaiono con nomi diversi nella documentazione di ogni vendor, e la nomenclatura non si trasferisce tra i framework. "Magentic" e "group chat" di Microsoft non significano nulla nell'OpenAI SDK finché non li traduci, e quella tassa di traduzione è un costo reale che questa tabella elimina.

Cinque vendor, cinque vocabolari, tre o quattro forme reali. Il costo pratico emerge quando cambi framework: un team che passa dall'Agent Framework di Microsoft all'OpenAI SDK deve rimappare "magentic" su agents-as-tools e "group chat" su un grafo di handoff prima che una singola riga di codice venga trasferita. La tassonomia in undici nomi di Google Cloud è la più lunga, la lista in sette nomi di Anthropic è la più citata, e i tre nomi del blog Claude sono quelli che implementerai per primi. Leggi la forma, poi leggi l'SDK. Le intestazioni di colonna sono i documenti stessi: Anthropic, il blog Claude, l'OpenAI Agents SDK, il Vercel AI SDK, Microsoft Learn e Google Cloud. Una volta viste le forme, scegliere un framework è una decisione separata; la nostra carrellata dei migliori framework per agenti AI nel 2026 e il confronto LangGraph vs CrewAI vs OpenAI Agents SDK coprono quella.

Quando NON dovresti proprio usare un workflow di agenti?

Spesso, non dovresti. La scala decisionale più votata su r/AI_Agents (2026-03-09) la mette in modo semplice: "Se funzionano le istruzioni if...then, usa quelle. Poi, se funzionano i workflow tradizionali, usa quelli. Altrimenti usa l'AI agentica." Due dei primi tre risultati in SERP sono documentazione cloud che strutturalmente non può dirti di costruire di meno. Noi possiamo. I dati in questo articolo puntano nella stessa direzione: i due guadagni misurati più grandi (+80,9% e +90,2%) vengono entrambi da compiti che si scomponevano in modo pulito, e la perdita misurata peggiore (−70%) veniva dal forzare agenti su un compito che non si scomponeva.

Le modalità di guasto hanno un nome, e ognuna ora ha un numero attaccato:

• Perdita di contesto negli handoff: ogni messaggio da agente ad agente perde stato (la lamentela del "telefono" su r/AI_Agents, 2026-04-23).
• Amplificazione degli errori: 17,2× per gli agenti indipendenti contro 4,4× centralizzati (Google Research, 2026-01-28).
• Cicli di reflection fuori controllo: limita le iterazioni e interrompi in assenza di miglioramenti, come nel codice qui sopra.
• Degrado sui compiti sequenziali: dal 39% al 70% in meno quando parallelizzi lavoro che non si scompone (Google Research, 2026-01-28).
• Esplosione dei costi: circa 15× i token di chat per un sistema multi-agente (Anthropic, 2025-06-13).

Ognuna di queste modalità di guasto ha un limite che puoi scrivere in dieci righe di codice, e il limite è sempre più economico dell'agente che stavi per aggiungere.

Walden Yan di Cognition ha sostenuto la stessa tesi dal lato di chi costruisce in Don't Build Multi-Agents (2025-06-12): "Condividete il contesto, e condividete le tracce complete degli agenti, non solo i singoli messaggi," e "Le azioni portano decisioni implicite, e decisioni in conflitto portano risultati cattivi." Il confronto di r/AI_Agents è quello su cui torniamo di continuo: "il multi-agente inizia ad assomigliare molto ai microservizi. potente quando i confini sono reali, doloroso quando sono inventati."

Come Techsy affronta la scelta del pattern

La scala qui sotto è la nostra lettura dei risultati di Google Research e Anthropic più i thread dei practitioner, non un risultato misurato nostro. La percorriamo dall'alto in basso e ci fermiamo alla prima riga che si adatta:

Dai dati in questo articolo seguono tre cose. Parti dal sequenziale, perché Anthropic lo consiglia e nulla in SERP lo smentisce. Parallelizza solo ciò che si scompone, perché lo stesso cambiamento di coordinamento misurato a +80,9% è stato misurato anche a −70%. E tratta un secondo agente come ultima risorsa, perché il conto dei token è reale e l'amplificazione degli errori è misurata. Il filo conduttore è che aggiungere agenti è una mossa di scalabilità, non una mossa di qualità: i benchmark la premiano solo dove il lavoro si divide, e i thread dei practitioner lo confermano ovunque altrove. Se vuoi un secondo parere su una architettura prima di costruirla, richiedi una consulenza gratuita.

Domande frequenti

Quali sono i 7 pattern per agenti AI?

I sette sono sequenziale (prompt chaining), routing (handoff), parallelizzazione (fan-out/fan-in), orchestrator-workers, reflection (valutatore-ottimizzatore), ReAct e plan-and-execute. Ricorrono con nomi diversi in ogni tassonomia dei vendor, da Anthropic a Google Cloud. Human-in-the-loop viene discusso insieme a loro, ma è un livello di controllo che avvolge una qualsiasi delle sette, non un ottavo pattern.

Quali sono le 4 fasi di un workflow di un agente AI?

Pianifica, agisci, osserva, rifletti. Il modello pianifica il passo successivo, agisce chiamando un tool, osserva il risultato del tool che entra nel contesto, poi riflette se l'obiettivo è raggiunto e ripete o si ferma. Ogni pattern in questo articolo è un modo diverso di cablare insieme queste quattro fasi.

Qual è la differenza tra un workflow AI e un agente AI?

Un workflow segue percorsi di codice predeterminati; un agente lascia che il modello diriga il proprio flusso di controllo. La regola di Anthropic: workflow per la prevedibilità su compiti ben definiti, agenti per la flessibilità quando servono decisioni guidate dal modello su larga scala. La maggior parte dei sistemi in produzione sono workflow con qualche passo da agente dentro.

ReAct vs plan-and-execute: quale dovrei usare?

Usa ReAct quando il passo successivo dipende da ciò che l'ultimo tool ha restituito e il percorso può cambiare in corsa. Usa plan-and-execute quando il percorso è prevedibile in anticipo e ripianificare dopo ogni passo sprecherebbe token. ReAct ha misurato +34% su ALFWorld (Yao et al., 2022); plan-and-execute ha battuto zero-shot CoT su dieci dataset (Wang et al., 2023).

Serve un framework come LangGraph per usare questi pattern?

No. Ogni blocco di codice in questo articolo è una semplice chiamata SDK, e i pattern sono precedenti ai framework che danno loro un nome. Un framework si guadagna il suo posto sulla persistenza dello stato, sui tentativi e sul tracing, non sul pattern in sé. Se ne stai scegliendo uno, il nostro confronto tra framework copre i compromessi.

Come impedisco a un ciclo di reflection di girare per sempre?

Due protezioni, entrambe nel codice: un limite rigido di iterazioni (noi usiamo 4 round) e un'interruzione in assenza di miglioramenti che ferma tutto nel momento in cui la riscrittura del critico non ottiene un punteggio migliore della bozza attuale. Non fidarti del prompt per chiudere il ciclo; il modello non ha idea di quanto costino le cose.

Quando basta un singolo agente?

Quando supera circa l'85% di accuratezza sul compito. Questa euristica, circolata su r/AI_Agents (2026-04-23) insieme allo studio di Google Research, combacia con i benchmark: sopra quell'asticella, agenti extra aggiungono costo e amplificazione degli errori senza aggiungere accuratezza. Misura la baseline dell'agente singolo prima di progettare qualsiasi cosa di più grande.

Dove trovo esempi di pattern workflow per agenti AI con codice?

I cinque blocchi Python qui sopra coprono sequenziale, routing, parallelizzazione, ReAct e reflection, tutti come semplici chiamate SDK che puoi copiare direttamente. Per esempi in stile vendor, il Vercel AI SDK fornisce TypeScript eseguibile per ogni pattern e la documentazione dell'OpenAI Agents SDK copre handoff e agents-as-tools. I link a entrambi sono nella lista delle Fonti qui sotto.

Fonti

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, Come abbiamo costruito il nostro sistema di ricerca multi-agente (2025-06-13)
• Google Research, Verso una scienza della scalabilità dei sistemi di agenti (2026-01-28); articolo: arXiv 2512.08296
• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang et al., Plan-and-Solve Prompting (ACL 2023)
• Claude di Anthropic, Pattern workflow comuni per agenti AI (2026-03-05)
• OpenAI Agents SDK, Orchestrare più agenti
• Vercel AI SDK, Pattern workflow
• Microsoft Learn, Pattern di orchestrazione per agenti AI (aggiornato 2026-05-12)
• Google Cloud, Scegli un pattern di progettazione per il tuo sistema di AI agentica (2026-05-28)
• Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, I sistemi multi-agente sono un incubo totale in produzione (2026-04-23); Aspetta, i workflow sono davvero meglio dei sistemi multi-agente? (2026-03-09)