L’agente AI non ha una forma: ha dei percorsi

L’architettura di un agente AI non è una pipeline fissa. Il diagramma a sette scatole — input, contesto, orchestrazione, tool, output, guardrail, memoria — che circola in ogni articolo sul tema descrive la forma massima, non la forma corretta. Gli agenti reali in produzione ne usano quattro o cinque, e il taglio non è arbitrario: dipende dal compito.

Il punto vale anche per chi sta progettando ora il proprio primo sistema agentico in azienda. Partire dall’architettura completa è l’errore più costoso: ogni layer aggiunto è una superficie in più da mantenere, monitorare, debuggare. Aggiungere il sesto layer non rende l’agente più intelligente, lo rende più fragile. Eppure è esattamente quello che accade quando si copia il diagramma canonico senza chiedersi quali pezzi servono davvero.

I sette layer come pool, non come template

Prima di parlare di forme, serve sapere quali sono i mattoni. Sette layer, ognuno con un ruolo distinto, ognuno con un costo operativo e un valore specifico per casi precisi.

Layer 1 — Input e contesto. Tutto quello che entra nel sistema: prompt utente, cronologia conversazione, file e database interni, eventi e trigger (scheduler, webhook), API esterne, sensori. Banale finché arrivano cinque sorgenti, complicato quando arrivano cinquanta. Il lavoro è di normalizzazione, parsing, arricchimento.

Layer 2 — Costruzione del contesto. Tre tecniche con obiettivi distinti. RAG (Retrieval-Augmented Generation) per il recupero semantico su knowledge base ampie. CAG (Context-Augmented Generation) per contesto pre-costruito, stato applicazione, riassunti, view, cache. Knowledge Graph per nodi, relazioni, reasoning multi-hop. Si combinano, raramente si escludono a vicenda.

Layer 3 — Orchestrazione. Chi decide e come. Single agent (loop LLM più tool), planner-executor (pianifica e poi esegue), multi-agent (ruoli specializzati). Pattern di controllo: ReAct, Plan and Solve, routing dinamico, reflection con self-correction. La scelta determina determinismo, costo e latenza dell’intero sistema.

Layer 4 — Tool e azioni. Le mani dell’agente: API e servizi (CRM, mail, calendar), database e query, esecuzione codice, web scraping, altri LLM (embedding, classifier), sistemi interni (filesystem, ERP). Ogni tool è un contratto formale: schema input, formato output, errori previsti. Senza tool, l’agente parla soltanto.

Layer 5 — Output e risultati. Risposta all’utente (testo, JSON, report), esecuzione di azioni (operazioni, invii, update), generazione di contenuti (riepiloghi, insight), aggiornamento stato (scrittura su DB, file, code). Spesso più di una contemporaneamente.

Layer 6 — Valutazione e controllo. I guardrail. Validazione (coerenza, completezza, veridicità, formato), sicurezza (filtri PII, policy, permessi, rate limit), autocorrezione (reflection, retry con strategie diverse, critic agent), feedback umano (approvazione, modifica). Senza guardrail, un agente in produzione è un esperimento.

Layer 7 — Memoria. Trasversale a tutti gli altri. Short-term per sessione, cronologia, stato corrente. Long-term per vector DB, knowledge graph, data lake. Cache per lo stato condiviso ad alta velocità: personalizzazione, continuità, evitare ricalcoli, learning continuo.

Un agente completo usa tutti e sette. Un agente minimo può funzionare con tre: input, orchestrazione, tool. Tutto il resto è opzionale. Il design consiste nel decidere quali opzioni valgono il loro costo per il caso specifico.

Il diagramma a sette scatole mente sempre

Apri un articolo qualsiasi su agentic architecture e trovi la pipeline ordinata: input → contesto → orchestrazione → tool → output → guardrail → memoria. Sequenza fissa, frecce piene, ogni passo collegato al successivo. La realtà è che quasi nessuna richiesta reale attraversa tutti i layer. La maggior parte ne tocca tre, a volte quattro. Il diagramma è la lista completa dei pezzi che potresti usare; l’esecuzione è la scelta dei pezzi che usi per quella query.

