Quando Anthropic ha pubblicato Building Effective Agents alla fine del 2024, ha fatto qualcosa di raro per il settore: ha fornito agli ingegneri un vocabolario condiviso. Invece di un altro manifesto sull'intelligenza artificiale generale, la guida ha offerto sei pattern chiari per strutturare i sistemi LLM. Un anno e mezzo dopo, nel 2026, il panorama appare radicalmente diverso. Il Model Context Protocol è diventato uno standard universale. Claude ha acquisito nuove capacità. La maggior parte delle organizzazioni ha ora almeno un agente in produzione. In questo contesto, è lecito chiedersi se quei sei pattern abbiano ancora importanza, o se appartengano all'archivio accanto ai pesi dei modelli dell'anno scorso.

Per scoprirlo, ho testato tutti e sei i pattern contro un modello locale in un repository separato. La risposta è sì. Reggono ancora. Ma non perché siano leggi immutabili. Reggono perché gli ultimi diciotto mesi di esperienza in produzione hanno validato la logica fondamentale del framework.

Cosa ci ha dato realmente il framework

I sei pattern vale la pena ricordarli precisamente: Prompt Chaining, Routing, Parallelization, Evaluator-Optimizer, Orchestrator-Workers e Autonomous Agents. L'ultimo è essenzialmente un loop in cui il modello pianifica, agisce, osserva e ripete finché non viene soddisfatta una determinata condizione.

Molti ingegneri stavano già concatenando prompt o delegando compiti a thread di lavoro prima ancora che la guida apparisse. Ciò che Anthropic ha fornito è stata una tassonomia. L'“agent” di una persona era il “workflow” di un'altra, e la “multi-step tool call” di una terza. La guida ha riordinato il caos in categorie con confini chiari. Ciò ha reso possibile discutere dei compromessi senza che le discussioni diventassero sterili a causa di una terminologia diversa. In un campo sommerso dall'hype, un linguaggio preciso è una sorta di infrastruttura.

L'industria ha costruito sopra, non intorno

Entro il 2026, queste categorie sono ormai integrate nel modo in cui i team progettano i sistemi. Anthropic le insegna ancora nei suoi corsi Academy. Paper di ricerca e blog di ingegneria utilizzano ancora le stesse sei categorie per descrivere nuove architetture. Un tale tipo di longevità è insolito per una disciplina che rinnova il proprio stack ogni trimestre.

Il motivo è semplice. L'industria non ha sostituito il framework. Ci ha costruito sopra. Nuovi strumenti come MCP e i più recenti standard Agent Skills fungono da tubature. Rendono più facile connettere un modello a un database, esporre uno strumento o gestire lo stato. Ma non cambiano la logica su quando usare un router invece di un orchestrator. Un tubo migliore non riscrive la planimetria.

I dati di produzione del 2026 lo confermano. Il pattern di deployment più comune è ancora una singola chiamata di tool-use abbinata alla revisione umana. Il secondo più comune è un workflow multi-step con esattamente un passaggio di consegne a una persona. Entrambi sono discendenti diretti di Prompt Chaining e Routing. I loop completamente autonomi rimangono l'eccezione, non la regola, nei sistemi live.

La moderazione ha vinto sul mercato

Il miglior consiglio della guida originale era anche quello più spesso ignorato nel 2024: usa il pattern più semplice che funzioni. Non distribuire un agente completamente autonomo se un percorso hardcoded può portare a termine il lavoro.

Il mercato ha finalmente interiorizzato questo concetto. La maggior parte dei progetti pilota di agent fallisce ancora, e fallisce per la stessa prevedibile ragione. I team accumulano astrazioni su astrazioni finché nessuno riesce più a tracciare il confine decisionale. Quando il sistema devia, il debugging diventa archeologia. Le aziende che hanno avuto successo in produzione sono quelle che hanno mostrato moderazione. Sono passate per impostazione predefinita all'uso di tool a singolo turno. Hanno aggiunto uno strato di routing solo dopo che il singolo prompt si è rivelato incoerente. Hanno trattato l'autonomia come un rischio da giustificare, non come una funzionalità da celebrare.

Questo non è un argomento contro l'ambizione. È un argomento a favore della composizione. I pattern funzionano meglio quando vengono combinati deliberatamente, invece di ricorrere riflessivamente all'opzione più complessa del menu.

Dove iniziano a vedersi le crepe

Il framework non è una panacea. Esistono limiti invalicabili che emergono non appena si esce dalla fase di prototipo.

For high-frequency, low-cost tasks, deterministic code still wins. An LLM should not be normalizing a CSV column when pandas can do it in milliseconds without hallucinating. Avoid autonomous loops if you cannot define a crisp evaluation goal. Without a clear stopping condition, the model will iterate until it invents a reason to stop. For high-stakes decisions that require external grounding, do not rely solely on the model’s internal knowledge. And watch for bottlenecks in data retrieval. Any pattern that depends on vector search or external APIs can choke if your database is slow or your context window is clogged with irrelevant chunks.

These are not hypothetical edge cases. They are the constraints that separate a working demo from a system that survives the weekend.

A Rigid Check and a Wrong Failure

I learned the practical value of this framework while building my test repository. I was implementing the Evaluator-Optimizer pattern. My evaluator started as a hardcoded regex that scanned the model’s output for specific keywords. The model returned a correct, well-reasoned answer that happened to use synonyms instead of the exact words I was hunting. The evaluator flagged it as a failure.

The model was right. My check was too rigid.

Fixing it required more than expanding a word list. I switched the evaluator itself to an LLM-based judgment. That cost extra tokens and a few more milliseconds, but it restored the evaluation to the right level of abstraction. The pattern itself was sound. I had simply chosen the wrong implementation for the task. That is exactly the kind of mistake the framework is meant to prevent. Some evaluations need code. Others need a model. Knowing which is which is the whole point.

How to Use Them Now

Treat these six patterns as a starting point, not absolute law. Begin with a single prompt. If quality is inconsistent across input types, add a routing layer to send different requests to specialized prompts. If you need multiple independent perspectives before making a call, use Parallelization. If the task is large and divisible, try Orchestrator-Workers. Only reach for the full autonomous loop when the problem space is too wide to pre-map and when you have a reliable