Graph engineering: dai loop ai grafi di conoscenza

Il 18 luglio 2026 Peter Steinberger ha pubblicato su X una domanda ironica sul passaggio dai loop ai grafi. Hamel Husain l’ha raccolta e ha pubblicato un articolo intitolato Loop Engineering Is Dead. Enter Graph Engineering. In una settimana il termine era ovunque.

Era soprattutto una battuta sulla velocità con cui questo campo conia nuove discipline: siamo passati da prompt engineering a context engineering, poi harness engineering, loop engineering e graph engineering in circa diciotto mesi, con definizioni che si sovrappongono parecchio.

Ma la battuta ha funzionato perché indica qualcosa di reale. Ecco la parte che vale la pena tenere.

Tre cose che si intendono per «graph engineering»

Il termine è arrivato portando con sé almeno tre idee distinte. Gran parte della confusione online è gente che discute passando dall’una all’altra.

1. Grafi di orchestrazione. Progettare un sistema multi-agente come un grafo esplicito invece che come un ciclo while: nodi tipizzati, transizioni tipizzate, checkpoint da cui riprendere. È il territorio di LangGraph e Temporal. È ingegneria vera, e conta soprattutto se costruite infrastruttura per agenti.

2. Grafi di loop. Reti di cicli di auto-miglioramento che si osservano a vicenda. Concettualmente interessante e, per opinione diffusa, il meno azionabile oggi.

3. Conoscenza e memoria strutturate a grafo. Il sapere dell’agente memorizzato come nodi e archi tipizzati che può realmente percorrere, invece di un mucchio di documenti che rilegge e reinterpreta ogni volta.

Se non costruite infrastruttura di orchestrazione — e la maggior parte di noi non lo fa, compresi quelli che guardano gli agenti entrare nello spazio di lavoro — è il numero 3 quello che vi cambia la giornata. È anche il più antico e meglio supportato dei tre: i grafi di conoscenza precedono il termine di decenni.

Perché gli archi battono la ricerca

Ecco l’esempio che lo rende evidente.

Chiedete a un agente: «Perché abbiamo abbandonato Redis per la coda dei job?»

La ricerca full-text vi restituisce ogni documento che contiene «Redis»: dopo un po’ che lavorate, decine di file e nessuno è la risposta. La ricerca vettoriale vi restituisce documenti che somigliano alla domanda, spesso peggio: semanticamente vicini, causalmente irrilevanti.

Un grafo risponde in tre salti:

coda dei job --decided_by--> ADR-007 (coda Postgres)
ADR-007      --supersedes--> ADR-003 (coda Redis)
ADR-003      --caused------> Incidente 2026-03-11

La risposta non è in nessun singolo documento. È nel percorso tra loro. Una ricerca non può recuperare un percorso: recupera nodi e spera che siate voi a collegarli.

E notate il dettaglio decisivo: gli archi sono nominati. supersedes non è caused non è decided_by. Togliete le etichette e tornate a «questi file sono in qualche modo collegati», il che costringe l’agente ad aprirli tutti e a reinferire la relazione: esattamente il lavoro che volevate evitare.

Gli archi tipizzati sono tutto il trucco. Il resto è idraulica.

Il vostro vault Markdown è già all’80 %

Questa è l’osservazione sottovalutata dell’intera discussione: un vault Markdown ben tenuto è già la parte maggiore di un indice GraphRAG.

Pensate a cosa vi dà gratis un vault di note con i wikilink:

• Nodi — un file per idea, fonte o decisione
• Archi — ogni [[wikilink]] è una connessione che qualcuno ha stabilito di proposito
• Risoluzione delle entità risolta per costruzione — [[ADR-007]] è lo stesso nodo ovunque compaia. Niente matching approssimativo, niente collisioni di embedding, niente «queste due menzioni sono la stessa cosa?»

Quest’ultimo punto non è da poco. La risoluzione delle entità è proprio il punto in cui la maggior parte delle pipeline automatiche di knowledge graph crolla in silenzio. Un vault lo aggira perché un umano ha nominato l’entità una volta, e il link è l’identità.

