Agent intelligenti: come bilanciare ragionamento on‑device e capacità cloud

Google attiverà in Google Messages una protezione che, se scelta dall’utente, invia nel cloud parti di chat con numeri sconosciuti per una valutazione con modelli Gemini. L’obiettivo è bloccare truffe che maturano nel tempo. È un opt‑in e partirà “nelle prossime settimane”. All’estremo opposto, LiquidAI rilascia LFM2.5-24B-A2B, un modello “reasoning‑only” pensato per agenti privati che lavorano sul dispositivo, con 131.000 token di contesto e 184 token al secondo su Apple M5 Max. Due mosse diverse, stessa domanda per chi progetta agent: cosa conviene fare sul device e cosa nel cloud.

Il confronto pratico: on‑device vs cloud

LiquidAI dichiara un target esplicito: agent privati, in locale, con catene di ragionamento sempre esplicite prima della risposta. LFM2.5-24B-A2B attiva 2 miliardi di parametri per token, porta il contesto da 32.000 a 131.000 token, e amplia il vocabolario da 65.000 a 128.000 unità con un’espansione in‑place. Sul benchmark LiveClaw, orientato ad agenti e uso di strumenti, totalizza 48,09 punti, contro 38,19 di Qwen3.6-35B-A3B. La stessa fonte segnala che il modello di confronto impiega circa il 50 per cento di parametri totali e attivi in più. L’azienda indica anche picchi di 21.000 token di output al secondo su una singola GPU NVIDIA B300.

Google, invece, inserisce più cervello nel cloud per difendere le chat. L’“enhanced protection” si attiva solo se l’utente la sceglie. Valuta i mittenti non in rubrica. Non sostituisce Scam Detection sul dispositivo, la amplia. L’azienda parla di truffe “a combustione lenta” e di attacchi “nuovi e sofisticati”, con la promessa di cogliere segnali che emergono col tempo. L’analisi remota, afferma, “incrementa e estende” il rilevamento già on‑device.

Tra questi due poli si colloca la pratica di molte aziende. ShipStation Global porta in produzione Deckhand, un agente di help desk IT dentro Slack. Vive in un canale dedicato, risponde alle domande frequenti con una knowledge base curata, interpreta screenshot di errori, e crea o aggiorna ticket in Jira Service Management. Gli autori spiegano di averlo costruito su Amazon Bedrock AgentCore. Qui il cloud serve soprattutto per integrare canali e strumenti interni.

Le leve tecniche per ridurre i compromessi

I modelli locali cercano margini nella progettazione. LFM2.5-24B-A2B eredita 40 layer, blocchi MoE con 64 expert e routing top‑4, e un ibrido tra gated short convolutions e GQA. La novità è d’uso: il modello genera sempre una traccia di pensiero prima della risposta. È “reasoning‑only”. Il throughput dichiarato su Apple M5 Max è 184 token al secondo. Scelte così puntano a far stare sul device compiti di pianificazione e tool use che prima richiedevano il cloud.

Nel cloud compaiono altre manopole. Amazon Bedrock introduce su Grok 4.7 un parametro che regola quanta deliberazione il modello compie prima di rispondere. Si chiama reasoning effort. L’annuncio lo lega agli agenti e ai compiti in più passaggi. Gli autori misurano l’effetto costruendo un agente che chiama strumenti esterni tramite Grok 4.7 e testandolo su tre compiti con una sola risposta corretta, verificata con forza bruta: diagnosticare un’interruzione con due servizi a partire dagli alert, pianificare una manutenzione con vincoli che interagiscono, scegliere migrazioni entro un budget. Eseguono tutti e tre i compiti a ogni livello di reasoning effort per osservare come cambia l’esito.

Una terza leva arriva dall’orchestrazione comportamentale. Un esperimento pubblicato su martinfowler.com il 13 ottobre 2026 mostra che un “behavioral harness” porta GPT‑6 Luna, ottimizzato per il costo, da 3 successi su 10 a 10 su 10. In parallelo, GPT‑6 Sol supera tutte le valutazioni esterne sia con harness sia senza. Con l’harness, Luna raggiunge la stessa affidabilità di Sol nelle verifiche esterne, ma paga meno per ogni esecuzione: 0,273 dollari per run contro 0,406. L’harness aumenta l’uso di token e il tempo di esecuzione. L’effetto, però, dipende dal modello.

Trade‑off operativi: privacy, latenza, costi e controllo

