Gli agenti AI non devono parlare per decidere

Un agente riceve una richiesta, consulta alcuni dati e deve scegliere il prossimo strumento da chiamare. Non deve scrivere una risposta al cliente, non deve comporre un rapporto e non deve convincere nessuno. Deve prendere una decisione. Eppure, in molte architetture, per arrivare a quel semplice passaggio si interroga un modello generativo, si aspetta che produca testo, si prova a ricavarne un JSON e si spera che il risultato rispetti lo schema.

È una soluzione comoda, soprattutto nei prototipi. Ma la comodità iniziale può diventare una tassa permanente su latenza, costi e gestione degli errori. La novità interessante della famiglia Clef di Cloudflare non è soltanto che esiste un altro modello AI. È che rende più esplicita una distinzione architetturale: generare linguaggio e scegliere un’azione sono problemi diversi, anche quando entrambi richiedono di comprendere il contesto.

Il 9 ottobre 2026 Cloudflare ha annunciato Clef-omni, un Clef-flash meno costoso e un Clef più veloce. I tre cambiamenti vanno letti insieme, ma senza confondere le prestazioni dichiarate dal produttore con una garanzia di funzionamento nei propri sistemi.

Una decisione strutturata non è una risposta in prosa

Un LLM generativo è progettato per produrre sequenze di token. Può certamente classificare, instradare richieste e scegliere fra opzioni, spesso con risultati utili. Ma se l’output richiesto è soltanto una delle azioni ammesse, magari accompagnata da un punteggio, la generazione del testo non è necessariamente il modo più diretto per ottenere quel risultato.

I decision model affrontano il problema in un altro modo: ricevono il contesto e un insieme di possibilità definite, poi restituiscono punteggi vincolati a quello schema. Non c’è bisogno di chiedere al modello di raccontare quale scelta ha fatto prima di trasformare il racconto in un dato. Il risultato può entrare direttamente in una fase di routing, classificazione o prioritizzazione.

Questo non rende automaticamente la decisione corretta. Un punteggio non è una prova, e una probabilità dichiarata non è affidabile soltanto perché ha tre cifre decimali. Occorre verificare la calibrazione, la qualità delle etichette, il comportamento sui casi ambigui e soprattutto il costo degli errori. La differenza è che almeno il contratto dell’output diventa esplicito: quali azioni sono ammesse, quale evidenza entra e come si decide quando non fidarsi.

Se un agente deve scegliere fra cinque azioni, il problema non è fargli scrivere una spiegazione elegante. È dimostrare che ha scelto quella giusta e che sa quando fermarsi.

Clef-omni: meno passaggi non significa meno responsabilità

Clef-omni estende il modello decisionale a testo, immagini, audio e video. Cloudflare dichiara di averlo costruito a partire dalla componente di comprensione di Qwen3-Omni-30B-A3B-Instruct, eliminando la parte di generazione vocale e adattando il sistema a punteggi vincolati alle opzioni. L’obiettivo è valutare, nella stessa richiesta, segnali che prima avrebbero potuto richiedere trascrizione, estrazione di fotogrammi e ulteriori passaggi fra modelli.

È una differenza concreta per chi costruisce pipeline. Pensiamo alla classificazione di un’anomalia documentata da una foto e da una registrazione audio: una catena tradizionale può trasformare entrambi in testo e poi chiedere a un altro modello di decidere. Un modello multimodale può invece valutare direttamente gli input originali. Si riducono i punti di integrazione e, potenzialmente, le perdite di informazione introdotte dalle trasformazioni intermedie.

Ma non bisogna scambiare una pipeline più corta per una pipeline verificata. Se il sistema decide sulla base di un video, occorre ancora capire quali dati sono stati acquisiti, con quale qualità, se audio e immagini erano sincronizzati e come ricostruire il percorso che ha portato alla scelta. La semplicità dell’API non elimina l’obbligo di osservabilità. Lo sposta.

Nelle note tecniche di Workers AI Cloudflare indica per Clef-omni un prezzo hosted di 0,15 dollari per milione di token di input e una finestra di contesto da 64.000 token. Anche audio e video vengono contabilizzati come input, secondo regole di tokenizzazione specifiche: confrontare soltanto il prezzo per milione di token testuali sarebbe quindi fuorviante.

Il prezzo scende. Il contesto, invece, si restringe

Il cambiamento più facile da trasformare in titolo è quello di Clef-flash: il prezzo dichiarato passa da 0,09 a 0,038 dollari per milione di token di input. Un taglio notevole. Nello stesso annuncio, però, Cloudflare precisa che la versione ospitata passa da una finestra precedentemente indicata di 64.000 token a circa 24.000 token. I pesi distribuiti per l’esecuzione autonoma non cambiano e, secondo l’azienda, sono stati addestrati per supportare contesti fino a 256.000 token.

Questa è la parte che dovrebbe interessare chi progetta software, più del confronto pubblicitario sul centesimo. Il modello non coincide con il servizio che lo ospita. Stessi pesi non significano stessi limiti operativi, stessa latenza, stesso costo o stesso comportamento sotto carico. La finestra disponibile su Workers AI è un vincolo del servizio hosted; la capacità dichiarata dei pesi in self-hosting non è una promessa che ogni installazione raggiungerà quelle dimensioni con identiche prestazioni.

