Agente o pipeline? Come si decide (senza innamorarsi della parola agente)

17 agosto 2026 · Lettura: 9 min

C'è una domanda che, in una riunione su dieci, fa perdere mezz'ora a tutti: «lo facciamo con un agente?». La parola è affascinante, suona moderna, e ha un difetto: viene pronunciata prima di aver capito che problema si sta risolvendo. Il risultato tipico è un sistema che, per compilare un modulo o smistare un'email, avvia un modello che «ragiona», chiama tre strumenti, ci ripensa, ne chiama un quarto e infine produce lo stesso risultato che una funzione di venti righe avrebbe dato in un decimo del tempo e a un centesimo del costo.

Il punto di questo articolo è togliere il fascino dalla parola e restituirle un significato operativo. Non esiste una tecnologia migliore in assoluto: esistono due modi diversi di far lavorare un modello, e la scelta tra i due è quasi sempre decisa dalla struttura del problema, non dalle mode. Chi progetta sistemi con gli LLM ripete la stessa regola: trova la soluzione più semplice che funziona, e aumenta la complessità solo quando serve davvero.

Le due parole, definite bene

Un workflow — chiamiamolo pipeline — è un sistema in cui i passaggi sono decisi da te, nel codice. Il modello viene chiamato in punti precisi per fare cose precise: classifica, riassumi, estrai, riscrivi. Il percorso è fisso; a cambiare è solo il contenuto che ci scorre dentro. Tu possiedi il control flow: sai in anticipo quali passi verranno eseguiti e in che ordine.

Un agente è un sistema in cui è il modello a decidere il passo successivo. Gli dai un obiettivo e un insieme di strumenti, e lui sceglie da solo quale usare, in che ordine, e quando ha finito. Il percorso non è scritto da nessuna parte: emerge, un turno dopo l'altro, dalle osservazioni che il modello raccoglie mentre lavora. Tu possiedi l'obiettivo e i guardrail, non ogni singola diramazione.

La differenza non è la presenza di strumenti — anche una pipeline può chiamarne — né la presenza di un LLM. La differenza è chi decide il prossimo passo: il tuo codice, o il modello. Tutto il resto discende da qui.

Perché la pipeline vince più spesso di quanto pensi

Il grosso del lavoro reale ha un percorso prevedibile. Smistare i ticket in tre categorie, estrarre importo e scadenza da una fattura, tradurre e poi riformattare, controllare un testo e correggerlo: in tutti questi casi tu sai già quali sono i passi. E quando sai i passi, scriverli a mano ti dà quattro cose che un agente non ti regala.

La prima è la prevedibilità: a parità di input, il sistema fa sempre le stesse mosse, quindi puoi ragionarci sopra e spiegarlo. La seconda è il costo: ogni turno autonomo in più di un agente è un altro giro di token, e i giri si sommano; una pipeline fa esattamente le chiamate che servono e nessuna di più. La terza è la latenza: niente attese per «pensare» al passo dopo, perché il passo dopo è già scritto. La quarta è la manutenibilità: quando qualcosa si rompe, sai dove guardare, perché la mappa del percorso esiste ed è la tua.

Il test da fare prima di tutto è brutale nella sua semplicità: riesci a disegnare l'albero delle decisioni? Se la risposta è sì, non hai un problema da agente. Hai una pipeline che aspetta solo di essere scritta.

Le pipeline non sono tutte uguali

Anche restando nel mondo dei percorsi fissi hai diversi mattoni a disposizione, ed è utile conoscerne i nomi perché coprono la maggioranza dei casi reali.

Il prompt chaining spezza un compito in passi in sequenza: l'uscita di uno entra nel successivo (prima genera la scaletta, poi scrivi, poi accorcia). Il routing classifica l'input e lo manda al ramo giusto (una domanda tecnica a un percorso, una commerciale a un altro). La parallelizzazione lancia più chiamate insieme e ne combina i risultati, utile quando servono più prospettive sullo stesso testo o più controlli indipendenti. Sono tre schemi semplici, componibili, e coprono una quantità sorprendente di lavoro senza che nessun modello debba mai «decidere» alcunché sull'ordine delle mosse.

Quando l'agente è la scelta giusta

Ci sono problemi in cui l'albero delle decisioni non si può disegnare, non perché sei pigro, ma perché dipende da cose che scopri solo mentre lavori. Non sai quanti passi serviranno né quali, perché il passo successivo dipende dal risultato del precedente. È qui che l'agente guadagna il suo costo.

