Approfondimento
Come gli agenti AI diventano componenti di produzione: composizione, runtime e integrazione
Testo scritto con l’intelligenza artificiale a partire da fonti pubbliche, senza revisione umana prima della pubblicazione.
Negli ultimi mesi gli agenti AI passano da esperimenti a componenti di produzione grazie a nuovi paradigmi di sviluppo (Flue 2 e Agent Hooks) e a integrazioni cloud‑native e operative (SageMaker + Bedrock AgentCore, osservabilità, browser tool) che risolvono i problemi pratici di deploy, monitoraggio e integrazione con sistemi legacy.
“Decine di migliaia” di modifiche l’anno su portali assicurativi senza API moderne. Amazon propone a un agente AI di entrare nel browser, leggere, cliccare, compilare moduli al posto degli operatori. Lo fa con Bedrock AgentCore Browser Tool, che apre una sessione dedicata e controllata per automatizzare interfacce web legacy. La tesi: gli agenti escono dagli esperimenti quando uniscono un modello di sviluppo prevedibile a strumenti gestiti per esecuzione, osservabilità e integrazione. Qui si saldano due linee: astrazioni di codice come gli “Agent Hooks” di Flue 2 e capacità cloud‑native come runtime, tracing e automazione via browser.
1) Tesi e quadro operativo
Il problema è concreto: combinare controllo sul ciclo di vita dell’agente, scelta del modello per compito e integrazione con applicazioni che non espongono API moderne. Amazon risponde con un runtime pensato per orchestrare agenti e modelli diversi senza riscrivere i framework, più strumenti di osservabilità e un browser gestito per i sistemi legacy. In parallelo, Flue 2 definisce una semantica chiara di riesecuzione e introduce la composizione via hook nello stile di React, applicata al flusso dell’agente.
2) Composizione e ciclo di vita: cosa introduce Flue 2
Fred Schott rilascia Flue 2 come prima versione stabile del framework e mette al centro i “React‑style Agent Hooks”. In Flue, un agente è una funzione JavaScript che “si re‑renderizza a ogni turno”, prima di ogni chiamata al modello. La riesecuzione prevedibile è la semantica dichiarata: ogni passaggio di dialogo innesca una nuova esecuzione dell’agente. Schott racconta il cambio di cornice durante lo sviluppo: non l’Astro o il Next.js per agenti, ma “forse nessuno ha ancora costruito il React per agenti”. Il fondatore di Astro presenta Flue 2 come base stabile del progetto, con i React‑style Agent Hooks al centro. La sua società è stata acquisita da Cloudflare a gennaio.
Un altro tassello della proposta riguarda la definizione stessa di agente. Secondo Schott, a caratterizzare un agente è l’“harness” che ne orchestra il ciclo di vita. L’obiettivo dichiarato è portare nei flussi degli agenti la stessa composizione che gli sviluppatori usano con React, ma sul ciclo di vita dell’agente.
3) Deploy multi‑modello e runtime: l’approccio Amazon
Amazon descrive un percorso pratico per agenti multi‑modello senza riscrivere il framework esistente. La guida mostra come collegare un endpoint OpenAI‑compatibile su SageMaker AI con il runtime di Amazon Bedrock AgentCore, mantenendo agenti specializzati che scelgono il modello più adatto al compito. L’esempio operativo parte dal deploy di Qwen 3.5 9B su Amazon SageMaker AI; integra quell’endpoint in un sistema multi‑agente costruito con Strands Agents insieme a modelli su Amazon Bedrock; e consegna l’intero workflow al runtime di Amazon Bedrock AgentCore.
L’obiettivo dichiarato è portare in produzione workflow che combinano modelli foundation gestiti e modelli propri, ottimizzando i costi, garantendo la residenza dei dati e mantenendo flessibilità nella scelta dei modelli. La proposta punta a integrare modelli differenti senza riscrivere gli agenti e a lasciare che ogni agente usi il modello più adatto al compito.
4) Osservabilità e limiti operativi
Amazon chiarisce i confini dell’osservabilità. AgentCore Observability offre tracing e analytics nativi solo per agent eseguiti sul runtime AgentCore in AWS. Se l’agente gira altrove, la telemetria va inviata in modo esplicito, con auto‑instrumentazione via AWS Distro for OpenTelemetry (ADOT) per alimentare il dashboard. Il post inquadra casi con Strands Agents, LangGraph e CrewAI, eseguiti su Amazon EKS, Amazon ECS e AWS Lambda, ma anche on‑premises o su cloud come Google Cloud Platform e Microsoft Azure.
AWS inquadra Amazon Bedrock AgentCore come piattaforma per costruire, collegare e ottimizzare agent con vari framework e modelli. All’interno, la funzione di Observability fornisce tracing, monitoring e analytics che non arrivano “out of the box” dagli strumenti generici dei provider cloud o dai data center aziendali. Il supporto è immediato quando l’agent gira su AgentCore in AWS; negli altri ambienti serve configurare l’invio dei dati al dashboard.
5) Integrare sistemi legacy: il Browser Tool per flussi UI
Molti processi aziendali non offrono API moderne. Amazon descrive portali assicurativi con “decine di migliaia” di modifiche annuali e cita frizioni simili in sanità, manifattura, retail e servizi finanziari, dove applicazioni critiche espongono solo HTML renderizzato lato server. Qui propone Bedrock AgentCore Browser Tool. Il servizio apre una sessione dedicata, controllata e protetta in cui un agente può eseguire i passaggi della UI come farebbe un operatore umano: navigare, leggere, cliccare, compilare moduli. Evita scripting fragile e wrapper su API che non esistono.
La combinazione con Strands Agents punta a orchestrare questi flussi a volume, gestendo percorsi diversi dentro il perimetro della sessione predisposta. Il caso assicurativo definisce il perimetro operativo: aggiornare coperture e intervenire su schermate stratificate direttamente nella UI, senza introdurre nuove API. L’obiettivo è far lavorare gli agenti dentro l’interfaccia esistente, in una sessione predisposta e protetta.
6) Fili che si incrociano
Dalle fonti emergono tre matrici. La prima è la semantica di sviluppo: Flue 2 dichiara una riesecuzione prevedibile dell’agente a ogni turno e introduce hook in stile React applicati al ciclo di vita dell’agente. La seconda è il runtime che connette modelli e agenti diversi senza riscrivere i framework, con un esempio che combina SageMaker AI, endpoint OpenAI‑compatibili, Strands Agents e modelli su Amazon Bedrock, consegnati a AgentCore per l’esecuzione. La terza è l’operatività: osservabilità nativa quando l’agente gira su AgentCore e invio esplicito di telemetria con ADOT quando gira altrove; automazione via browser gestito quando mancano API.
Queste linee disegnano un perimetro di lavoro in cui la composizione del codice, l’orchestrazione in runtime e l’integrazione con sistemi esistenti si affiancano senza richiedere riscritture. Per chi costruisce agenti, le fonti indicano scelte concrete: adottare una semantica di ciclo di vita dichiarata come in Flue 2; agganciare modelli diversi a un runtime comune come AgentCore mantenendo i framework esistenti; definire una strategia di osservabilità coerente con l’ambiente di esecuzione; e impiegare il Browser Tool quando l’accesso ai sistemi passa solo dalla UI.
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici
Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate nel pezzo. Prima di uscire, ogni testo passa questi controlli:
- Fedeltà alle fonti. Un secondo passaggio toglie ogni affermazione che le fonti non sostengono.
- Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale.
- Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica.
I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.
Per vedere Millebit nelle notizie principali di Google, aggiungilo alle tue fonti preferite. Oppure segui l’edizione di oggi, il feed RSS o La Sintesi.