Agenti componibili e interoperabili: hooks reattivi, orchestrazione multi‑modello e tracing

Fred Schott ha pubblicato Flue 2 e ha portato gli “Agent Hooks” ispirati a React nel ciclo di vita dell’agente. Amazon, intanto, collega endpoint OpenAI‑compatibili su SageMaker AI al runtime di Bedrock AgentCore senza riscrivere gli agenti. llm‑gemini 0.33 aggiunge Gemini 3.7 Flash e mostra reasoning traces dalla riga di comando. Tesi: gli agenti si muovono verso un modello componibile e interoperabile, con strumenti concreti per scegliere il modello giusto, orchestrare in produzione e osservare il ragionamento.

Un modello di programmazione riattivabile: Flue 2 e gli Agent Hooks

Flue 2 è la prima versione stabile del framework per agenti di Fred Schott. Il cuore sono i “React‑style Agent Hooks”. In Flue, un agente è una funzione JavaScript che si riesegue a ogni turno, prima di ogni chiamata al modello. Questa è la semantica dichiarata: riesecuzione prevedibile a ogni passaggio di dialogo.

Schott racconta un cambio di cornice. All’inizio pensava a “Astro per agenti” o “Next.js per agenti”. Poi ha capito di voler costruire il “React per agenti”. L’enfasi è sulla composizione applicata al ciclo di vita dell’agente: strutturare la logica in unità che si riattivano a ogni turno, con regole esplicite su quando e come scattano.

L’obiettivo è portare nei flussi agentici lo stesso controllo che gli sviluppatori hanno in React. La previsione della riesecuzione aiuta a ragionare sui dati in ogni passaggio di dialogo. Flue 2 si presenta come base stabile del progetto. I React‑style Agent Hooks sono al centro dell’architettura. La società di Schott è stata acquisita da Cloudflare a gennaio.

Questo cambio di modello conta perché rende prevedibile il comportamento nel tempo: ogni turno riallinea stato e logica prima della chiamata al modello. La semantica dichiarata riduce ambiguità sul “quando” e sul “cosa” ricalcolare. Gli hook forniscono un meccanismo per incapsulare capacità che si riattivano con le stesse regole a ogni passaggio.

Orchestrazione multi‑modello per la produzione: SageMaker AI e Bedrock AgentCore

Amazon descrive come collegare endpoint OpenAI‑compatibili serviti su SageMaker AI con il runtime di Amazon Bedrock AgentCore. L’obiettivo è portare in produzione workflow agentici multi‑modello senza riscrivere il framework esistente. Si parte da un ostacolo concreto: mescolare modelli foundation gestiti con modelli propri, ottimizzati per costo o dominio, mantenendo l’impianto attuale degli agenti.

La guida mostra un percorso pratico. Primo passaggio: il deploy di Qwen 3.5 9B su Amazon SageMaker AI. Secondo: integrare quell’endpoint, compatibile con le API di OpenAI, dentro un sistema multi‑agente costruito con Strands Agents. Terzo: consegnare l’intero workflow al runtime di Amazon Bedrock AgentCore. Risultato dichiarato: un’architettura pronta per la produzione che unisce ottimizzazione dei costi, residenza dei dati e flessibilità nella scelta dei modelli, mantenendo agenti specializzati che usano il modello più adatto al compito.

Questa impostazione separa la logica dell’agente dalla scelta del modello a livello di esecuzione. Gli endpoint OpenAI‑compatibili su SageMaker AI entrano nel sistema senza cambiare l’impianto degli agenti; il runtime di Bedrock AgentCore coordina il workflow multi‑modello.

Per i team, il punto pratico è evitare una riscrittura ogni volta che cambia il parco modelli. Si preserva la specializzazione dell’agente, si amplia il catalogo dei modelli e si governano costi e vincoli di residenza dei dati tramite decisioni per agente e per compito. Questo completa la proposta di composizione a livello di codice con una composizione a livello di infrastruttura.

Strumenti client e tracce di ragionamento: llm‑gemini 0.33 e Gemini 3.7 Flash