Cloudflare sostiene che soltanto lo 0,24% delle richieste osservate supera 24.000 token. È un dato interessante, ma riguarda il suo traffico, non il tuo. Se il tuo agente deve valutare tracce operative lunghe, documenti estesi o molte opzioni, quel limite può incidere sulla progettazione del routing. Potresti dover comprimere il contesto, scegliere Clef invece di Clef-flash o cambiare strategia. In ciascun caso il prezzo per token smette di essere l’unica variabile economica.

Un sistema che risparmia pochi millesimi sulla singola inferenza ma deve ripetere le chiamate, troncare informazioni importanti o chiedere interventi correttivi non è necessariamente più economico. Il costo utile è quello di una decisione sufficientemente affidabile, misurato sull’intero flusso.

La velocità si guadagna anche senza cambiare modello

Il terzo aggiornamento riguarda Clef nella versione ospitata. Cloudflare riporta una mediana che, su input di circa 800 token, passa da 262 a 152 millisecondi; su circa 3.400 token, da 616 a 305 millisecondi. Sono misure pubblicate dal fornitore, non un benchmark indipendente del tuo ambiente. Eppure il dettaglio architetturale è più importante del numero: l’azienda attribuisce una parte sostanziale del miglioramento al serving, incluso il passaggio a SGLang, senza distribuire nuovi pesi.

È una lezione che va oltre l’AI. Quando un servizio è lento, la risposta non è sempre comprare un modello migliore o cambiare algoritmo. Contano il runtime, la gestione delle richieste, il batching, la serializzazione, la memoria, la rete e la coda. Chi sviluppa applicazioni lo sa da decenni; con gli agenti sembra che ogni tanto ce ne dimentichiamo, come se il nome del modello potesse assolvere l’intera architettura.

Per una scelta inserita in una sequenza di dieci operazioni, anche poche centinaia di millisecondi possono sommarsi. Ma prima di festeggiare una mediana bisogna misurare anche la coda lunga: p95, timeout, retry e comportamento sotto carico reale. Il benchmark di un singolo endpoint non equivale al tempo necessario a completare un processo.

Un benchmark non ti dice quanto costa una decisione sbagliata

Cloudflare pubblica confronti con altri modelli decisionali su diversi dataset. I risultati non mostrano un vincitore universale: nella tabella dei workflow, per esempio, Clef-omni non supera il Clef testuale su tutti i casi. È coerente con una realtà spesso trascurata: aggiungere modalità di input non implica migliorare automaticamente ogni classificazione. Le valutazioni riportate sono quelle del fornitore e vanno replicate sul proprio dominio prima di usarle come criterio di acquisto o di deployment.

Se un classificatore decide quale strumento un agente può chiamare, un falso positivo potrebbe attivare un’operazione non pertinente; un falso negativo potrebbe bloccare un passaggio utile. In altri contesti le conseguenze sono più pesanti. La soglia di confidenza, il diritto di astenersi, la verifica delle precondizioni e l’eventuale revisione umana devono essere progettati in funzione di quel rischio, non copiati da un esempio di documentazione.

Questo si collega a un principio già discusso parlando di modello e harness negli agenti AI: il risultato dipende dal sistema che circonda il modello. E anche la scelta di quali strumenti rendere disponibili, tema affrontato nell’analisi sul tool retrieval sotto vincoli di budget, è una decisione di architettura prima che una gara fra modelli.

Dove ha senso mettere un modello decisionale

Una possibile architettura parte da una separazione netta. Le regole deterministiche verificano ciò che non deve essere lasciato all’inferenza: autorizzazioni, schema, limiti di spesa, disponibilità delle risorse, vincoli legali o di business. Il modello decisionale interviene dove serve interpretare contesto ambiguo e assegnare punteggi a opzioni ammesse. Un livello di policy trasforma quei punteggi in un’azione, in una richiesta di approfondimento oppure in un rifiuto motivato.

Il modello generativo resta utile dove bisogna spiegare, sintetizzare, negoziare significati o produrre contenuti. Non viene eliminato: smette semplicemente di essere il martello con cui affrontare qualunque chiodo. Se la classificazione è incerta, può entrare in gioco un secondo percorso più costoso, oppure una persona. L’importante è che il fallback sia una scelta esplicita, misurabile e testabile.

Prima di adottare Clef o qualunque alternativa, la prova utile non è una demo con tre esempi perfetti. Serve un dataset rappresentativo, con casi limite, distribuzioni realistiche, misure di calibrazione, costo per decisione corretta, latenza mediana e di coda, tasso di astensione e verifiche sui cambi di versione. Per l’input multimodale aggiungerei test sui file degradati, sul disallineamento audio-video e sulle evidenze mancanti. Se non misuri queste cose, hai soltanto spostato l’incertezza dietro un endpoint più elegante.

La notizia, quindi, non è che Cloudflare abbia inventato la capacità di classificare. È che i modelli decisionali stanno diventando un componente operativo distinto, con scelte proprie su modalità, contesto, serving e costo. La domanda sensata non è se sostituiranno tutti gli LLM. È quante decisioni dei nostri agenti stiamo ancora facendo passare inutilmente attraverso la generazione di testo, e quanto ci costa non aver progettato un confine migliore.