Gli esempi classici hanno tutti la stessa forma. Un assistente che indaga un problema tecnico: quali comandi eseguire dipende da cosa restituiscono i precedenti. Un agente di supporto che, a seconda della risposta del cliente, deve interrogare sistemi diversi. Un agente che scrive codice e lo aggiusta finché i test non passano: il numero di iterazioni non è prevedibile. In tutti, c'è una regola d'oro che rende l'autonomia accettabile: il progresso deve essere verificabile. I test che passano, lo screenshot che mostra il risultato, il documento che ora contiene il campo richiesto — serve un modo, indipendente dal modello, di sapere che si sta avvicinando all'obiettivo. Senza quel segnale, un agente non è flessibile: è solo imprevedibile.

C'è anche un pattern ibrido che vale la pena tenere a mente, l'evaluator-optimizer: un modello produce, un altro valuta secondo un criterio, e il primo riprova finché la valutazione non è soddisfatta. È un pezzo di autonomia controllata dentro una struttura per il resto fissa — spesso è tutto ciò di cui hai davvero bisogno.

Il prezzo dell'autonomia

Vale la pena dirlo senza giri di parole, perché è la ragione per cui l'agente non è la scelta di default. L'autonomia si paga su tre fronti: più latenza (ogni decisione è un turno in più), più costo (ogni turno sono altri token, e crescono con la lunghezza della conversazione) e più rischio (un errore preso presto si trascina in tutti i passi successivi). Un agente scambia la prevedibilità con la flessibilità. Se non ti serve la flessibilità, stai solo pagando di più per meno controllo.

E quando un agente solo non basta: più agenti

Salendo di complessità c'è un terzo scenario: un compito così ampio da non entrare comodamente in un singolo agente, e che conviene spezzare tra più agenti specializzati che si coordinano. Uno cerca, uno scrive, uno verifica; oppure agenti costruiti da team o addirittura da aziende diverse che devono collaborare.

Qui, nel 2026, sta maturando uno standard aperto pensato apposta: A2A (Agent2Agent), un protocollo — ora ospitato dalla Linux Foundation — che definisce come agenti diversi si scoprono a vicenda, si scambiano compiti e collaborano, senza doversi rivelare la logica interna. Se hai presente MCP, l'analogia è pulita: MCP standardizza il dialogo tra un modello e i suoi strumenti, A2A standardizza il dialogo tra un agente e un altro agente. Ma vale la solita cautela, anzi raddoppiata: il multi-agente moltiplica costi, punti di guasto e difficoltà di debug. È la risposta giusta a un problema che pochi hanno davvero. La maggioranza dei sistemi in produzione oggi funziona benissimo con una pipeline, o con un singolo agente ben fatto.

Il metodo, in tre domande

Quando torna la domanda «lo facciamo con un agente?», rispondi con queste, nell'ordine.

Primo: so disegnare il percorso in anticipo? Se sì, scrivi una pipeline e fermati qui. Non ti serve altro. Secondo, se il percorso non è prevedibile: posso verificare il progresso con un segnale indipendente dal modello? Se no, non sei ancora pronto per un agente — prima costruisci quel segnale, altrimenti stai delegando alla cieca. Se sì, un agente è giustificato: dagli obiettivo, strumenti e limiti chiari. Terzo, solo se il compito è troppo grande per un agente e ha parti nettamente separabili: vale il costo di farne collaborare più d'uno? Quasi sempre la risposta onesta è «non ancora».

Il filo che tiene insieme tutto è lo stesso di ogni buona ingegneria: parti dalla soluzione più semplice che risolve il problema, misura se funziona, e aggiungi autonomia solo quando hai la prova che quella semplice non basta. La parola «agente» non è un obiettivo. È uno strumento con un conto da pagare, e va usato quando il conto vale la pena.

Prova subito

Prendi un compito che stai pensando di automatizzare — o uno che hai già automatizzato «con un agente» — e fai questo esercizio da quindici minuti, con carta e penna o un file di testo:

Prova a disegnare l'albero delle decisioni. Scrivi ogni passo e ogni «se succede X, allora Y». Se ci riesci fino in fondo, hai la prova che ti serve una pipeline: segna quali passi sono chiamate al modello (classifica, estrai, riscrivi) e quali sono codice normale.
Cerca il punto dove la penna si ferma. Se a un certo punto non riesci a scrivere il passo successivo perché «dipende da cosa torna prima», hai trovato la parte che forse richiede un agente. È lì, e solo lì, che l'autonomia guadagna il suo costo.
Definisci il segnale di progresso. Per quella parte, scrivi in una riga come farebbe il sistema a sapere che si sta avvicinando all'obiettivo senza fidarsi del modello: un test, un controllo di formato, un confronto con un dato certo. Se non riesci a scriverlo, quello — non il modello — è il primo pezzo da costruire.

Alla fine avrai o una pipeline pronta da scrivere, o un agente con confini chiari e un modo per sapere se sta lavorando bene. In entrambi i casi avrai smesso di scegliere per moda e avrai iniziato a scegliere per struttura del problema. È l'unica differenza che conta.