Tre esempi concreti chiariscono il punto. Stesso agente, stesso pool di sette layer disponibili, tre query diverse:

• Domanda semplice: Input → CAG → Output. Tre layer, una sola chiamata LLM.

• Task operativo: Input → CAG → Tool → Output → Memoria. Cinque layer, il tool deterministico fa il lavoro pesante.

• Analisi: Input → RAG → Knowledge Graph → Orchestrazione → Output. Cinque layer ma combinazione completamente diversa dalla precedente, non un sottoinsieme.

Le frecce non sono obbligatorie. Sono possibilità. Cambia il modo di leggere il problema: la domanda smette di essere “quale architettura monto?” e diventa “per ciascun tipo di query, quale sentiero seguo nel grafo dei layer disponibili?”.

Quattro casi reali, quattro architetture diverse

Lo stesso vocabolario di sette layer produce architetture radicalmente diverse a seconda del compito. Quattro casi reali, quattro selezioni, ognuna con la propria logica interna.

Caso 1 — Knowledge aziendale (documentazione, FAQ, manuali). Un agente con loop semplice, RAG su corpus interno, tool leggeri, memoria minima fra sessione e vector DB. L’obiettivo è recuperare informazioni affidabili e rispondere in modo coerente. Multi-agent qui è overhead puro. Il knowledge graph aggiunge complessità senza valore: i documenti hanno già la loro struttura. Esempi: helpdesk, policy aziendali, onboarding, manuali tecnici.

Caso 2 — Workflow operativo (automazioni, trading, pipeline). CAG con stato strutturato, memoria veloce in Redis, tool forti (API, DB, esecuzioni), poco o nessun RAG. Servono controllo, determinismo, bassa latenza. Il contesto è stabile e prevedibile: numeri, stati, regole. Il RAG semantico introduce ambiguità dove serve precisione. Ogni millisecondo conta. Esempi: trading algoritmico, ETL, operazioni finanziarie, gestione ordini.

Caso 3 — Ricerca e analisi complessa (OSINT, intelligence, research). RAG combinato con Knowledge Graph, multi-agent con ricercatore, analista e redattore, planner esplicito, tool avanzati (scraping, API specializzate). Le relazioni fra entità contano: serve reasoning multi-hop e collegamenti fra informazioni distanti. Il singolo agente fallisce sulla pianificazione. Il KG diventa la struttura portante, non un accessorio. Esempi: OSINT, due diligence, analisi di mercato, ricerca accademica.

Caso 4 — Copilota aziendale complesso (assistente trasversale). Planner più executor, RAG con memoria a lungo termine, multi-agent più tool più cache, layer di valutazione robusto. Ambiente dinamico, compiti eterogenei, richieste imprevedibili. Servono coordinazione, affidabilità e continuità nel tempo. Qui i sette layer servono davvero. Tagliarne uno è una scelta deliberata, non una semplificazione. Esempi: copilota dipendenti, supporto decisionale, automazione end-to-end.

Quattro casi, quattro architetture, zero coincidenze. Il RAG indispensabile nel caso 1 diventa zavorra nel caso 2. Il multi-agent overkill nel caso 1 è essenziale nel caso 3. Il knowledge graph che fa la differenza nel caso 3 non aggiunge nulla nel caso 1. L’errore comune è partire dall’architettura. Si parte sempre dal compito: l’architettura è un effetto collaterale.

Sei principi che non cambiano al cambiare della forma

Indipendentemente dalla forma scelta, sei principi resistono a qualunque scenario. Non sono best practice: sono il prezzo del primo incidente in produzione. Ignorarli costa caro al terzo mese.

Sono regole noiose. Vengono violate sistematicamente, anche da team senior, perché la prima demo che funziona sembra non averne bisogno. Ne ha bisogno al terzo mese in produzione, quando la base utenti cresce e gli edge case emergono in batteria.

Maggio 2026, antirez sposta una tessera

Il 3 maggio 2026 Salvatore Sanfilippo (antirez, autore originale di Redis) pubblica un post sul nuovo tipo di dato Array per Redis, pronto dopo quattro mesi di sviluppo iniziati a gennaio. La pull request è la numero 15162: specifica scritta a mano, poi affinata con Opus, poi GPT-5.x, poi revisione riga per riga.

