Agenti AI e Architetture Agentiche: dalla logica dei Bot alla produzione A2A

Un motore linguistico, da solo, è un interlocutore passivo. Per costruire un sistema che valuta un problema, pianifica, corregge i propri errori e porta a termine un compito complesso, serve un’architettura radicalmente diversa. Questa guida traccia la mappa esatta di quell’architettura: sette passaggi tecnici che separano un semplice script chiuso da ecosistemi capaci di reale orchestrazione e delega.

L’evoluzione dell’AI agentica non rappresenta una singola tecnologia, ma una successione di capacità emergenti. A ogni livello vengono aggiunte nuove proprietà computazionali che modificano profondamente il comportamento del sistema.

1. SCRIPT BOTS: Il gradino zero

Uno script bot non comprende nulla. È un insieme di condizioni if/else o di pattern matching che mappa input noti a output predefiniti. Zero ambiguità gestita, zero adattamento: se l’input non corrisponde a un pattern previsto, il bot fallisce o risponde in modo generico.

Esempio applicativo

# script_bot.py
# Un sistema totalmente deterministico: prevedibile, ma fragile.
regole = {
    "orari": "Siamo aperti dal lunedì al venerdì, 9-18.",
    "prezzo": "Il prezzo base è di 49€/mese.",
    "contatti": "Scrivici a [email protected]"
}

def rispondi(messaggio_utente):
    testo = messaggio_utente.lower()
    for chiave, risposta in regole.items():
        if chiave in testo:
            return risposta
    return "Non ho capito, prova a riformulare."

>>> rispondi("Quali sono i vostri orari?")
"Siamo aperti dal lunedì al venerdì, 9-18."
>>> rispondi("Posso venire di domenica?")
"Non ho capito, prova a riformulare."  # Il sistema crolla fuori dai binari

Dove si usa ancora oggi: Menu IVR telefonici, automazioni di form, chatbot di primo livello su siti con FAQ statiche. Il vantaggio è la prevedibilità totale: non ci sono allucinazioni perché non c’è generazione di linguaggio.

2. LLMs: L’arrivo della comprensione linguistica

Un modello linguistico (LLM) introduce la prima vera capacità cognitiva: comprendere ed elaborare linguaggio naturale non strutturato. L’LLM qui è isolato: non ha accesso a strumenti esterni, non ha memoria tra una conversazione e l’altra, risponde solo sulla base di ciò che è cristallizzato nei suoi pesi neurali.

Esempio applicativo

# llm_puro.py
# L'LLM può ragionare sul testo, ma la sua conoscenza è congelata.

prompt = "Qual è la temperatura attuale a Milano?"
risposta_llm = "Non ho accesso a dati in tempo reale, "
              "ma a giugno Milano ha in media 24°C."  # Plausibile, ma inutile ai fini pratici

Utile per: Riassunti, riscrittura, classificazione testuale, estrazione di concetti. Il limite strutturale è netto: non c’è modo di agire sul mondo esterno.

3. LLMs + TOOLS: Dal “sapere” al “fare”

Attraverso il function calling, il modello smette di essere un sistema chiuso. Può decidere autonomamente di invocare un’API esterna , meteo, SQL, motore di ricerca, passando parametri strutturati, per poi integrare il risultato nella risposta finale.

Esempio applicativo

# llm_con_tools.py
tools = [{
    "name": "get_weather",
    "description": "Ottiene il meteo attuale per una città",
    "parameters": {"city": "string"}
}]

messaggio = "Che tempo fa a Milano oggi?"

# Il modello non genera testo libero, ma una struttura dati azionabile:
tool_call = {"name": "get_weather", "arguments": {"city": "Milano"}}

# Il sistema esegue la chiamata API reale
risultato_api = get_weather(city="Milano")  # Output: {"temp": 27, "condizioni": "sereno"}

# L'LLM riprende il controllo e sintetizza:
"A Milano oggi ci sono 27°C con cielo sereno."

Il salto concettuale è enorme: l’LLM passa da generatore di testo a orchestratore di azioni.

4. RAG: Ancorare le risposte ai fatti

Il Retrieval-Augmented Generation (RAG) risolve il problema della conoscenza congelata. Recupera documenti da un database vettoriale, li inserisce nel contesto e forza il modello a rispondere basandosi esclusivamente su quei frammenti.

Esempio applicativo

# rag_pipeline.py
domanda = "Qual è la policy di reso della nostra azienda?"

# 1. RETRIEVAL: ricerca semantica nei documenti aziendali
documenti_rilevanti = database_vettoriale.search(query=domanda, top_k=3)

# 2. AUGMENTATION: iniezione del contesto nel prompt
prompt = f"""
Contesto: {documenti_rilevanti}
Domanda: {domanda}
Rispondi SOLO basandoti sul contesto fornito.
"""

# 3. GENERATION
"Il reso è possibile entro 30 giorni dall'acquisto, conservando lo scontrino."

Perché conta: Riduce drasticamente le allucinazioni su documentazione tecnica e policy interne, vincolando l’output a fonti verificabili.

5. AGENTIC MEMORY: Continuità nel tempo

La memoria agentica introduce la capacità di accumulare contesto. Distingue tra cache a breve termine, memoria semantica (fatti generali) e memoria episodica (eventi passati).

Esempio applicativo

# agentic_memory.py
memoria_semantica = {"utente": "Emanuela", "ruolo": "Analyst"}
memoria_episodica = []

def gestisci_richiesta(messaggio):
    # L'agente inietta il passato prima di valutare il presente
    contesto = f"""
    Utente: {memoria_semantica}
    Storico recente: {memoria_episodica[-3:]}
    Richiesta attuale: {messaggio}
    """
    risposta = llm.generate(contesto)

    memoria_episodica.append({"data": "2026-07-02", "evento": messaggio})
    return risposta

6. MCP: Standardizzare gli strumenti enterprise

Il Model Context Protocol (MCP) funge da livello di standardizzazione. Invece di scrivere connettori custom per ogni singolo database o applicativo aziendale, un server MCP espone gli strumenti in un formato universale, agganciabile da qualsiasi agente compatibile.

Esempio applicativo

// mcp_config.json
// L'agente vede automaticamente gli strumenti esposti senza codice di integrazione custom
{
  "mcpServers": {
    "chroma-db": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-chroma"]
    },
    "kusto-db": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-kql"]
    }
  }
}

# Python
class SOCState(TypedDict):
    goal: str
    kql_query: str
    logs: list
    findings: dict
    report: str
    errors: list

# Logica decisionale dell'Orchestratore
if state.get("errors"):
    # C'è stato un problema nel parsing o nell'API
    return "fix_data_agent"
elif not state.get("findings") and len(state.get("logs", [])) > 0:
    # I dati ci sono, ma non sono stati ancora analizzati
    return "run_analyst"
else:
    # Il ciclo è completo
    return "generate_report"