Per due anni "prompt engineering" è stata la parola d'ordine di ogni corso, ogni post LinkedIn, ogni finto esperto che prometteva di insegnarti "il prompt perfetto". Nel frattempo, chi costruisce davvero sistemi AI in produzione è passato ad altro, e la parte curiosa è che nessuno ne parla con la stessa insistenza — nonostante sia molto più decisiva. Proviamo a mettere ordine, perché sono competenze diverse, non versioni upgrade l'una dell'altra.
Prompt engineering: la base, non il traguardo
La prompt engineering è quello che tutti immaginano: scrivere l'istruzione giusta per ottenere la risposta giusta da un modello. Few-shot examples, chain-of-thought, ruoli assegnati al modello ("agisci come..."), formati di output specificati con precisione.
Resta utile, ma nel 2026 il suo peso relativo si è ridimensionato per un motivo strutturale: il divario tra i modelli di punta si è ristretto parecchio rispetto al 2023. I trucchi di prompting che una volta facevano la differenza oggi funzionano più o meno allo stesso modo su qualsiasi modello frontier. Il vantaggio competitivo si è spostato altrove.
Context engineering: quello che quasi nessuno insegna
Ecco il pezzo che manca in molte conversazioni sull'argomento, incluse spesso le mie prime bozze mentali su questi temi: la context engineering.
Non è scrivere un'istruzione migliore. È decidere cosa il modello vede prima di rispondere: quali dati recuperare, in che formato, in che ordine, quali strumenti rendere disponibili, quanta cronologia della conversazione includere, cosa invece tagliare fuori perché rumore. È la disciplina di trattare l'intera finestra di contesto come una superficie di progettazione, non come un campo di testo da riempire con la frase magica.
La ragione per cui conta così tanto è quasi contro-intuitiva: più contesto non significa risultati migliori. Un modello con troppa informazione irrilevante comincia a dimenticare dettagli critici, recupera cose fuori tema, produce errori con sicurezza. Il costo dei token in input, oltretutto, è molto più alto di quello in output — quindi un contesto disordinato non è solo un problema di qualità, è anche un problema di budget.
Fare context engineering bene vuol dire, in pratica: costruire pipeline di retrieval che portano solo l'informazione rilevante, strutturare quella informazione in un formato che il modello può usare senza doverlo reinterpretare, decidere esplicitamente cosa "dimenticare" da una conversazione lunga, e definire con precisione quali tool il modello ha a disposizione in quel momento — non tutti quelli che esistono nel sistema.
Loop engineering: il ciclo che fa di un prompt un agente
Un prompt singolo produce una risposta singola. Un agente, invece, ragiona in cicli: osserva lo stato attuale, decide un'azione, la esegue, osserva il risultato, decide il passo successivo — e ripete finché il compito non è concluso o finché non viene interrotto.
Progettare bene questo ciclo è un lavoro a sé. Vuol dire decidere quando il loop deve fermarsi (condizioni di uscita chiare, non "fino a quando sembra finito"), come gestire un errore in un singolo step senza far collassare l'intero processo, quanti tentativi concedere prima di passare la palla a un umano, e come evitare che il modello giri in tondo ripetendo la stessa azione senza avvicinarsi alla soluzione — un problema molto più comune di quanto sembri quando si costruiscono agenti reali.
Un loop mal progettato è il motivo per cui molti "agenti AI" dimostrativi funzionano benissimo nel video di presentazione e si bloccano al primo caso limite in produzione.
Graph engineering: quando un solo loop non basta
Man mano che un sistema cresce, un singolo ciclio agente-azione-osservazione smette di bastare. Compiti diversi richiedono agenti diversi con responsabilità diverse: uno che pianifica, uno che esegue ricerche, uno che scrive codice, uno che verifica il risultato finale. A quel punto il problema diventa orchestrare più agenti che si passano lavoro tra loro, in un flusso che spesso non è lineare ma si ramifica, si unisce di nuovo, torna indietro quando qualcosa fallisce.
Qui entra la graph engineering: modellare il sistema come un grafo di nodi (agenti, strumenti, punti di decisione) e archi (le condizioni che determinano dove va il flusso). È l'approccio dietro framework come LangGraph, ed è quello che sto approfondendo scrivendo il mio libro sui sistemi multi-agente. La differenza rispetto a un semplice loop è che il grafo permette percorsi condizionali espliciti — se l'agente di verifica trova un errore, il flusso torna all'agente che ha scritto il codice, non semplicemente al passo precedente in sequenza.
Come si incastrano tra loro
Non sono quattro fasi in sequenza né quattro livelli di uno stesso skill. Sono quattro competenze che si sommano, e servono contemporaneamente in progetti diversi:
- La prompt engineering resta la base per ogni singola interazione con un modello, dentro qualsiasi sistema più grande
- La context engineering decide cosa quel prompt ha davvero a disposizione per rispondere bene
- La loop engineering entra in gioco quando il compito richiede più passaggi autonomi di un singolo agente
- La graph engineering entra in gioco quando servono più agenti coordinati, con responsabilità e percorsi diversi
Chi si ferma alla prima, oggi, sta lavorando con un decimo delle leve che ha davvero a disposizione. Il salto di qualità nei progetti AI che sto costruendo — e in quello che sto scrivendo nel libro — sta tutto in queste tre competenze successive, molto più che in un prompt scritto meglio.
Un esempio concreto
Per rendere tutto meno astratto, prendiamo un caso reale: un agente che gestisce il supporto clienti via email.
Prompt engineering. Chiedi al modello: "Rispondi a questa email di un cliente in modo professionale." Ottieni una risposta plausibile, ma il modello non sa nulla dello storico del cliente, delle policy aziendali, o se quel problema è già stato risolto altrove.
Context engineering. Prima di far rispondere il modello, costruisci il contesto: recuperi lo storico ticket di quel cliente da un database, la policy di reso rilevante da una knowledge base tramite RAG, e lo stato dell'ordine da un'API. Passi al modello solo questi pezzi, formattati in modo pulito — non l'intero database. La risposta ora è specifica e accurata, non generica.
Loop engineering. Il compito non finisce con una risposta: l'agente deve osservare l'email, decidere se serve un rimborso, eseguire la chiamata API al sistema di pagamento, verificare che sia andata a buon fine, e solo allora rispondere al cliente. Se l'API fallisce, il loop deve ritentare un numero limitato di volte prima di passare il caso a un operatore umano — altrimenti rischi un loop infinito o un rimborso duplicato.
Graph engineering. Ora immagina ticket di tipo diverso: reso, bug tecnico, domanda commerciale. Costruisci un grafo con un nodo "triage" che smista il ticket, un nodo "reso" con accesso al sistema pagamenti, un nodo "supporto tecnico" con accesso alla knowledge base di prodotto, e un nodo "verifica finale" che controlla la qualità della risposta prima dell'invio — con un arco che torna indietro al nodo giusto se la verifica non passa.
Lo stesso compito, quattro livelli di ingegnerizzazione, quattro risultati completamente diversi in termini di affidabilità.