Il dettaglio rilevante per chi costruisce agenti non è il tipo di dato in sé. È la combinazione di tre proprietà che rendono questa primitiva diversa da qualunque cosa esista oggi nello stack di memoria agentica.

Rappresentazione sparsa. Il comando ARSET myarray 293842948324 foo non alloca trentuno gigabyte. La struttura interna è una super-directory di directory sliced dense, con slice da 4096 elementi. Indici giganti, memoria proporzionale a quello che si usa davvero.

ARGREP server-side. Ricerca con regex tramite libreria TRE, modalità MATCH/GLOB/EXACT/RE, predicati multipli con AND e OR. La feature nasce per supportare la ricerca dentro file Markdown immagazzinati in array Redis. È esattamente il caso d’uso del knowledge layer di un agente.

ARSCAN proporzionale. Scan in tempo proporzionale agli elementi popolati, non al range dichiarato. Su un array sparso con dieci elementi su un indice da miliardi, lo scan è istantaneo.

Tradotto in linguaggio agentico: il knowledge layer di un agente, che oggi è tipicamente un vault Obsidian su filesystem locale o un vector DB esterno, può diventare una struttura Redis nativa interrogabile lato server con regex, dentro lo stesso processo che già tiene la memoria a breve termine, la cache di sessione e (con i Vector Sets) il RAG. Un solo backend per quattro layer.

Antirez stesso, lo stesso giorno del post, chiarisce su X il punto chiave: con il nuovo tipo Array e il supporto ARGREP è possibile memorizzare nelle chiavi Redis diversi documenti markdown che vengono utilizzati e aggiornati collettivamente da una moltitudine di agenti remoti. La frase importante è “moltitudine di agenti remoti”: il pattern non è single agent locale, è sistema distribuito di agenti concorrenti, magari di fornitori diversi, che leggono e aggiornano lo stesso set di documenti.

Tre cose, in ordine. Primo: i documenti che l’agente legge non sono file su disco, sono chiavi Redis accessibili in rete. Cambia la topologia: niente filesystem condiviso, niente sync. Secondo: il pattern di accesso è KEYS per scoprire l’indice più ARGREP per filtrare il singolo documento. Discovery e retrieval su due livelli, entrambi server-side. Terzo: gli agenti sono una moltitudine. Concorrenti, distribuiti, eterogenei.

La direzione è coerente con il resto del progetto Redis. Aprile 2026, dal blog ufficiale: Long-Term Memory Architectures for AI Agents. Una settimana dopo, il Redis Agent Memory Server entra in alpha. Il messaggio è chiaro: Redis non vuole essere “anche utile” per gli agenti, vuole essere il backbone di default.

Un solo processo per sette ruoli

L’argomento “usa Redis come backbone agentico” non è marketing, è una constatazione architetturale. Contando quanti dei sette layer un Redis 8.x ben configurato può coprire si arriva a un numero scomodo per chi vende stack ML compositi.

Un solo processo, sette ruoli. Non significa “fai tutto con Redis”: significa che la linea di taglio tra cosa tenere in Redis e cosa spostare altrove è molto più alta di quanto sembri. Per la maggior parte degli agenti reali in azienda, “Redis più un LLM” copre i sette layer. Postgres, Neo4j, Pinecone diventano necessari solo quando il caso lo richiede davvero.

Onestamente: funziona finché i vincoli restano gestibili. Quando la scala cresce, quando servono join complessi su entità eterogenee, quando le query analitiche multi-hop diventano la norma e non l’eccezione, Redis come backbone unico inizia a stridere. Il punto non è “Redis è la soluzione finale”: è che il punto di rottura è molto più lontano di quanto la cargo cult dello stack ML tipico suggerisca. Conviene partire da qui e migrare quando il dolore reale si manifesta, non prima.

Tre query, tre sentieri nello stesso diagramma

