Workflow agentici che non si rompono: tool calling, umano nel loop, e le cuciture tra i sistemi

L’automazione dei processi aziendali e un agente AI vengono venduti come la stessa cosa, e non lo sono. L’automazione è una pipeline fissa: il passo due segue sempre il passo uno allo stesso modo. Un agente è un loop in cui il modello decide quale passo viene dopo, in base a ciò che una chiamata a un tool ha appena restituito. Entrambi hanno un posto - la maggior parte di ciò di cui un’azienda ha davvero bisogno è automazione con uno o due punti di decisione agentici, non un agente che prende ogni decisione.

L’architettura sottostante, in entrambi i casi, è ciò che determina se sopravvive al contatto con dati reali: come si dà contesto al modello, come si recupera una risposta in una forma di cui il codice possa fidarsi, come il modello arriva ad altri sistemi, e dove una persona deve ancora dire sì. È quell’impianto, non la scelta del modello, su cui passo la maggior parte di un progetto.

1. Context engineering: dare al modello la fetta giusta, non tutto

Il context engineering è il lavoro poco glamour di decidere cosa vede il modello in una data chiamata - quali record, quali turni precedenti, quali istruzioni - e, altrettanto importante, cosa non vede. Riversare l’intera storia di un cliente o un documento intero nel prompt ogni volta non è accuratezza; è rumore che allontana la domanda reale dall’attenzione del modello e gonfia silenziosamente il costo di ogni chiamata.

Lo schema che regge assomiglia più a un problema di ricerca che a uno di memoria: recuperare i due o tre record rilevanti per questo passo specifico, riassumere ciò che è venuto prima invece di ripeterlo alla lettera, e lasciare che l’agente chieda di più solo quando serve. Un workflow che estrae in modo affidabile le cinque righe giuste su diecimila batte uno che le infila tutte e diecimila sperando bene.

2. Output strutturati e tool/function calling sono la vera interfaccia

Un modello che risponde in testo libero e viene fatto il parsing con una regex è dove queste build falliscono silenziosamente in produzione. Gli output strutturati - uno schema JSON entro cui il modello è costretto a rispondere - e il tool/function calling - il modello richiede una funzione specifica con argomenti tipizzati invece di descrivere un’azione in prosa - sono ciò che permette al vostro codice di fidarsi abbastanza di una risposta da agire senza che un umano rilegga ogni output.

Convalido lo schema all’uscita dal modello e di nuovo prima che raggiunga un sistema reale, perché un modello può produrre JSON sintatticamente valido che è comunque sbagliato per la regola di business in questione - una quantità negativa, una data nel passato, una valuta che l’account non supporta. Lo schema cattura gli errori di forma; un secondo strato di validazione, noioso, cattura quelli che sono JSON valido eppure sbagliati.

3. Embeddings e database vettoriale - solo quando la ricerca è davvero il compito

Gli embeddings e un database vettoriale si guadagnano il posto quando il compito è davvero retrieval: trovare i tre ticket di supporto più vicini a questo nuovo, trovare la clausola di un contratto più vicina a questa domanda. Sono lo strumento sbagliato per un piccolo insieme fisso di record che una normale query di database già copre - ho visto un database vettoriale avvitato su un workflow con undici categorie possibili, dove una tabella di lookup sarebbe stata più veloce, più economica e più facile da debuggare.

Quando è lo strumento giusto, ciò che ha davvero bisogno di cura non è il modello di embedding - è cosa viene suddiviso in chunk, come, e quanto resta fresco l’indice dopo che il documento sorgente cambia. Una ricerca vettoriale su chunk obsoleti dà una risposta sicura e sbagliata, e nulla nell’output dell’agente vi dice che è successo.

4. Umano nel loop e orchestrazione delle API: dove si rompe davvero

Il guasto che vedo più spesso non è un cattivo ragionamento del modello - è la cucitura tra due sistemi: una chiamata API che va in timeout e l’agente la ritenta due volte, inviando un ordine duplicato; un webhook che scatta prima che il passo precedente finisca di scrivere; una chiamata a un tool che riesce lato fornitore ma la risposta ricevuta dall’agente dice che è fallita. Orchestrare chiamate tra CRM, fatturazione ed email significa decidere cosa succede in caso di timeout o fallimento parziale prima che accada in produzione, non dopo.

Tutto ciò che invia denaro, cancella un record o manda un’email a un cliente passa per un passaggio di conferma umana prima di scattare - non perché il modello sia inaffidabile in generale, ma perché il costo di un’azione automatica sbagliata è asimmetrico rispetto al costo di un clic in più. Preferisco che una persona approvi venti azioni corrette al giorno piuttosto che l’agente invii automaticamente una fattura sbagliata.

Conclusione: l’agente è il 10% facile

Scegliere un modello e scrivere il primo prompt è davvero la parte facile di un workflow agentico. Il contesto che viene fornito, lo schema che viene validato, la ricerca vettoriale che gira solo quando deve, la logica di retry attraverso tre API, e quell’unico passaggio che un umano continua ad approvare - questo è l’altro 90%, ed è ciò che decide se l’automazione funziona ancora un martedì tra sei mesi con dati che nessuno ha testato. Scrivete tramite il modulo il processo che volete automatizzare, e vi dirò quale 10% è l’agente e quale 90% è ciò che va davvero costruito.