01 - AI Agents: Introduzione, Cosa Sono e Quando Usarli

Il problema: un'automazione che non sa che strada prendere

Hai un compito che un modello linguistico, da solo, non chiude: rispondere a un cliente che chiede dov'è il suo ordine richiede di consultare un gestionale, e se l'ordine non esiste, di cercare per un'altra chiave. Puoi scrivere questa logica come una sequenza di passi fissi, oppure puoi lasciare che sia il modello a scegliere il passo successivo. La prima soluzione si chiama workflow, la seconda agente. Questa serie parla della seconda, e questo primo articolo serve a decidere quando vale la pena sceglierla: spesso la risposta è «non ancora».

La distinzione che usiamo è quella di Anthropic nel suo articolo Building effective agents: i workflow sono sistemi in cui modelli e strumenti sono orchestrati da percorsi di codice predefiniti; gli agenti sono sistemi in cui il modello dirige dinamicamente il proprio processo e l'uso degli strumenti, mantenendo il controllo su come portare a termine il compito. La stessa fonte raccomanda di cercare la soluzione più semplice possibile e di aumentare la complessità solo quando serve, il che può voler dire non costruire nessun sistema agentico, perché questi sistemi di solito scambiano latenza e costo con una migliore riuscita sul compito.

Cos'è un agente AI?

La definizione di agente viene dal manuale di Russell e Norvig, Artificial Intelligence: A Modern Approach: qualunque cosa possa essere vista come qualcosa che percepisce l'ambiente attraverso sensori e agisce su di esso attraverso attuatori. Un termostato rientra in questa definizione. Ciò che rende interessante l'agente basato su un modello linguistico è che la scelta dell'azione non è scritta nel codice, ma prodotta dal modello a ogni giro, a partire da ciò che ha visto fin lì.

Un modello usato direttamente è invece una funzione: riceve un prompt, restituisce testo, e il ciclo finisce. Per diventare un agente gli serve un anello attorno, cioè un programma che esegue le azioni che il modello propone, rimette il risultato nel contesto e richiama il modello finché non decide di fermarsi. Le capacità concrete che quell'anello rende possibili sono quattro.

• Decisioni a più passi: scomporre l'obiettivo e adattare il piano ai risultati intermedi, come nel caso dell'ordine che non si trova.
• Strumenti esterni: chiamare API, interrogare database, leggere e scrivere file.
• Memoria tra i giri: tenere nel contesto ciò che è già stato osservato, e se serve salvarlo fuori dal contesto.
• Gestione dell'errore: se uno strumento fallisce, il modello vede l'errore e può riprovare in un altro modo.

Nessuna di queste quattro voci è magica: sono tutte codice scritto da te attorno a una chiamata al modello. La più delicata è l'ultima, perché un errore ripetuto senza un tetto ai giri è il modo più rapido di bruciare budget; per questo il listato qui sotto ha un limite esplicito, max_giri.

Workflow e agente a confronto, in poche righe

Il listato risolve lo stesso problema in due modi. workflow è il percorso fisso: cerca l'ordine e riporta lo stato, qualunque cosa trovi. agente è un ciclo in cui modello restituisce una coppia (azione, argomento), il codice esegue lo strumento corrispondente e aggiunge il risultato a osservazioni. Il «modello» qui è finto: segue un copione per ciascuna richiesta, ma sceglie l'azione in base a quante osservazioni ha già, come farebbe un modello vero con il contesto. In questo modo l'esempio è riproducibile e non chiama nessun servizio.

# Modello finto: segue un copione, così l'esempio è riproducibile.
# In un sistema vero questa funzione sarebbe una chiamata a un LLM.
COPIONI = {
    "A-1042": [("cerca_ordine", "A-1042"),
               ("rispondi", "Il pacco A-1042 è in consegna, arriva domani.")],
    "A-9999": [("cerca_ordine", "A-9999"),
               ("cerca_cliente", "mario@example.com"),
               ("rispondi", "Non trovo A-9999; l'ordine di Mario è A-1042, in consegna.")],
}
ORDINI = {"A-1042": "in consegna"}
CLIENTI = {"mario@example.com": ["A-1042"]}

def modello(richiesta, osservazioni):
    """Restituisce la prossima azione, scelta in base a ciò che ha visto."""
    return COPIONI[richiesta][len(osservazioni)]

STRUMENTI = {
    "cerca_ordine": lambda k: ORDINI.get(k, "ordine inesistente"),
    "cerca_cliente": lambda k: CLIENTI.get(k, []),
}

def workflow(richiesta):
    """Percorso fisso, deciso dal programmatore: sempre e solo questi due passi."""
    stato = STRUMENTI["cerca_ordine"](richiesta)
    return f"Stato dell'ordine {richiesta}: {stato}", 1

def agente(richiesta, max_giri=5):
    """Il modello decide il passo successivo; il codice esegue e riporta."""
    osservazioni = []
    for giro in range(1, max_giri + 1):
        azione, argomento = modello(richiesta, osservazioni)
        if azione == "rispondi":
            return argomento, giro - 1          # chiamate a strumenti fatte
        osservazioni.append(STRUMENTI[azione](argomento))
    return "Limite di giri raggiunto", max_giri

