Il vero costo nascosto degli agenti AI: token, latenza e l’illusione dell’intelligenza infinita

Chiunque abbia costruito un agente AI complesso negli ultimi dodici mesi ha imparato una lezione tanto banale quanto ignorata nei pitch deck: l’intelligenza costa, e non in senso filosofico ma in token fatturabili. Ogni parola, ogni istruzione, ogni frammento di contesto si traduce in consumo, latenza e, in ultima analisi, margini erosi. Il mito dell’agente onnisciente che “sa tutto” è tecnicamente elegante e finanziariamente disastroso. Il vero vincolo non è la capacità del modello, ma la quantità di contesto che gli si riversa addosso come se fosse gratis.

Il punto centrale del modello che descrivi, quello delle Agent Skills, è tanto semplice da risultare quasi offensivo per chi ha passato anni a ottimizzare pipeline con embeddings, retrieval e classificatori: carica meno roba possibile, ma al momento giusto. Un principio che ricorda più l’ingegneria dei sistemi operativi degli anni ’70 che l’hype dell’intelligenza artificiale del 2026. Lazy loading, modularità, decomposizione. Non è magia, è disciplina.

Il problema nasce quando si tenta di costruire agenti generalisti con decine di workflow specializzati. Trenta workflow significano trenta blocchi di istruzioni, trenta contesti cognitivi, trenta micro-architetture operative. Caricare tutto upfront significa trasformare il system prompt in una discarica semantica da 150k token, una cifra che non solo impatta i costi ma degrada la qualità stessa del ragionamento. I modelli non “pensano meglio” con più contesto; spesso affogano. La narrativa per cui più dati equivalgono a più intelligenza è un residuo culturale del deep learning pre-Transformer, e continua a fare danni.

La riduzione da 150k a 3k token non è solo un’ottimizzazione, è un cambio di paradigma economico. Si passa da un modello eager, in cui tutto è sempre disponibile, a un modello just-in-time, in cui il contesto è costruito dinamicamente. È lo stesso salto concettuale che ha portato il cloud a sostituire i data center on-premise: paghi per quello che usi, non per quello che potresti usare. Solo che qui la valuta non è il compute puro, ma l’attenzione del modello.

La fase di discovery è, in questo senso, un capolavoro di minimalismo funzionale. Caricare solo il frontmatter YAML, nome e descrizione, significa trattare ogni skill come un’entità latente, una promessa di capacità piuttosto che una capacità attiva. Cento token per skill sono un investimento trascurabile rispetto ai benefici. Il sistema prompt diventa una mappa, non il territorio. Una directory, non un’enciclopedia. È un approccio che ricorda i sistemi UNIX, dove la potenza emerge dalla composizione di strumenti piccoli e ben definiti.

Quando la query utente entra in gioco, il sistema non è sovraccarico di istruzioni irrilevanti. Il modello vede un insieme compatto di opzioni, ciascuna descritta in modo sintetico ma sufficiente per essere selezionata. Qui emerge un altro aspetto interessante: la selezione delle skill avviene senza embeddings o classificatori esterni. È il modello stesso, durante il forward pass, a decidere. Questo elimina un intero layer architetturale, riducendo complessità e latenza. Ironico, considerando quanto l’industria abbia investito negli ultimi anni in sistemi di retrieval sempre più sofisticati per poi scoprire che, in molti casi, il modello è già abbastanza bravo a scegliere.

L’attivazione della skill introduce una gerarchia che, se ben implementata, diventa una leva potente di controllo dei costi. Metadata già presente, corpo della skill caricato solo quando serve, script eseguiti e spesso non reinseriti nel contesto. Questo dettaglio è cruciale. Molti sistemi agentici commettono l’errore di reiniettare tutto, output e codice, gonfiando il contesto a ogni iterazione. Qui invece si mantiene una separazione netta tra ciò che il modello deve sapere e ciò che deve semplicemente usare.

L’iniezione del contesto è il momento in cui l’agente si trasforma. Fino a quel punto è un generalista informato; dopo diventa uno specialista temporaneo. Questa trasformazione dinamica è, in fondo, ciò che rende gli agenti realmente scalabili. Non esiste un agente universale, esistono agenti che sanno diventare specialisti quando serve. La differenza è sottile ma decisiva, soprattutto quando si guarda ai costi operativi su larga scala.