llm‑gemini 0.33 è uscito il 13 agosto 2026. Aggiunge supporto a Gemini 3.7 Flash e due nuovi modelli di embedding, gemini‑embedding‑2 e gemini‑embedding‑001. Nel changelog compaiono anche gemini‑3.6‑flash e gemini‑3.5‑flash‑lite. Il plugin è compatibile con LLM 0.32. Mostra i reasoning traces e abilita strumenti lato server seguendo il pattern indicato dall’autore.

Il post include un comando di esempio: llm -m gemini-3.7-flash -T CodeExecution 'use python to calculate (factorial of 13) * 3' Il comando attiva l’esecuzione di codice e interroga il nuovo modello dalla riga di comando.

C’è anche un confronto sul “thinking effort” nella generazione di immagini. In Gemini 3.6 Flash era disponibile l’opzione “minimal”. In Gemini 3.7 Flash questa opzione non c’è più. L’autore mostra tre versioni della stessa scena — pellicani in bicicletta — con sforzo alto, medio e basso, e segnala l’assenza di “minimal” nella nuova release. Per chi controlla spesa o tempi di inferenza, la rimozione toglie un gradino di regolazione. Va adeguato il prompt o la scelta del mode.

Questo blocco completa il quadro: nuovi modelli e embedding entrano nelle toolchain; i reasoning traces arrivano allo sviluppatore; e alcune leve di costo/latenza cambiano con l’evoluzione dei modelli.

Cosa cambia per chi sviluppa agenti: interoperabilità, scelta dei modelli e osservabilità

Mettendo insieme i pezzi, emerge una traiettoria pratica.

• Modello di programmazione: Flue 2 fissa una semantica di riesecuzione per turno e introduce gli Agent Hooks ispirati a React. La composizione diventa esplicita e prevedibile.
• Orchestrazione: l’integrazione SageMaker AI + Bedrock AgentCore permette di combinare endpoint OpenAI‑compatibili con il runtime, tenendo agenti specializzati e scegliendo il modello per compito, in un’architettura dichiarata pronta per la produzione.
• Strumenti: llm‑gemini 0.33 porta nuovi modelli, embedding, reasoning traces e strumenti lato server, con un esempio concreto di invocazione e code execution.

Il filo è l’interoperabilità a tre livelli: del codice agente, del runtime e dei client. La semantica di Flue rende gli agenti componibili sul piano del ciclo di vita. L’integrazione di Amazon fa dialogare più modelli senza toccare il framework esistente. Il plugin Gemini aggiunge capacità osservabili nel flusso di lavoro dello sviluppatore. Per i team, questo si traduce in due guadagni operativi: riduzione del costo d’integrazione e maggiore libertà di scelta del modello per vincoli di costo, dominio o residenza dei dati.

Sul piano del QA, i reasoning traces offrono visibilità sul processo di generazione lato client. La riesecuzione per turno in Flue fornisce un punto fisso per valutare il comportamento di un agente a parità di input e stato. L’orchestrazione multi‑modello consente di mantenere agenti specializzati mentre si varia la scelta del modello, senza alterare l’impianto.

Sfide residue e nodi tecnici da monitorare

La composizione reattiva richiede disciplina su stato ed effetti. Concepite l’agente come funzione che si riesegue a ogni turno e verificate dove tenere lo stato e come sincronizzare i dati tra passaggi. La semantica di Flue aiuta a stabilire regole chiare.

L’integrazione multi‑modello introduce complessità operative. Bisogna leggere i profili di costo e latenza per ogni modello e adeguare le scelte per agente. La residenza dei dati resta un vincolo da implementare correttamente anche quando l’architettura è dichiarata pronta per la produzione.

Infine, le manopole del modello possono cambiare. La rimozione di “minimal” in Gemini 3.7 Flash riduce i livelli di controllo sullo sforzo di generazione. I team devono aggiornare prompt e modalità per bilanciare qualità, costo e tempi di inferenza.

Se questi tre fronti — semantica programmativa, orchestrazione e strumenti — continuano a convergere, la differenza competitiva può spostarsi su come le squadre standardizzano hook e tracing nei propri playbook, non su quale singolo modello adottano.