I Livelli di Complessità degli Agenti AI

Ogni settimana esce un nuovo framework per agenti AI. Ogni settimana qualcuno annuncia “il paradigma definitivo”. E ogni settimana, in produzione, i sistemi più affidabili restano quelli più semplici. Non è un caso. È un pattern.

La decisione più critica quando si progetta un sistema AI non è quale modello usare. È decidere quanta complessità serve davvero. La differenza tra una singola chiamata API e un’architettura multi-agente può significare settimane di sviluppo in più, costi 10 volte superiori e un sistema impossibile da debuggare.

Eppure la tentazione di partire con l’architettura più sofisticata è forte. La realtà che vediamo nei progetti con i nostri clienti è diversa: i livelli di complessità degli agenti AI vanno scelti con criterio, non con entusiasmo.

I livelli: dal semplice LLM al multi-agente

Esiste una tassonomia chiara. Cinque livelli, dal più semplice al più complesso. Ogni livello aggiunge potenza - ma anche costi, latenza e complessità di manutenzione. Capire dove ti posizioni è il primo passo per evitare di sovra-ingegnerizzare.

Livello 1: LLM aumentato

Una singola chiamata API. Structured output. Classificazioni, estrazioni dati, generazione di testo. Costo basso, latenza minima, facilissimo da testare. Se il problema si risolve così, non serve andare oltre. E sorprendentemente spesso si risolve così.

Livello 2: DAG con routing deterministico

Qui si entra nei grafi aciclici diretti (Directed Acyclic Graph). Il sistema classifica l’input - un ticket di assistenza, una richiesta commerciale - e segue un percorso deterministico con regole if/else. Questo è ancora il fondamento dei sistemi AI affidabili in produzione.

Il problema? Quando il DAG cresce, diventa un mostro di Frankenstein. Venti rami, trenta rami, sviluppatori diversi che lavorano su parti diverse del grafo. Il debugging diventa un incubo. Ma è un incubo gestibile - molto più di un agente che “ragiona” in modo imprevedibile.

Livello 3: tool calling agentico

Invece di codificare ogni decisione, dai al modello una serie di tool - database, policy aziendali, invio email - e lasci che l’AI decida quale usare. L’agente ragiona in un loop. È qui che il sistema diventa “agentico” nel senso vero del termine.

Lo sweet spot nella pratica? Combinare livelli 2 e 3. DAG deterministico come struttura portante, tool call solo ai nodi periferici dove la complessità lo richiede. Classificare e instradare in modo deterministico, lasciare autonomia all’AI solo dove serve.

Livello 4: agent harness

Un salto significativo. Non è più solo un LLM con dei tool - è un modello con accesso a un runtime completo: esecuzione bash, file system, ricerca web, API esterne via server MCP. È ciò che alimenta strumenti come Claude Code.

Il Claude Agent SDK permette di replicare queste capacità nelle proprie applicazioni. Potente? Enormemente. Rischioso? Altrettanto. Dare a un’AI accesso al file system e alla rete in produzione senza limiti è come lasciare le chiavi dell’ufficio a un nuovo dipendente il primo giorno - senza supervisione.

Livello 5: orchestrazione multi-agente

L’orchestratore delega a sotto-agenti, ciascuno con la propria finestra di contesto separata. Il problema che risolve è reale: nei task lunghi, il contesto si gonfia al 70-80%. Con i sotto-agenti, ognuno parte fresco, fa la sua ricerca e riporta solo il risultato. Il contesto dell’orchestratore resta pulito.

Ma è ancora molto presto. Chi lo sta testando in produzione riporta inaffidabilità e costi significativi. Un’area in evoluzione rapida, non ancora matura per sistemi business-critical.

Cosa funziona davvero in produzione

Dopo un anno e mezzo di ottimizzazione su sistemi reali di customer care, il pattern che emerge è chiaro.

DAG deterministico + tool call ai nodi periferici. Il sistema classifica il ticket, lo instrada lungo un percorso definito, e solo quando serve flessibilità - consultare le policy specifiche, richiedere informazioni mancanti - il nodo periferico ha accesso a tool.

Perché funziona?

• Il DAG è testabile - puoi scrivere unit test per ogni ramo
• Il debugging è localizzato - sai esattamente dove il flusso ha preso la strada sbagliata
• I costi sono prevedibili - meno chiamate API, meno token consumati
• La latenza è bassa - percorsi deterministici senza loop di ragionamento

L’agent harness è il vero differenziatore

Un punto che sfugge nella discussione sugli agenti AI autonomi: non sono i modelli a fare la differenza. È l’harness intorno al modello - l’infrastruttura che gestisce tool, permessi, contesto, retry, sicurezza.

Claude Code non è superiore ad altri strumenti solo per il modello sottostante. È l’agent harness - il modo in cui gestisce file system, permessi, contesto - a renderlo efficace. Per chi costruisce sistemi AI aziendali, investire tempo nella comprensione degli harness disponibili - Claude Agent SDK, LangGraph, Pydantic AI - è più produttivo che inseguire l’ultimo modello. I modelli migliorano ogni mese. Un buon harness resta valido molto più a lungo.

La regola: il livello più semplice che funziona

La tentazione di usare un sistema multi-agente per ogni progetto è comprensibile. È più affascinante, più “all’avanguardia”. Ma in produzione, la complessità ha un costo reale: in latenza, in budget, in ore di debugging.

• Si risolve con una singola chiamata API? Livello 1
• Serve classificare e instradare? DAG deterministico
• Troppi casi limite per il DAG? Aggiungi tool call ai nodi periferici
• Serve un runtime completo? Agent harness - con estrema cautela
• Il contesto esplode? Multi-agente - solo se necessario

I livelli si combinano. Il sistema migliore non è quello che usa il livello più alto - è quello che usa il livello giusto per ogni nodo. Tre righe di if/else spesso battono un agente con cinque tool. Non è meno sofisticato. È più intelligente.