L’esecuzione, orchestrata tramite MCP server e strumenti esterni, completa il quadro. Le skill definiscono il “come”, mentre l’infrastruttura fornisce il “dove” e il “con cosa”. Separare questi livelli permette di evolvere l’uno senza rompere l’altro. È un principio classico dell’ingegneria del software, ma sorprendentemente raro nei sistemi AI, dove tutto tende a essere accoppiato in modo pericoloso.

La fase finale, quella di output e dehydratazione, è probabilmente la più sottovalutata. Scaricare la skill dopo l’uso significa evitare accumuli di contesto che, iterazione dopo iterazione, porterebbero inevitabilmente a una spirale inflattiva di token. Load, execute, unload. Una sequenza quasi zen, che ricorda certe pratiche di gestione della memoria nei sistemi embedded. La semplicità qui non è un vezzo estetico, è una necessità economica.

Dietro questa architettura si intravede una verità più ampia, che molti preferiscono ignorare: l’AI non è limitata dalla capacità dei modelli, ma dall’efficienza con cui gestiamo il contesto. Il vero collo di bottiglia non è la GPU, ma il prompt. Una frase che potrebbe sembrare provocatoria, ma che chi gestisce budget cloud a sei zeri conosce fin troppo bene.

Il parallelo con l’economia è inevitabile. I token sono una risorsa scarsa, e come tale devono essere allocati con criterio. Sprecarli equivale a bruciare capitale. In un mondo in cui le aziende costruiscono agenti sempre più complessi, la differenza tra profitto e perdita può ridursi a poche migliaia di token per richiesta. Su scala, questo diventa milioni. E i CFO, notoriamente meno impressionati dalle demo rispetto agli ingegneri, iniziano a fare domande scomode.

La narrativa dominante continua a essere quella dell’espansione: modelli più grandi, contesti più lunghi, capacità sempre maggiori. Tuttavia, la storia della tecnologia insegna che ogni fase di espansione è seguita da una fase di ottimizzazione. Negli anni ’90 si accumulava hardware, nei 2000 si è imparato a virtualizzarlo, nei 2010 a orchestrarlo nel cloud. Ora siamo nella fase in cui dobbiamo imparare a comprimere l’intelligenza, a renderla frugale. Non è glamour, ma è inevitabile.

Qualcuno potrebbe obiettare che con contesti da milioni di token questo problema diventerà irrilevante. È un’illusione pericolosa. Aumentare la capacità non elimina il costo, lo sposta. Più contesto significa più compute, più latenza, più energia. In un’epoca in cui anche la sostenibilità energetica dei data center è sotto scrutinio, ignorare questi aspetti è strategicamente miope. La Silicon Valley ama vendere l’infinito; la realtà operativa è fatta di vincoli molto concreti.

Il concetto di Agent Skills introduce anche una dimensione organizzativa interessante. Le skill diventano asset riutilizzabili, versionabili, condivisibili. Non più prompt scritti al volo e dimenticati, ma componenti strutturati, quasi come microservizi semantici. Questo apre la porta a ecosistemi, marketplace, standard. E inevitabilmente, a nuove forme di lock-in. Perché se controlli le skill, controlli il comportamento degli agenti. Una dinamica che ricorda da vicino quella degli app store.

Dal punto di vista strategico, la domanda non è se adottare questo approccio, ma quanto velocemente farlo prima che diventi uno standard de facto. Le aziende che continueranno a costruire agenti monolitici si troveranno presto a competere con sistemi più agili, più economici e, paradossalmente, più intelligenti proprio perché meno sovraccarichi. È una di quelle inversioni di logica che il mercato punisce senza pietà.

La provocazione finale è inevitabile. Forse non abbiamo bisogno di modelli più intelligenti, ma di architetture più intelligenti. Forse il futuro dell’AI non è scritto nei parametri, ma nei pattern di utilizzo. In un settore ossessionato dalla scala, la vera innovazione potrebbe essere la sottrazione. Ridurre, selezionare, caricare solo ciò che serve. Il resto è rumore, e il rumore, come sanno bene gli ingegneri e gli economisti, ha sempre un costo.