for r in ("A-1042", "A-9999"):
    print(r, "| workflow:", workflow(r))
    print(r, "| agente  :", agente(r))

# Output:
# A-1042 | workflow: ("Stato dell'ordine A-1042: in consegna", 1)
# A-1042 | agente  : ('Il pacco A-1042 è in consegna, arriva domani.', 1)
# A-9999 | workflow: ("Stato dell'ordine A-9999: ordine inesistente", 1)
# A-9999 | agente  : ("Non trovo A-9999; l'ordine di Mario è A-1042, in consegna.", 2)

Eseguito due volte con Python 3.14.4 (python3 -I), il programma ha stampato l'uscita identica in entrambe. Per A-1042 i due approcci coincidono, e il workflow è più semplice e più economico: una chiamata a uno strumento. Il caso interessante è A-9999: il workflow risponde «ordine inesistente» e si ferma, mentre l'agente vede quella osservazione, sceglie cerca_cliente e arriva a una risposta utile, con due chiamate a strumenti invece di una. Il prezzo della flessibilità è proprio quel secondo giro: in un sistema reale ogni giro è una chiamata al modello, con costo e latenza. La riga che non puoi togliere è il for con max_giri: senza, un copione (o un modello) che non dice mai «rispondi» gira per sempre.

Il listato è uno schema didattico: il copione non è un modello e non dimostra che un modello vero sceglierebbe bene. Mostra solo la struttura, cioè dove sta la decisione (dentro modello) e dove sta il controllo (dentro agente). Il ciclo completo, con modelli e strumenti veri, lo costruiamo negli articoli successivi, a partire da Fondamenti: OODA Loop, ReAct e Tool Calling.

Agente, LLM e chatbot: le differenze che contano

«Chatbot», «LLM» e «agente» si usano come sinonimi, ma descrivono architetture diverse. La tabella le confronta sui punti che cambiano le scelte di progetto.

Nella tabella conta soprattutto l'ultima riga: ogni autonomia in più si paga in prevedibilità. Il chatbot a regole è il più noioso e il più facile da collaudare; l'agente è il più capace e il più difficile da riprodurre. Per questo la scelta non è «quale è più moderno», ma «quanta variabilità del compito giustifica il costo di non sapere in anticipo i passi».

Quando usare un agente, e quando no

Un criterio pratico: se riesci a scrivere sulla carta i passi, nell'ordine, per tutti i casi che ti aspetti, hai un workflow. Un agente ha senso quando i passi dipendono da ciò che si scopre strada facendo e non puoi elencarli prima. Alcuni casi in cui questo accade davvero:

• Assistenza su casi irregolari: l'ordine che non si trova, il rimborso che dipende dalla storia del cliente.
• Ricerca con fonti multiple: la domanda successiva dipende da quanto trovato nella precedente.
• Codice con verifica: scrivere, eseguire i test, leggere l'errore, correggere, con un tetto ai tentativi.
• Analisi esplorativa di dati: l'ipotesi successiva nasce dal risultato dell'interrogazione precedente.

Il filo comune è che il numero e l'ordine dei passi non sono noti all'inizio, e che un errore a metà strada si può recuperare. Quando questo non vale, il vantaggio dell'agente sparisce e restano i costi. Nell'articolo Anthropic citato sopra, gli esempi di impiego sono proprio il supporto clienti e gli agenti di programmazione, dove il risultato si può verificare.

I segnali che l'agente non serve

• Esiste un algoritmo noto: ordinare, validare un formato, calcolare un importo. Una funzione normale è più veloce, gratuita e deterministica.
• La latenza deve essere minima: un ciclo con più chiamate al modello non è compatibile con una risposta in pochi millisecondi.
• L'esito deve essere riproducibile: documenti con formato fisso o decisioni da giustificare identiche a ogni esecuzione.
• I dati sono sensibili e mancano i controlli: senza permessi minimi, tracciamento e approvazione umana, dare strumenti a un modello è un rischio, non una funzione.

Queste voci non si sommano: ne basta una per fermarti. In particolare l'ultima non dipende dal modello ma da ciò che gli permetti di fare, ed è il tema di Security e Safety: Jailbreaking e Guardrails. Prima di costruire un agente, prova sempre il caso più povero: una sola chiamata al modello con il contesto giusto, poi un workflow, e solo dopo il ciclo.

I framework: tre filosofie, non tre gare

Non serve un framework per scrivere un agente: il listato sopra ne è la prova. I framework servono per ciò che sta attorno al ciclo, cioè stato salvato, riprese dopo un errore, approvazioni umane, osservabilità. Le versioni sul registro PyPI il 2026-11-12: langgraph 1.2.21, crewai 1.15.41, ag2 1.3.1, autogen-agentchat 0.7.5, agent-framework 1.26.0, openai-agents 0.24.0. I framework cambiano in fretta: controlla sempre la versione prima di copiare un esempio.

LangGraph