Un esperimento concreto rende il principio visibile. Un assistente di cucina italiana costruito su Redis 8 come backbone unico, scelto perché il dominio è universalmente comprensibile: convertire una ricetta per N persone, riconoscere uno stile regionale, trovare pattern fra preparazioni. La tesi non cambia rispetto a un dominio enterprise.

Tre query, tre sentieri reali nel diagramma dei sette layer. Il codice stampa il PATH attivo e i layer SKIPPED ad ogni run.

Query 1 — domanda semplice: “Cos’è il soffritto?”. Path: Input → CAG → Output → Guardrail. Layer saltati: RAG, KG, Orchestration, Tool, Memory (write). La definizione è nel system prompt CAG. Una sola chiamata LLM, output diretto. Niente retrieval, niente tool, niente memoria persistente.

Query 2 — task operativo: “Convertimi la Carbonara per 6 persone”. Path: Input → CAG → Tool → Output → Guardrail → Memory. Layer saltati: RAG, KG, Orchestration. Il routing rileva ricetta più numero di persone. Chiama il tool deterministico convert_servings che parsa gli ingredienti e li scala. L’LLM impagina il risultato, la memoria di sessione registra l’interazione.

Query 3 — analisi multi-hop: “Pattern delle ricette napoletane”. Path: Input → KG (ARGREP) → Orchestration (multi-agent) → Output → Guardrail. Layer saltati: CAG (verbatim), RAG, Tool, Memory (write). Il KG contiene sei ricette. Il filtro ARGREP "stile:.*napolet" trova le tre napoletane. Multi-agent: un researcher (Haiku) estrae i fatti, un analyst (Sonnet) sintetizza i pattern. Niente RAG perché il KG è già pieno di contesto.

Tre query, tre sentieri davvero diversi. Non sottoinsiemi annidati: combinazioni differenti. La query 1 attraversa quattro layer, la 2 ne attraversa sei, la 3 cinque, ma il sentiero della 3 non passa per il Tool della 2, e quello della 2 non tocca KG e Orchestration della 3. Stesso agente, stesso pool, sentieri distinti.

Il pezzo che rende efficiente il sentiero analitico è un modulo Python che riproduce le semantiche di ARSET/ARGREP/ARINSERT del PR antirez sopra primitive Redis disponibili oggi (Sorted Set più Hash). L’API è la stessa che esporrà il PR a merge avvenuto. Quando atterra in master, si sostituisce la classe con i comandi nativi senza toccare il resto del codice.

class RedisArray:
    def arset(self, key: str, index: int, value: str):
        # sparse: salviamo solo gli indici popolati in un Sorted Set
        self.r.zadd(f"{key}:idx", {str(index): index})
        self.r.hset(f"{key}:val", str(index), value)

    def argrep(self, key: str, pattern: str, mode="RE"):
        # lato server (mock): regex su tutti i valori popolati
        vals = self.r.hgetall(f"{key}:val")
        rx = re.compile(pattern)
        return [(int(i), v) for i, v in vals.items() if rx.search(v)]

    def arinsert(self, key: str, value: str) -> int:
        last = self.r.zrange(f"{key}:idx", -1, -1, withscores=True)
        next_idx = int(last[0][1]) + 1 if last else 0
        self.arset(key, next_idx, value)
        return next_idx

L’output della demo mostra esattamente la differenza riga per riga: nessuna delle tre query attraversa tutti i layer, nessuna è un sottoinsieme banale di un’altra. La query 2 chiama un tool che la 1 non chiama, la 3 attiva un’orchestrazione multi-agent che la 2 non tocca, la 1 è un sentiero piatto che le altre non fanno.

Il router decide la forma, non il programmatore

Il componente che decide quale sentiero attivare è il router, deliberatamente deterministico: zero token bruciati per classificare query banali. Tre segnali, tre euristiche, fallback a knowledge form se nessuna scatta.

def decide_form(query: str, mem: Memory) -> Form:
    q = query.lower()

    # 1) domanda definitoria → CAG-only
    if any(k in q for k in ["cos'e'", "definizione", "spiega"]):
        return Form.KNOWLEDGE

    # 2) "pattern", "stile X" + KG popolato → analisi multi-agent
    if any(k in q for k in ["pattern", "in comune"]) or detect_style(q):
        if mem.kg.size() >= 2:
            return Form.ANALYTIC

    # 3) ricetta nota + numero di persone → tool deterministico
    if detect_recipe(query) and detect_servings(query):
        return Form.OPERATIONAL

    return Form.KNOWLEDGE  # default sicuro, costa pochissimo