La scelta non è solo tecnica. Riguarda chi controlla il dato, chi aggiorna il sistema, e quanto costa ogni run. Google dichiara un opt‑in esplicito per inviare nel cloud parti delle conversazioni con mittenti non riconosciuti. La funzione si presenta come estensione della protezione esistente, non come prodotto a parte. Il messaggio è chiaro: serve consenso esplicito quando si sposta l’analisi fuori dal dispositivo.

Sul device, LiquidAI pone l’enfasi su agenti “privati” e su catene di ragionamento esplicite. Qui contano la capacità di elaborare contesti lunghi e un throughput sufficiente su hardware locale. LFM2.5-24B-A2B dichiara 131.000 token di contesto e 184 token al secondo su Apple M5 Max. Sono numeri che abilitano sessioni ricche senza uscire dal perimetro del dispositivo.

Nel cloud, la priorità spesso è l’integrazione. Deckhand vive in Slack, usa una knowledge base curata e collega Jira Service Management per creare o aggiornare ticket. È costruito su Bedrock AgentCore. L’obiettivo dichiarato è liberare il team IT da domande ripetitive e ticket di routine, mantenendo tracciabilità e coerenza delle risposte. Qui il valore sta nell’agganciare canali e processi esistenti.

Sui costi, l’esperimento con il behavioral harness offre un criterio operativo. A parità di affidabilità nelle verifiche esterne, contano i dollari per run. In quel setup, Luna con harness costa 0,273 dollari per esecuzione contro 0,406 di Sol. L’harness aumenta risorse e latenza, ma può ribaltare la convenienza relativa tra un modello “ottimizzato per il costo” e un modello “frontier”.

Progetti ibridi e orchestrazione come risposta pratica

I fatti suggeriscono architetture miste. Si può mantenere sul dispositivo la parte di ragionamento ritenuta sensibile o continuativa, come indicano gli agent “privati” di LiquidAI, e inviare nel cloud valutazioni mirate quando serve competenza aggiornata o segnali deboli nel tempo, come fa Google Messages con i mittenti non riconosciuti e l’analisi con Gemini su opt‑in.

Le manopole operative aiutano a governare questa frontiera. Il parametro reasoning effort in Bedrock permette di dosare la deliberazione per task e per agente. L’harness comportamentale mostra che si può innalzare l’affidabilità di un profilo economico fino a matchare un profilo “frontier”, contenendo il costo per run. Insieme, questi strumenti danno controllo su accuratezza, latenza e spesa, senza cambiare forzatamente modello o piattaforma.

Le piattaforme agent colmano il resto. Deckhand usa Bedrock AgentCore per abitare Slack, leggere da una base di conoscenza, e operare su Jira Service Management. Per molte aziende, è questo il perimetro che conta: canali quotidiani, fonti curate, e sistemi di ticketing che garantiscono tracciabilità. L’ibrido nasce qui, dall’incrocio di ragionamento e integrazione.

Cosa cambia per chi progetta e testa agent

Servono metriche osservabili e comparabili. L’esperimento su martinfowler.com misura successi su 10, costo per run in dollari, e dichiara che l’harness aumenta token e tempo di esecuzione. Solo con numeri così si valutano i compromessi tra modelli e orchestrazioni. Sul fronte locale, dati come 131.000 token di contesto e 184 token al secondo su Apple M5 Max offrono un perimetro chiaro per progettare catene di tool use senza uscire dal device. Nel cloud, parametri espliciti come reasoning effort e test con risposta unica verificata a forza bruta aiutano a impostare verifiche end‑to‑end per agenti multi‑passo.

Per il QA, i percorsi ibridi diventano casi di test. Bisogna validare quando scatta l’invio al cloud su opt‑in, come nel caso di Google Messages, e come si comporta l’agente quando alterna fonte locale e servizio gestito. In ambito enterprise, serve controllare la coerenza tra base di conoscenza, risposte nel canale Slack e ticket creati o aggiornati su Jira Service Management, come in Deckhand. La tracciabilità dei passaggi e la documentazione delle policy non sono accessorie, fanno parte del comportamento atteso.

La direzione è operativa: più leve di controllo in piattaforma, più orchestrazione comportamentale, e modelli locali capaci di sostenere ragionamenti lunghi. I benchmark di agent e i test con verifica forte indicati nelle fonti mostrano una via per misurare questi sistemi in produzione. Chi costruisce agent dovrà trattare reasoning effort e harness come parametri di configurazione al pari del modello scelto, perché ormai incidono su affidabilità e costo quanto il modello stesso.