Il tuo Agente AI è stupido e costoso. E la colpa è tua.

Quel retrogusto amaro del fallimento

Parliamoci chiaro. Il tuo nuovo, fiammante agente basato su LLM, quello che doveva cambiare le sorti dell'azienda, è un chiodo. Lento, costoso e imprevedibile. Le risposte arrivano quando ormai il cliente ha già riattaccato, i costi delle API fanno impallidire il direttore finanziario e scalarlo è un incubo che neanche a Kampala nelle notti peggiori. E adesso il team passa più tempo a "mettere pezze" che a innovare. Budget bruciati, notti insonni, e la netta sensazione di aver tirato su un accrocchio che sta in piedi con lo sputo.

Fermi tutti. Prima di dare la colpa al modello, a OpenAI o alla congiuntura astrale, facciamo un respiro. Il problema, quasi sempre, non è l'intelligenza artificiale. Il problema è l'idraulica. L'architettura. È un errore di progettazione così sottile, così banale, che fa ancora più rabbia: la criminale confusione tra Cosa Fa (Strumenti) e Cosa Sa (Risorse). Ignorare questa distinzione è come costruire la Moka del caffè senza il filtro. Sembra una caffettiera, profuma quasi di caffè, ma alla fine ti bevi solo una brodaglia bollente e inutile.

Se non capisci questo, stai solo buttando soldi

Dentro il "cervello" del tuo LLM, ci sono solo due cose che contano davvero. Due. Non venti, non cinquanta. O l'agente deve fare qualcosa, o deve sapere qualcosa.

1. Eseguire un'azione (Strumenti/Tools): Qui si cambiano le carte in tavola. Si modifica lo stato del mondo. create_order, cancel_order, send_email. Un'azione è un verbo. È un evento che lascia una traccia. Anche una ricerca, come search_products(query), non è una lettura passiva: è uno strumento, perché scatena un processo dinamico il cui risultato non è mai garantito a priori. Sono le API che il tuo agente invoca per smuovere le acque.
2. Accedere a dati (Risorse/Resources): Qui si legge, non si scrive. È pura conoscenza contestuale, statica o quasi. Il profilo di un utente (user_profile), il catalogo prodotti, la documentazione interna. Roba che sta lì, ferma, e serve a dare un senso a quello che succede. Le risorse sono i sostantivi. Sono le tabelle del database che l'agente consulta per non fare la figura dell'idiota.

Mescolare questi due concetti è un disastro annunciato. Trattare un'operazione di lettura come get_user_profile(user_id) alla stregua di uno strumento significa costringere l'LLM a un giro del fumo inutile ad ogni singola interazione. È come se un meccanico, per sapere che modello di auto sta riparando, dovesse ogni volta telefonare in motorizzazione. Chiamate superflue, latenza che schizza alle stelle, costi che si impennano e un modello che prende decisioni basate su un contesto confuso. La regola è brutale nella sua semplicità: se cambia qualcosa nel mondo, è uno Strumento. Se informa e basta, è una Risorsa.

Questo è il punto.

Il grande cimitero degli agenti AI (Dati dal campo di battaglia, 2026)

La corsa all'oro degli agenti AI è iniziata. Il mercato globale veleggia verso gli 11 miliardi di dollari nel 2026, con tassi di crescita da capogiro (+45% CAGR). Tutti vogliono un pezzo della torta. Gartner prevede che entro fine anno il 40% delle applicazioni enterprise avrà a bordo un agente AI specializzato. Nel primo trimestre del 2026, l'80% del software nuovo o aggiornato ne includeva già uno. Cifre da bolla speculativa.

Eppure, c'è un dato che nessuno sbandiera su LinkedIn. Un dato sporco, scomodo. Solo il 31% delle aziende ha un agente che gira davvero in produzione. Esiste un "divario di prontezza" che è una voragine in cui finiscono i sogni di gloria e, soprattutto, i budget. La verità amara? "L'88% degli agenti AI non riesce a raggiungere la produzione". Ottantotto per cento. Vanno a gambe all'aria prima ancora di vedere la luce. Quelli che ce la fanno, però, generano un ROI medio del 171%. La linea tra un successo strepitoso e un fallimento silenzioso è sottilissima e si chiama "infrastruttura, governance e framework di valutazione inadeguati". Oltre il 40% dei progetti attuali rischia di essere cancellato entro il 2027 se non si mette ordine.