Tre regole, niente classifier LLM. Funziona perché il dominio della cucina ha pattern lessicali stabili: “cos’è”, “per N persone”, “napoletana”, “in comune”. In un dominio meno strutturato vale la pena aggiungere un fallback a Haiku, ma solo come ultima istanza. Il piacere di questo approccio è che la forma non è configurata: emerge. La query 3 è analitica solo perché il KG ha già due o più ricette. Su un’installazione a freddo verrebbe degradata a knowledge. L’agente si adatta a quello che ha.

Tre limiti onesti del modello

Il sistema funziona ma ha punti deboli. Tre, in particolare, da dichiarare senza eufemismi.

Il PR antirez non è ancora merged. ARSET, ARGREP e ARINSERT sono in review. La latenza sarà diversa quando atterrerà la versione nativa: sicuramente più bassa, probabilmente molto. Il codice resta uguale, l’API è la stessa, ma i numeri di benchmark che si misurano oggi su un wrapper Python non sono quelli che si vedranno a merge avvenuto.

Il routing deterministico copre solo i casi facili. Le euristiche del decisore funzionano per un dominio circoscritto con vocabolario stabile. Su un dominio diverso vanno reimpostate. Per agenti con migliaia di query al giorno e dominio aperto, l’unica strada è il fine-tuning di un classifier piccolo. Non c’è scorciatoia.

Memoria non è apprendimento. L’agente ricorda, non impara nel senso forte: i pesi dell’LLM non cambiano. Se sbaglia in modo sistematico su un certo tipo di query, lo continua a sbagliare. La reflection alza un alert, la memoria di errori riduce la frequenza, ma il bias di base resta. Senza un loop di fine-tuning vero, “imparare” è una metafora.

Il design vero è il routing

Tutto quello che precede converge in una frase: l’agente non ha una forma, ha dei percorsi. La conseguenza per chi progetta sistemi del genere in azienda è un cambio di mestiere, con tre implicazioni concrete.

Il design vero è il routing. Il valore di un agente sta nelle decisioni che prende su quali componenti usare per ogni query, non nell’inventario dei componenti che monti. Cambia il livello del lavoro: dal cablare una pipeline al disegnare un grafo di scelte. È un compito diverso, richiede competenze diverse, produce metriche diverse.

Il collo di bottiglia è il decisore. Migliorare il RAG serve poco se il router lo chiama nei casi sbagliati. Migliorare il knowledge graph serve meno se non viene mai consultato. La qualità che paga sta nelle euristiche di routing, non nei layer in sé. Quasi tutti gli sforzi di ottimizzazione che si vedono in produzione sono allocati male: si rifinisce il componente più visibile invece del componente più decisivo.

Il deliverable è uno spazio di possibilità, non un agente. Quello che si mette in produzione è un sistema in cui molti agenti possibili coesistono, e quello effettivo emerge query per query dal routing. Cambia la query, cambia l’agente. La forma è una proprietà emergente, non una scelta a priori. Per i CTO che approvano budget AI questa è la frase da incorniciare: non si compra un agente, si compra uno spazio di comportamenti possibili.

Non è RAG contro CAG, non è single contro multi-agent, non è Redis contro Postgres. È la differenza fra oggetto e processo: l’agente non è una cosa, è un comportamento. Chi lo capisce smette di costruire pipeline e inizia a costruire grafi di decisione. Chi non lo capisce continua a sommare layer pensando di aumentare l’intelligenza, e ottiene solo più superfici di fallimento da gestire.

La forma giusta dell’agente, in fondo, non è un grafo di layer. È il modo in cui si sceglie quanta complessità tollerare in cambio di quanta capacità di rispondere. Ogni layer aggiunto è una promessa di feature e un debito tecnico simultanei. La scelta migliore, spesso, è quella di non aggiungerlo affatto.