Graph Engineering: come progettare workflow AI che funzionano
Scopri il graph engineering: come progettare workflow AI strutturati che producono risultati migliori della chat infinita. Esempi pratici per partire subito.
L'AI non ti ruberà il lavoro. Ma qualcuno che sa progettare il lavoro intorno all'AI, probabilmente sì. E il graph engineering è esattamente questo: un modo più intelligente di organizzare come l'AI lavora per te.
Quando ho iniziato a esplorare questo approccio, ho capito una cosa fondamentale: la qualità del tuo output AI non dipende solo da quanto è bravo il prompt che scrivi. Dipende da come progetti l'intero flusso di lavoro intorno al modello. In questo articolo ti mostro cos'è il graph engineering, perché funziona meglio della chat infinita con Claude, e come puoi applicarlo ai tuoi progetti reali senza diventare un ingegnere informatico.
Cos'è il graph engineering e perché dovresti conoscerlo
Il modo più semplice per capire il graph engineering è questo: il prompt engineering ti insegna a fare domande migliori all'AI. Il context engineering ti insegna a darle informazioni migliori. Ma il graph engineering ti insegna a progettare il lavoro intorno all'AI , in modo che smetta di vivere dentro una chat infinita e disordinata.
Facciamo un esempio concreto. Immagina di voler validare un'idea di business. Il modo normale è aprire Claude e chiedere: "Dovrei lanciare questo prodotto?" Il modello ti darà una risposta sicura, magari con dimensioni di mercato, competitor, un piano go-to-market. Ti sembra di aver fatto ricerca. Ma se ti fermi un attimo, ti accorgi di una cosa scomoda: un solo modello, in una sola passata, ha deciso cosa contava, ha fatto la ricerca, ha interpretato i dati, ha scritto la raccomandazione e ha valutato la propria risposta. È come chiedere a qualcuno di scrivere la propria recensione di performance e poi sorprendersi quando si descrive come visionario.
La versione graph funziona diversamente. Un planner divide la domanda in angoli di analisi. Un ricercatore studia il cliente, un altro i competitor, un altro la distribuzione, un altro il pricing, un altro i rischi. Poi uno skeptic prova a demolire le evidenze deboli. Infine, un merger trasforma ciò che sopravvive in una raccomandazione di una pagina. E tu approvi prima di agire. L'output finale può ancora essere un documento scritto, ma il lavoro dietro è progettato molto meglio.
Come funziona davvero un workflow a grafo
Quando senti "grafo", pensa a questo: lavori connessi da frecce. Ogni lavoro è uno step del workflow. Le frecce mostrano cosa succede dopo. E le note condivise che si muovono attraverso il workflow sono lo stato , cioè cosa sa il sistema fino a quel momento.
Sembra tecnico per cinque secondi, poi ti accorgi che è esattamente così che funziona il lavoro vero. Prendiamo il customer support. Quando arriva un ticket, il lavoro non è semplicemente "rispondi". Prima devi capire che tipo di problema è. Poi controlli lo storico del cliente. Magari cerchi nella documentazione la policy giusta. Poi prepari una bozza di risposta. Poi decidi se è abbastanza rischioso da richiedere la revisione umana prima di inviarlo. Quando disegni questi passaggi e li colleghi nell'ordine in cui dipendono l'uno dall'altro, ottieni un grafo.
Considera la creazione di contenuti. Se devo scrivere un articolo, il lavoro non è solo "scrivi un pezzo". Un buon articolo parte da ricerca, tesi, esempi, hook, script, idee per il titolo, concept visivi, revisione finale dove mi chiedo: "Suona umano o come un funnel di onboarding SaaS?" Alcuni step devono avvenire in ordine (la tesi prima dello script). Altri possono succedere in parallelo: un ricercatore cerca esempi mentre un altro cerca controargomentazioni. Poi gli output si fondono nello script finale.
Questo è il punto in cui il grafo inizia a ripagare: la maggior parte delle persone usa l'AI in linea retta perché la chat rende tutto sequenziale. Chiedi ricerca, poi sintesi, poi bozza, poi revisione, poi titoli. Funziona per cose semplici, ma quando il lavoro ha più pezzi, la chat lineare diventa lenta, confusa e difficile da verificare.
Agent graph vs knowledge graph: due tipi di grafo
Ci sono due significati diversi quando si parla di "grafo" nell'AI, e questo genera molta confusione.
Il primo è il knowledge graph : aiuta l'AI a ragionare sulle relazioni tra cose. Ad esempio: questo cliente lavora in quest'azienda, quest'azienda usa questo prodotto, questo prodotto si integra con questo tool, questo ticket di supporto riguarda questa feature, questa feature è gestita da questo team. I knowledge graph sono utili perché l'AI spesso fatica a connettere relazioni complesse con il normale RAG, che recupera pezzi di testo simili alla domanda ma non sempre capisce le connessioni tra persone, aziende, eventi.
Il secondo è l'agent graph : riguarda come si muove il lavoro. Un planner passa il lavoro ai ricercatori, i ricercatori lavorano in parallelo, uno skeptic controlla i risultati, un synthesizer fonde le parti, un umano approva la risposta finale. In questo articolo mi concentro sugli agent graph, perché è la versione che puoi iniziare a usare oggi come professionista, founder o piccolo team.
La differenza è semplice: i knowledge graph aiutano l'AI a capire come si connettono le informazioni. Gli agent graph aiutano l'AI a capire come dovrebbe muoversi il lavoro. Alla fine, i migliori sistemi usano entrambi.
Quando usare il graph engineering (e quando no)
Usa il graph engineering quando il lavoro ha step multipli, fonti multiple, percorsi alternativi, controlli, rischio o approvazioni.
Se stai chiedendo all'AI di generare 10 nomi per un progetto, probabilmente non ti serve un grafo. Se vuoi riassumere una email breve, idem. Ma se stai usando l'AI per fare ricerca approfondita, creare un piano go-to-market, fare triage di ticket di supporto, rivedere codice, preparare call di vendita, sintetizzare feedback clienti, o produrre contenuti ricorrenti, è lì che il graph thinking inizia a fare la differenza.
La regola è semplice: usa un grafo quando il lavoro ha step multipli, alcuni step possono avvenire contemporaneamente, e l'output finale richiede verifica prima di contare davvero.
- Ricerca di mercato complessa
- Validazione idea startup
- Workflow di customer support strutturato
- Produzione contenuti ricorrente
- Code review con test e approvazione
Un pattern che funziona bene è il diamante : parti da una domanda, dividi in percorsi paralleli, controlli il lavoro, poi fondi tutto in una risposta. Ad esempio: "Dovrei lanciare un prodotto di bookkeeping AI per merchant Shopify?" Un planner divide la domanda in angoli: dolore del cliente, panorama competitivo, canali di distribuzione, pressione sui prezzi, rischi. Tre ricercatori lavorano in parallelo su questi angoli. Poi uno skeptic attacca le evidenze deboli. Poi un merger crea una raccomandazione finale. E tu decidi se procedere o no.
Come iniziare: dal manuale all'automazione
Questo è il punto dove le persone si complicano troppo la vita. Non partire con LangGraph o framework complessi. Per il tuo primo grafo, puoi eseguirlo manualmente dietro le quinte. Sì, è più lento di un sistema completamente automatizzato, ma è molto più facile da capire. E se la versione manuale non produce lavoro migliore, automatizzarla produrrà solo lavoro mediocre più velocemente.
Il primo passo è disegnare il grafo prima di automatizzarlo. Io lo faccio con una lavagna Excalidraw vuota. Scrivo l'outcome finale in cima. Poi disegno i lavori: planner, ricercatore clienti, ricercatore competitor, ricercatore distribuzione, skeptic, merge, approvazione umana. Poi disegno le frecce: il planner alimenta i tre ricercatori, i ricercatori alimentano lo skeptic, lo skeptic alimenta il merge, il merge alimenta la decisione umana. Questo è sufficiente.
Una volta che funziona tre volte manualmente, allora penso agli strumenti. La versione intermedia è Claude Code , dove ogni step scrive file: plan.md, customer.md, competitors.md, distribution.md, review.md, recommendation.md. Ciò lascia una traccia: puoi vedere cosa è successo, confrontare versioni, riutilizzare la struttura settimana dopo settimana.
La versione avanzata usa LangGraph, n8n, Make o script custom per orchestrare il grafo. LangGraph è utile quando vuoi checkpoint di stato, persistenza, approvazioni human-in-the-loop. n8n e Make sono utili quando il grafo tocca sistemi business reali come Slack, email, Airtable, CRM. Ma ripeto: il tool non è il punto. Il tool viene dopo il workflow. Se automatizzi un workflow che non capisci, ottieni un casino. Se capisci prima il workflow, l'automazione diventa ovvia.
Esempi pratici: support, content, coding
Un grafo di customer support potrebbe iniziare classificando il problema: billing, bug, confusione prodotto, rischio cancellazione. Poi controlla il contesto account: è un cliente nuovo? Ad alto valore? Ha scritto prima? È frustrato? Poi cerca nella documentazione interna. Poi prepara una risposta. Poi un checker rivede accuratezza, tono, rischio. Poi un umano approva tutto ciò che riguarda rimborsi, modifiche account, clienti arrabbiati, rischio legale.
Un grafo di creazione contenuti potrebbe partire da ricerca, poi tesi, poi esempi, poi hook, poi script, poi un checker che chiede: gli esempi sono specifici? Il ritmo funziona? L'hook cattura attenzione? Il testo suona come una persona vera? Poi il grafo si ramifica in idee titolo, concept thumbnail, caption, B-roll.
Un grafo di coding potrebbe partire con un piano, poi un agent modifica il codice, un altro rivede il diff, un altro esegue test, un altro controlla la UI nel browser, un altro cerca edge case, poi un umano approva la pull request finale. Questo è dove stanno andando tutti i tool di AI coding: il modello che scrive il codice è solo una parte del workflow. La leva sta nel planning, testing, reviewing, inspecting e decidere cosa è sicuro shippare.
Errori da evitare e prossimi passi
Un errore comune: più agent non significano automaticamente output migliore. A volte più agent significano più rumore. A volte cinque AI worker ripetono con sicurezza la stessa idea sbagliata. A volte il sistema passa più tempo a coordinarsi che a pensare.
L'obiettivo non è fare il grafo più grande possibile. L'obiettivo è fare il grafo più piccolo che migliora la qualità del lavoro. Un buon grafo dovrebbe rimuovere attese inutili, separare worker da checker, mettere approvazione umana dove gli errori costano caro, fermarsi quando la risposta è abbastanza buona, lasciare dietro stato utile: note, evidenze, bozze, fonti, decisioni.
Il valore compounding reale del graph engineering non è solo che un task diventa migliore. È che il tuo lavoro inizia a produrre memoria. Ogni grafo di customer research crea note clienti migliori. Ogni grafo di contenuti crea esempi e insight su audience migliori. Ogni grafo di support crea feedback prodotto migliore. Il grafo produce il lavoro, ma produce anche la memoria che rende il prossimo grafo più intelligente. Diventa un asset.
Se vuoi iniziare con il graph engineering, ecco come fare. Scegli un workflow che già esegui con l'AI ogni settimana: ricercare idee, preparare episodi podcast, rivedere landing page, analizzare feedback clienti. Scrivi l'output finale in una frase: "Voglio una raccomandazione di una pagina su se quest'idea startup vale la pena testare". Elenca i lavori che farebbe un grande umano: chiarire la domanda, ricercare i clienti, ricercare competitor, cercare distribuzione, cercare rischi, controllare evidenze, fare raccomandazione. Disegna frecce dove il lavoro dipende davvero da un altro step. Aggiungi un gate umano prima della decisione costosa. Poi eseguilo manualmente una volta.
Dopo averlo fatto una volta, inizi a vedere il lavoro AI in modo diverso. Non pensi più "qual è il prompt perfetto?". Pensi "qual è il workflow perfetto?". E poi progetti un percorso che produce quella risposta. Questo è il motivo per cui il graph engineering è un concetto che vale la pena conoscere: è il prossimo passo logico dopo il prompting. Le persone che otterranno di più dall'AI saranno quelle che sanno spezzare il lavoro nei pezzi giusti, dare a ogni pezzo il contesto giusto, controllare l'output e tenere l'umano nel posto giusto.