Quello che manca a un vault semplice sono le etichette. [[ADR-007]] vi dice che due note sono collegate. Non vi dice come. Quello è il 20 % restante.

Come appare nella pratica

È la parte attorno a cui è stato costruito Minibase Vault, quindi meglio essere concreti su come funziona che astratti su cosa potrebbe fare.

I nodi vengono dalla lettura. Cliccate l’estensione Minibase su qualsiasi cosa valga la pena tenere — una pagina di documentazione, una RFC, un thread su X, un talk — e atterra come Markdown pulito in una base di conoscenza locale. Niente copia-incolla, niente passaggio di export, niente scheda «lo leggo dopo» che muore al prossimo crash del browser.

Gli archi vengono registrati, con una motivazione. Il vault tiene un _graph.json nella sua radice:

{
  "edges": [
    {
      "from": "AI Research/attention-paper-20260405-1200.md",
      "to": "AI Research/transformer-tutorial-20260408-0900.md",
      "reason": "Both explain the attention mechanism in transformers"
    }
  ]
}

Claude scrive quegli archi da solo, tramite il server MCP del vault, quando legge trasversalmente le vostre note e nota una connessione. Poi emergono come righe Related: nell’_index.md di ciascuna base, così la trama è visibile anche a voi, non solo al modello.

I percorsi si condensano in pagine. Quando un gruppo di note collegate diventa abbastanza denso, Claude può sintetizzarle in una pagina _topic-*.md che cita le sue fonti. La volta dopo che salvate qualcosa in quel gruppo, la pagina di sintesi è già lì da aggiornare. È il passo che compone: il vault diventa più intelligente, non solo più grande.

Gli orfani vengono segnalati. Un passaggio di lint riporta duplicati, note orfane, contenuti obsoleti e gruppi maturi per una sintesi. I grafi si degradano; qualcosa deve accorgersene.

Gira tutto in locale. L’indice di ricerca è SQLite FTS5 con ranking BM25, il grafo è un file JSON, e nulla delle vostre note lascia la macchina.

Dove smorzerei l’entusiasmo

Due riserve oneste, perché è un termine diventato popolare in una settimana, e la popolarità corre più della sostanza.

Gli archi di Minibase portano una motivazione, non un tipo formale. "reason": "Both explain the attention mechanism" è una frase, non supersedes. È molto meglio di un wikilink senza etichetta e molto meno di un’ontologia. Se vi servono relazioni rigorosamente tipizzate per ragionamento multi-salto su larga scala, vi serve un vero database a grafo — e conviene essere onesti sulla manutenzione che comporta.

La maggior parte delle persone non ha bisogno di niente di tutto questo. Se la vostra conoscenza sono cinquanta note, la ricerca basta. I grafi cominciano a rendere quando avete abbastanza materiale da aver iniziato a dimenticare cosa possedete — e quando le domande che fate sono causali («perché abbiamo») invece che lessicali («dove ho letto»).

Il termine «graph engineering» probabilmente non sopravviverà all’anno. L’idea sottostante — che la struttura tra le vostre note vale più del volume delle note — era vera molto prima di avere un nome, e lo resterà dopo.

Cominciate dalla versione noiosa

1. Salvate ciò che leggete come Markdown invece di aggiungerlo ai preferiti. Un preferito è un puntatore a qualcosa che marcisce; un file è qualcosa che avete.
2. Tenetelo in locale, in una sola cartella, un file per fonte.
3. Lasciate che la vostra IA legga l’intera cartella — via MCP, non con il copia-incolla — e fatele domande che richiedono due documenti per essere risolte.
4. Registrate le connessioni che trova. Poi richiedete il mese dopo.

Questo è il graph engineering per chi non rilascia framework di orchestrazione. È context engineering con le connessioni messe per iscritto.

---

Minibase trasforma qualsiasi pagina web in Markdown pulito con un clic, dritto in un vault locale che la vostra IA può cercare e collegare. L’estensione è gratuita con salvataggi illimitati; Minibase Plus (5,99 $/mese o 34,99 $/anno) aggiunge modelli IA, cronologia e trascrizione video. minibase.md.