Il "Silent Token Killer", ovvero la tassa sulla stupidità

Il costo di un'architettura sbagliata non lo vedi nella fattura di OpenAI. È una tassa occulta, un parassita che si nutre di token in silenzio. Noi lo chiamiamo il "Silent Token Killer", l'assassino silenzioso di token. E si manifesta in forme diverse:

• Prompt obesi e chiamate zombie: Prompt che si gonfiano a ogni modifica non tracciata. Workflow con più agenti che si pestano i piedi a vicenda, continuando a chiedere le stesse cose perché nessuno ha spiegato loro la differenza tra sapere e fare.
• Recupero dati bulimico: Pipeline RAG (Retrieval Augmented Generation) che vomitano valanghe di dati inutili, appesantendo il contesto, aumentando la latenza e confondendo il modello.
• Selezione schizofrenica dei modelli: Usare un modello potentissimo (e costoso) per rispondere a una domanda banale, solo perché la logica di failover è stata scritta da un ubriaco.
• La gestione dello stato come un'emorragia: Questo è il vero killer. Ad ogni singola chiamata, l'intero stato della conversazione – prompt di sistema, cronologia, documenti, output degli strumenti – viene impacchettato e rispedito all'API. Paghi il biglietto intero ogni volta. La stragrande maggioranza dei token che bruci in produzione non sono i messaggi dell'utente. Sono lo stato.

Questa inefficienza non è un problema tecnico astratto. È un costo vivo. Ogni microsecondo di latenza, ogni watt di energia sprecato, si traduce in un compromesso tra performance e costi. Un'architettura scadente non solo è "più difficile da interpretare", ma le sue "chiamate non necessarie aumentano i costi dell'API e delle risorse di calcolo". Fine della storia.

L'approccio ThinkPink: meno fuffa, più architettura

A Rosignano Solvay come a Kampala, abbiamo imparato a diffidare delle soluzioni magiche. La nostra strategia è fondata sulla precisione di un artigiano toscano e sulla resilienza di chi deve far funzionare le cose con poche risorse: separazione maniacale tra Strumenti e Risorse e un'orchestrazione LLM che non perdona. Nel 2026, i progetti che spaccano non sono quelli che hanno l'agente più "intelligente". Sono quelli che lo mettono in produzione in modo efficiente e governato.

L'LLM è il cervello, certo, ma un cervello senza un sistema nervoso decente è inutile. Ha bisogno di pianificazione, memoria e un uso degli strumenti che sia chirurgico. Protocolli come il Model Context Protocol (MCP) stanno diventando lo standard per far parlare tra loro agenti e strumenti, con quasi 100 milioni di download. I nostri ragazzi a Kampala lo usano per ridurre al minimo i tempi di risposta e i costi, assicurandosi che ogni pezzo del puzzle faccia solo quello per cui è stato progettato. L'orchestrazione non è un lusso, è il fondamento.

Un messaggio alle PMI italiane: smettete di comprare motori, imparate a guidare

Per una piccola o media impresa italiana, l'idea di competere sull'AI sembra una follia. Ma la partita non si vince a chi ha il budget più grosso. Si vince a chi ha l'architettura più intelligente. Separare strumenti e risorse non è un vezzo da puristi del codice, è una necessità strategica. Riduce la complessità, ottimizza i costi di inferenza (che possono diventare una voragine), e migliora la qualità delle decisioni del modello. Invece di investire in potenza bruta, investite in intelligenza architetturale.

La "function calling" è la chiave che permette a un LLM di interagire con il mondo reale, con i tuoi database, con la tua infrastruttura. Usare il RAG per pescare informazioni da grandi moli di dati e il Function Calling per eseguire operazioni precise o generare output strutturati è la base per ridurre il consumo di token e aumentare la precisione. Questa è la mentalità dei Saggi Ribelli di ThinkPink. Non corriamo dietro all'ultima moda. La smontiamo, capiamo come funziona e la usiamo per risolvere problemi veri.

Avete un accrocchio del genere tra le mani e non sapete da dove iniziare? Scriveteci. Potremmo anche divertirci.