La documentazione ufficiale lo definisce un framework di orchestrazione di basso livello e un runtime per agenti di lunga durata e con stato: si descrive il flusso come grafo di stato condiviso, nodi e archi, mescolando passi deterministici e passi guidati dal modello. Si concentra su esecuzione durevole, streaming e intervento umano, e non impone prompt né architettura di agente. Il pezzo di più alto livello è nel pacchetto langchain: la funzione create_agent, descritta come un involucro minimale e configurabile attorno al ciclo del modello. La guida alla migrazione alla versione 1 dice che prima si consigliava langgraph.prebuilt.create_react_agent e ora langchain.agents.create_agent, e che catene legacy come LLMChain e altre funzionalità deprecate sono nel pacchetto langchain-classic. Lo vediamo in LangChain e LangGraph: Agenti con AgentExecutor e Tools.

CrewAI

CrewAI si descrive come un framework open source che combina le Crews, squadre di agenti autonomi che collaborano su compiti delegati, con i Flows, flussi guidati da eventi che gestiscono stato ed esecuzione. È la scelta naturale quando il problema si divide in ruoli (ricercatore, analista, redattore) e vuoi dichiarare i ruoli più che scrivere il ciclo. Il trade-off è che parte della logica di coordinamento è dentro il framework: più comodo, meno visibile. Ne parla CrewAI: Team di Agenti Collaborativi.

AutoGen, AG2 e Microsoft Agent Framework

Qui lo stato è cambiato di recente e va letto sulle fonti. La documentazione di AutoGen riporta oggi che il progetto è archiviato e non più mantenuto da Microsoft, che sconsiglia l'uso in produzione e che i nuovi utenti dovrebbero partire dal Microsoft Agent Framework, con una guida di migrazione per chi già usa AutoGen. Il repository ag2ai/ag2 segnala invece che il pacchetto ag2 non include più il nome di importazione autogen né le classi classiche, ora raccolte in «AG2 Classic». Se trovi un tutorial con import autogen, controlla a quale pacchetto e a quale versione si riferisce. Il tema è trattato in AutoGen e AG2: Conversazione Multi-Agente Emergente.

La tabella non è una classifica. Se parti da zero e il tuo flusso è sequenziale, nessuno dei tre serve: il ciclo del listato basta. I framework si giustificano quando ti ritrovi a riscrivere salvataggio dello stato, ripresa e approvazione umana, e vuoi smettere di farlo a mano.

Anatomia di un agente: cinque componenti

Ogni agente, con qualunque framework, ha cinque parti. Nel listato le vedi tutte: il modello (modello), le istruzioni (il copione, che in un sistema vero è il prompt di sistema), gli strumenti (STRUMENTI), la memoria (osservazioni) e l'orchestratore (agente).

• Il modello sceglie il passo successivo. Un modello più capace sbaglia meno, uno più piccolo costa meno: la scelta è un compromesso, non una gerarchia.
• Il prompt di sistema dà ruolo, vincoli e formato. Se è vago, il comportamento è imprevedibile; se è troppo rigido, il modello non si adatta.
• Gli strumenti sono funzioni con nome, descrizione e schema dei parametri. La descrizione è ciò che il modello legge per decidere quando usarli.
• La memoria è il contesto corrente (a breve termine) più un eventuale archivio esterno (a lungo termine).
• L'orchestratore è il ciclo che esegue, accumula e si ferma: tiene limiti di giri, timeout e gestione degli errori.

Delle cinque parti, quella su cui si sbaglia più spesso è lo strumento: una descrizione ambigua fa chiamare la funzione sbagliata, e nessun modello compensa uno schema scritto male. Il progetto degli strumenti è in Tool Calling Avanzato: API, Web e Custom Tools, e la memoria in Memory Systems: Context, History e Knowledge Graphs.

Gli standard per gli strumenti: MCP

Il Model Context Protocol (MCP) è, secondo la specifica, un protocollo aperto per l'integrazione tra applicazioni basate su modelli linguistici e fonti di dati e strumenti esterni. La ragione pratica è evitare un adattatore diverso per ogni coppia applicazione-strumento: un server MCP espone strumenti, e ogni client che parla MCP può usarli. Per un agente significa che parte degli strumenti può venire da fuori anziché essere scritta da te, con una conseguenza di sicurezza da non trascurare: ogni server MCP che colleghi allarga ciò che il modello può fare.

Domande frequenti

Che cosa sai fare adesso

Sai distinguere un workflow da un agente e riconoscere nel codice dove sta la decisione. Sai usare il criterio dei passi elencabili per decidere se ti serve davvero un agente, e conosci il costo da pagare: più chiamate, meno prevedibilità, un tetto ai giri da imporre sempre. Nel prossimo articolo, Fondamenti: OODA Loop, ReAct e Tool Calling, apriamo il ciclo e vediamo come il modello propone un'azione e come il programma la esegue.

Il resto della serie sviluppa ciò che qui è solo accennato: l'orchestrazione di più agenti in produzione, test e valutazione degli agenti, il deployment in produzione, il costo dei token, un esempio costruito di assistente di ricerca e, in chiusura, le capacità e i limiti degli agenti.