L’adozione dell’intelligenza artificiale nelle imprese sta facendo emergere un problema economico che non può essere risolto semplicemente scegliendo modelli più potenti o aspettando una nuova riduzione dei prezzi delle API. Durante la sperimentazione, aumentare la capacità di calcolo e utilizzare il modello di base più avanzato disponibile può migliorare rapidamente i risultati. Quando però un’applicazione viene portata in produzione e deve gestire migliaia o milioni di richieste, la stessa strategia può generare costi difficili da sostenere.
Una ricerca condotta da Writer mostra che una parte rilevante di questi costi non dipende direttamente dal modello linguistico, ma dall’infrastruttura che lo circonda. Si tratta del livello di orchestrazione che prepara i prompt, gestisce la cronologia, seleziona gli strumenti, recupera le informazioni, coordina eventuali sub-agenti, controlla gli errori e stabilisce quando un’attività deve terminare. Intervenendo su questo livello, i ricercatori hanno ottenuto una riduzione significativa del numero di token utilizzati per ogni attività, un calo del costo delle attività completate con successo fino al 61% e una qualità sostanzialmente stabile, senza modificare, addestrare o mettere a punto il modello di base. L’elemento più importante per le imprese è proprio questo: il sistema di orchestrazione rimane sotto il controllo dello sviluppatore. I miglioramenti possono quindi essere applicati direttamente all’architettura dell’applicazione, senza dover intervenire sui pesi del modello e senza affrontare i costi, i tempi e i rischi di una procedura di fine-tuning.
Una delle principali cause di inefficienza nelle applicazioni agentiche è il cosiddetto “tokenmaxxing”, cioè la tendenza a utilizzare finestre di contesto molto grandi e quantità crescenti di token come sostituti di una progettazione accurata del sistema. Il modello viene incaricato di generare una soluzione, eseguirla, analizzare l’eventuale errore, reinserire nel prompt l’errore stesso insieme ad altre informazioni contestuali e riprovare. Questo comportamento riproduce un metodo comune nello sviluppo software tradizionale, ma nei sistemi basati su modelli linguistici ogni nuova iterazione può richiedere la ritrasmissione di una parte consistente della cronologia precedente. Secondo Waseem AlShikh, CTO e cofondatore di Writer, molti team utilizzano il tokenmaxxing perché rappresenta inizialmente il percorso meno costoso in termini di lavoro ingegneristico e perché riflette il modo in cui gli sviluppatori affrontano normalmente i problemi di programmazione. Dal momento che questa strategia riesce spesso a risolvere le attività di coding, viene applicata automaticamente anche ad altri carichi di lavoro agentici.
Il problema emerge quando il successo occasionale del metodo viene confuso con l’efficienza economica. La fattura finale dipende infatti dalla quantità di token consumati per ogni attività moltiplicata per il prezzo unitario dei token. Molte aziende osservano quasi esclusivamente il secondo valore, confidando nella progressiva diminuzione dei prezzi delle API, ma trascurano il primo. Nei flussi agentici, il numero di token per attività può crescere molto più velocemente di quanto diminuisca il prezzo per token. Ogni iterazione del ciclo ritrasmette un contesto in continua espansione, aggiunge risultati intermedi, errori, output degli strumenti e nuove istruzioni. La riduzione del prezzo unitario finisce così per mascherare un’inefficienza strutturale che continua ad amplificarsi. Il tokenmaxxing determina diverse modalità di fallimento nelle applicazioni aziendali. Attività relativamente semplici vengono instradate automaticamente verso modelli di frontiera più costosi. Il modello linguistico viene utilizzato come un indice di ricerca poco selettivo e la finestra di contesto viene riempita con interi documenti o risultati grezzi, anziché con risposte mirate. I cicli degli agenti vengono lasciati senza limiti rigorosi e possono continuare a generare richieste quando il modello incontra un errore o non riesce a convergere verso una soluzione. Questa dinamica è particolarmente onerosa perché, presso i principali fornitori, i token di output hanno normalmente un costo superiore a quelli di input. Un agente che ragiona troppo a lungo, produce spiegazioni ridondanti, ripete chiamate agli strumenti o genera codice non necessario può quindi consumare il budget in modo silenzioso, pur continuando a sembrare tecnicamente operativo.
Il settore ha già introdotto varie tecniche per contenere il consumo di token e migliorare la velocità di inferenza, ma molte di queste soluzioni trattano il modello come un componente isolato e non intervengono sull’architettura complessiva dell’applicazione. La compressione immediata del prompt riduce la lunghezza del testo in ingresso, ma non corregge il modo in cui gli input vengono sequenziati e ripetuti all’interno di un flusso di lavoro complesso. Un prompt più corto può comunque essere reinviato decine di volte in un ciclo progettato male. Il ragionamento basato su un budget limita il numero di passaggi computazionali consentiti al modello. Questa restrizione può ridurre i costi, ma rischia anche di peggiorare la qualità quando il sistema non è in grado di distinguere le attività semplici da quelle che richiedono realmente più elaborazione. La codifica concisa spinge il modello a produrre una quantità minima di codice e può diminuire i token di output, ma non risolve l’inefficienza nelle chiamate agli strumenti, nel recupero delle informazioni o nella gestione degli errori. La decodifica speculativa utilizza un modello più piccolo per preparare una bozza dell’output che viene poi verificata da un modello più grande. La tecnica può aumentare la velocità di generazione, ma non interviene sulla complessità dell’architettura agentica e non impedisce a un sistema mal progettato di effettuare troppe chiamate o di trascinare un contesto eccessivo. Questi approcci ottimizzano il motore senza intervenire sulla trasmissione. Il modello può diventare più veloce, economico o sintetico, mentre il livello di orchestrazione continua a generare richieste ridondanti, passaggi superflui e cicli non controllati.
Il framework di un’applicazione AI non è soltanto il codice necessario per collegare un’API a un’interfaccia utente. È il sistema che instrada le richieste, formatta gli input, compone il contesto, seleziona gli strumenti, conserva la memoria e trasforma il modello di base in un’applicazione funzionante. Le principali leve di ottimizzazione comprendono la memorizzazione nella cache dei prompt di sistema, la compattazione della cronologia delle interazioni, la gestione degli strumenti, le strategie di recupero delle informazioni e il trattamento degli errori. Sono componenti direttamente accessibili ai team di ingegneria e possono essere modificati senza intervenire sul modello sottostante. Il principio espresso dai ricercatori è che, se l’infrastruttura è il livello che trasforma le richieste rivolte al modello in lavoro effettivamente svolto, è anche il livello che stabilisce il prezzo di quel lavoro. In passato, il framework è stato spesso considerato codice di collegamento provvisorio e sostituibile. Nelle applicazioni aziendali su larga scala deve invece essere trattato come un artefatto software primario, sottoposto a test, versionamento, misurazioni e progettazione rigorosa. Questa impostazione modifica anche il tradizionale dilemma tra possedere internamente una tecnologia e affidarsi a una soluzione esterna. Le imprese possono trascorrere mesi confrontando modelli linguistici differenti e successivamente adottare un sistema di orchestrazione preconfezionato, rinunciando al controllo sul componente che determina gran parte dell’economia unitaria dell’applicazione. Secondo AlShikh, chi possiede l’infrastruttura controlla i costi per attività. Un framework aperto o generalista, progettato per facilitare dimostrazioni e prototipi, non è necessariamente ottimizzato per minimizzare la fattura di una specifica applicazione aziendale.
Per isolare l’impatto dell’orchestrazione, i ricercatori hanno eseguito gli esperimenti su sei modelli di base appartenenti a fornitori e classi dimensionali differenti: Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1 e Palmyra X6, il modello proprietario di Writer. Il confronto è stato effettuato tra un ciclo agentico convenzionale, mantenuto invariato come riferimento, e la versione finale del Writer Agent Harness. Entrambi i sistemi hanno affrontato gli stessi 22 compiti aziendali bloccati. Le prove includevano attività di grounding e recupero delle informazioni, flussi di lavoro articolati in più fasi, uso di strumenti, delega e generazione di contenuti. Mantenendo costanti sia i modelli sia i compiti, i ricercatori hanno potuto attribuire le differenze osservate al livello di orchestrazione. L’implementazione ottimizzata ha ridotto del 41% il costo medio per attività, passato da 21 a 12 centesimi. Il risultato è stato ottenuto soprattutto attraverso una diminuzione del 38% dei token consumati per ogni attività, scesi in media da 14.200 a 8.800. Il sistema ottimizzato delega operazioni circoscritte, come la ricerca, a sub-agenti specializzati. Un sub-agente non riceve l’intero contesto dell’applicazione, ma soltanto lo strumento necessario e la query specifica da eseguire. Recupera i dati pertinenti e restituisce all’agente principale un riepilogo sintetico e ripulito. In questo modo, la finestra di contesto principale non viene riempita con pagine di risultati grezzi, documenti completi, metadati o passaggi intermedi irrilevanti per la decisione successiva. L’agente principale riceve solo le informazioni necessarie per proseguire. La riduzione dei token non ha determinato un peggioramento del tasso di successo. La percentuale di attività completate è passata dal 78% all’81%. I ricercatori considerano l’aumento indicativo, ma non statisticamente significativo a causa delle dimensioni del campione. Il dato rilevante è quindi la stabilità della qualità nonostante il calo dei costi. Anche la latenza end-to-end è diminuita. Il tempo medio necessario per completare un’attività è passato da 48 a 27 secondi, con una riduzione del 44%. Il miglioramento deriva dalla memorizzazione nella cache delle risposte rapide e dall’eliminazione dei cicli di ragionamento che continuavano senza produrre progressi utili.
I risultati non indicano che un’architettura più complessa sia sempre migliore. Gli esperimenti hanno mostrato limiti rilevanti nella delega ai sub-agenti quando vengono utilizzati modelli più piccoli. Gemini Flash 3.5 e Qwen 3.6 hanno ottenuto rispettivamente punteggi di 0,45 e 0,42 nelle attività di delega. Entrambi i risultati sono rimasti al di sotto di una soglia considerata sufficiente per un utilizzo affidabile. L’orchestrazione dei sub-agenti ha superato la soglia di affidabilità soltanto sui due modelli più potenti tra quelli testati. Palmyra X6 ha raggiunto un punteggio di 0,86 e Claude Sonnet 4.6 un punteggio di 0,85. Questo limite evidenzia un compromesso fondamentale. L’aggiunta di istruzioni di coordinamento, schemi, regole di delega e strutture di supporto richiede al modello di comprendere e rispettare un contesto più articolato. Un modello con capacità insufficienti può impiegare una parte eccessiva delle proprie risorse per interpretare l’infrastruttura, sottraendole allo svolgimento dell’attività principale. In queste condizioni, una funzione introdotta per aumentare l’efficienza può ottenere l’effetto opposto, riducendo l’accuratezza e aumentando il numero complessivo di token. La regola proposta è quindi matematica: quando una funzione di orchestrazione aggiunge più token di coordinamento di quanti riesca a eliminarne per uno specifico modello, quella funzione dovrebbe essere rimossa. Nessun componente del sistema è privo di costo.
Una delle indicazioni operative più immediate riguarda la struttura dei prompt di sistema. Le moderne API dei modelli linguistici offrono sistemi di prompt caching, ma il semplice utilizzo dell’API non garantisce che la cache venga sfruttata in modo efficace. Il payload dovrebbe essere suddiviso in una zona stabile e una zona volatile. Nella parte iniziale devono essere collocati gli elementi statici e immutabili, come le regole fondamentali dell’agente, le procedure operative standard e gli schemi degli strumenti, che possono essere particolarmente lunghi. Nella parte finale devono invece comparire gli elementi dinamici, come la domanda specifica dell’utente, lo stato più recente dell’attività o le informazioni appena recuperate. Questo ordinamento consente al sistema di riconoscere e riutilizzare lo stesso prefisso memorizzato nella cache per centinaia di chiamate successive. Se un dato dinamico viene inserito all’inizio del prompt, anche una minima variazione può invalidare il prefisso e costringere il sistema a elaborare nuovamente tutte le istruzioni statiche. La separazione tra zona stabile e zona volatile evita quindi che le stesse regole, gli stessi schemi e le stesse procedure vengano elaborati da zero in ognuno dei numerosi passaggi compiuti da un agente.
Un’altra misura essenziale è l’offload del contesto. Nei sistemi meno efficienti, ogni iterazione viene aggiunta a un prompt monolitico. La cronologia cresce progressivamente fino a riempire la finestra disponibile e viene ritrasmessa quasi integralmente a ogni nuova richiesta. Una progettazione più efficiente sposta la cronologia, gli artefatti intermedi e i risultati precedenti in una memoria esterna recuperabile. A ogni passaggio vengono riportate nella finestra soltanto le informazioni pertinenti all’azione corrente. Quando l’architettura e il modello lo consentono, anche l’utilizzo di sub-agenti con un unico compito può ridurre l’ingombro del contesto. Il sub-agente riceve solo il materiale indispensabile, esegue l’operazione e restituisce una sintesi strutturata. La voce di costo più pesante per molti agenti non è il ragionamento nuovo, ma il continuo reinvio di informazioni che il modello ha già elaborato. La memoria esterna deve quindi essere progettata non come un archivio passivo, ma come un sistema di recupero selettivo capace di fornire il contenuto minimo necessario per ogni passaggio.
L’ottimizzazione economica richiede anche una revisione delle metriche. I team devono misurare il costo per attività completata e i token utilizzati in relazione ai risultati ottenuti, anziché limitarsi al prezzo nominale del modello. Tra le metriche suggerite rientrano i completamenti per milione di token, utili per comprendere quante attività reali vengono portate a termine con un determinato consumo. Il costo per richiesta, considerato isolatamente, può infatti risultare fuorviante quando alcune richieste non producono un risultato valido o attivano lunghe catene di tentativi. Il modello non dovrebbe mai essere incaricato di controllare autonomamente la propria spesa. Un’istruzione come “non utilizzare troppi token” non costituisce un limite affidabile, perché lo stesso sistema che genera il consumo dovrebbe anche decidere quando interrompersi. Il controllo deve essere collocato sotto il modello, nel codice gestito dall’azienda. Ogni attività deve disporre di un budget massimo di token e l’esecuzione deve terminare quando tale budget viene esaurito, senza eccezioni affidate alla discrezionalità dell’agente. Il sistema deve inoltre imporre un numero massimo di passaggi, di chiamate agli strumenti e di livelli di ricorsione. Questi limiti impediscono agli agenti non convergenti di continuare a generare tentativi, deleghe o verifiche che non avvicinano alla soluzione. È necessaria anche una gestione specifica della spesa successiva a un fallimento. Dopo la prima convalida non superata, il budget residuo dell’esecuzione dovrebbe essere ridotto o sottoposto a vincoli più severi. In caso contrario, un’attività problematica rischia di diventare proprio quella più costosa, perché continua ad accumulare nuovi tentativi senza garanzia di successo.
Una struttura di orchestrazione avanzata richiede tempo di sviluppo, test, osservabilità e manutenzione. Durante la fase iniziale di prototipazione, questo investimento può non essere giustificato. Quando l’obiettivo è verificare rapidamente un’idea, può essere più razionale utilizzare un modello robusto con un’infrastruttura leggera, accettando temporaneamente una minore efficienza. In questa fase, la velocità di iterazione può avere un valore superiore al risparmio per singola richiesta. La situazione cambia quando l’applicazione raggiunge volumi elevati, fino a milioni di richieste giornaliere. A quel punto, anche una riduzione apparentemente modesta dei token per attività può produrre risparmi rilevanti, mentre la diminuzione della latenza migliora la capacità del sistema di gestire più utenti con la stessa infrastruttura. I team devono tuttavia evitare di introdurre complessità per principio. L’utilità di ogni componente deve essere misurata separatamente per ciascun modello e per ciascun tipo di attività. Una strategia efficace con un modello di frontiera può risultare controproducente con un modello più piccolo. L’infrastruttura ottimale non coincide quindi con quella dotata del maggior numero di funzioni, ma con quella che produce il miglior rapporto tra costo, affidabilità, velocità e qualità per uno specifico carico di lavoro.
L’idea di utilizzare finestre di contesto come contenitori praticamente illimitati sta diventando economicamente insostenibile. Aumentare la potenza di calcolo applicata a un sistema progettato male non rappresenta una strategia adeguata per le aziende che devono dimostrare un ritorno concreto sugli investimenti nell’intelligenza artificiale. Con l’evoluzione dei modelli di base, capacità come la pianificazione, la selezione degli strumenti e il ragionamento in più fasi saranno sempre più incorporate direttamente nei modelli. Il livello di controllo esterno non scomparirà, ma cambierà funzione. L’infrastruttura dovrà compensare meno frequentemente le debolezze operative del modello e concentrarsi maggiormente sull’applicazione delle regole aziendali. Budget, autorizzazioni, limiti di accesso ai dati, registri di controllo e interruttori di sicurezza deterministici non possono essere affidati esclusivamente ai pesi del modello. Secondo AlShikh, tra cinque anni l’infrastruttura potrebbe essere più snella, ma ancora più importante. Saranno necessarie meno impalcature per guidare il ragionamento e una quantità maggiore di controlli per governare ciò che il sistema è autorizzato a fare. Per quanto un modello possa diventare sofisticato, un componente esterno dovrà continuare a stabilire quanto può spendere, quali informazioni può visualizzare e quali dati o sistemi può modificare. Questo livello di controllo appartiene all’impresa, perché determina contemporaneamente i costi, la sicurezza, la conformità e l’affidabilità dell’applicazione. Esternalizzarlo completamente significa rinunciare al controllo sull’economia unitaria e sulle regole operative del proprio sistema di intelligenza artificiale.