Agenti e Redis

L’articolo originale di Signal Pirate parte da una frase semplice e molto utile per chi progetta sistemi AI reali: un agente non ha una forma, ha dei percorsi. È una buona correzione al modo in cui spesso raccontiamo le architetture agentiche: diagrammi ordinati, sette layer, frecce inevitabili, come se ogni richiesta dovesse attraversare sempre l’intera macchina.

In produzione non funziona così. Una domanda definitoria può fermarsi a contesto e output. Un task operativo può saltare il retrieval semantico e chiamare direttamente un tool deterministico. Un’analisi complessa può invece richiedere knowledge graph, orchestrazione multi-agent e guardrail più severi. La forma dell’agente emerge dalla query, non dal poster architetturale.

Il diagramma è un inventario, non una pipeline

Il punto più importante è distinguere tra componenti disponibili e componenti usati. Input, contesto, RAG, CAG, knowledge graph, orchestrazione, tool, output, guardrail e memoria non sono una sequenza obbligatoria. Sono un inventario di possibilità.

Se li cabli tutti in ogni richiesta, ottieni un sistema più costoso, più lento e più fragile. Se invece tratti ogni layer come una capacità attivabile, il lavoro vero diventa il routing: decidere quale sentiero attraversare per quella query, con quel contesto, in quello stato di memoria.

Questa distinzione evita due errori comuni. Il primo è l’over-engineering: usare multi-agent, planner e grafo quando una risposta RAG controllata bastava. Il secondo è l’under-engineering: trattare un copilota operativo come una chat con memoria quando in realtà servono azioni, permessi, audit trail e fallback.

Perché Redis entra nella discussione

La parte Redis dell’articolo è interessante perché sposta la memoria agentica fuori dalla metafora del file locale. Il nuovo tipo Array proposto da antirez nel PR Redis #15162 introduce una struttura indicizzata, sparsa e interrogabile lato server. Comandi come ARSET, ARGREP e ARINSERT puntano a casi in cui la posizione ha significato: righe di un file, slot temporali, step di workflow, annotazioni sparse, documenti Markdown spezzati in elementi interrogabili.

Per un agente, questo cambia la topologia del knowledge layer. Le skill, le note e i frammenti di conoscenza non devono per forza vivere nel filesystem della singola macchina. Possono diventare dati remoti, condivisi, aggiornabili da più processi e interrogabili con pattern server-side.

Redis come backbone, non come religione

Redis è già naturale per cache, sessioni, code leggere, stream di eventi e stato rapido. Con vector search, memoria agentica e ora l’ipotesi Array/ARGREP, diventa credibile come backbone compatto per molti agenti pragmatici: un solo processo per memoria breve, memoria lunga, retrieval, stato condiviso e segnali tra agenti.

Questo non significa usare Redis per tutto. Se il dominio richiede join complessi, analisi storiche pesanti o reasoning multi-hop su milioni di entità, un graph database o un warehouse restano strumenti sensati. Il punto è più sobrio: non serve partire da uno stack distribuito solo perché il diagramma sembra più maturo. Si parte dal compito, poi si aggiunge complessità quando il dolore è reale.

Il router è il nuovo centro dell’architettura

Se l’agente è un insieme di percorsi, il router è il componente critico. Non deve essere per forza un altro LLM. In domini strutturati, spesso bastano segnali semplici: parole chiave, presenza di entità note, tipo di output richiesto, disponibilità del knowledge graph, rischio dell’azione.

Una richiesta “cos’è il soffritto?” può usare un percorso definitorio. “Converti la carbonara per sei persone” può chiamare un tool deterministico. “Trova i pattern delle ricette napoletane” può interrogare un grafo e poi passare a una sintesi multi-agent. Stesso agente, percorsi diversi.

Il router quindi è un pezzo di prodotto, non solo di ingegneria. Definisce quanto costa rispondere, quanto rischio accettiamo, quando consultiamo memoria, quando usiamo un tool, quando chiediamo approvazione umana e quando degradiamo a una risposta più semplice.

Memoria non significa apprendimento

La parte più delicata è la memoria. Un agente può ricordare, ma questo non vuol dire che impari nel senso forte. I pesi del modello non cambiano. Cambia la rappresentazione esterna: riassunti, note, vettori, eventi, relazioni, errori già visti.

Ogni compressione però è anche una perdita. Un summary sostituisce un pezzo di conversazione. Una promozione a memoria lunga decide cosa è importante. Un decay cancella. Per questo la memoria agentica non va trattata come archivio perfetto, ma come narrazione operativa: abbastanza fedele da guidare il prossimo passo, abbastanza compressa da non saturare il sistema.

Cosa portare in un progetto reale

Per un progetto reale, la lezione pratica è questa:

• disegnare prima i tipi di richiesta, non il diagramma universale;
• decidere quali layer sono obbligatori, opzionali o vietati per ogni classe di query;
• tenere il routing osservabile, con log di PATH e layer saltati;
• usare memoria e retrieval solo quando riducono incertezza, non per abitudine;
• preferire tool deterministici quando il risultato deve essere numerico, transazionale o verificabile;
• trattare Redis come un buon punto di partenza per stato e memoria condivisa, non come una risposta automatica a ogni problema.

La tesi dell’articolo originale è forte perché ridimensiona l’estetica del diagramma. Non stiamo costruendo una creatura con una silhouette stabile. Stiamo costruendo uno spazio di possibilità controllato, in cui ogni query sceglie un percorso.

Glossario tecnico

Agente AI: un sistema che usa un modello linguistico insieme a contesto, tool, memoria e regole di controllo per decidere e agire oltre la semplice risposta testuale.

Layer: una parte funzionale dell’architettura, per esempio input, retrieval, orchestrazione, tool, output, guardrail o memoria.

Routing: la scelta del percorso da far seguire a una richiesta. Decide quali layer attivare e quali saltare.

RAG: Retrieval-Augmented Generation. Prima recupera documenti rilevanti da una base di conoscenza, poi li passa al modello per generare una risposta più fondata.

CAG: Context-Augmented Generation. Usa contesto già preparato o strutturato, come stato applicativo, summary, policy o dati di sessione, senza fare necessariamente retrieval semantico.

Knowledge graph: una rappresentazione di entità e relazioni. Serve quando contano i collegamenti tra concetti, non solo la somiglianza semantica tra testi.

Tool call: una chiamata a una funzione, API, database o servizio esterno. È il modo in cui l’agente passa dal “dire” al “fare”.

Guardrail: controlli di sicurezza, formato, policy, privacy o qualità che validano l’output e riducono errori rischiosi.

Memoria agentica: stato conservato oltre una singola richiesta. Può includere cronologia, preferenze, errori, documenti, vettori, relazioni e risultati precedenti.

Redis Array: nuovo tipo dati proposto per Redis che rappresenta array indicizzati e sparsi. È utile quando la posizione dell’elemento ha significato.

ARGREP: comando proposto per cercare dentro un Redis Array usando pattern, inclusi regex e glob. Per gli agenti può diventare un modo per cercare skill o documenti lato server.

Sistema sparso: struttura in cui esistono pochi elementi popolati dentro uno spazio di indici molto grande. L’obiettivo è non pagare memoria per gli spazi vuoti.