Agent in produzione: strumenti AWS per agenti multi‑modello, osservabilità e automazione web

Amazon mostra come collegare endpoint OpenAI‑compatibili su SageMaker AI al runtime di Bedrock AgentCore e affianca due tasselli operativi: tracing nativo per gli agent e un browser gestito per automatizzare interfacce legacy. La tesi: il baricentro si sposta dalla scelta del singolo modello alla gestione end‑to‑end degli agenti in produzione, tra integrazione multi‑modello, telemetria e automazione di UI complesse.

1) La tesi e il problema pratico

Dopo i prototipi inizia il lavoro vero: mescolare modelli foundation gestiti e modelli propri senza riscrivere gli agenti. I vincoli sono operativi. Servono controllo dei costi, residenza dei dati, specializzazione dei ruoli tra agent diversi. Chi ha investito in framework e orchestrazioni non vuole ripartire da zero. AWS risponde con integrazione di runtime, osservabilità nel perimetro di AgentCore e un tool per portali senza API moderne.

2) Integrazione multi‑modello: SageMaker AI e Bedrock AgentCore

La proposta tecnica è concreta: esporre su SageMaker AI un endpoint OpenAI‑compatibile e collegarlo al runtime di Amazon Bedrock AgentCore. Così i workflow agentici multi‑modello vanno in produzione senza riscrivere il framework esistente. Il post di Amazon segue un percorso pratico. Pubblica Qwen 3.5 9B su SageMaker AI. Integra quell’endpoint in un sistema multi‑agente costruito con Strands Agents, insieme a modelli su Amazon Bedrock. Consegna l’intero workflow al runtime di AgentCore.

Architettura con agenti specializzati. Ogni agente usa il modello adatto al compito. AWS la presenta come pronta per la produzione, con ottimizzazione dei costi, residenza dei dati e flessibilità nella scelta dei modelli. La chiave è operativa: riusare l’impianto esistente, evitare migrazioni del framework, aprire la porta a endpoint eterogenei senza duplicare pipe e colla di integrazione.

3) Osservabilità: cosa è nativo e cosa va configurato

Monitorare non è un dettaglio. AWS chiarisce cosa funziona “out of the box” e cosa no. AgentCore Observability offre tracing, monitoring e analytics nativi quando l’agent gira sul runtime AgentCore in AWS. In questo perimetro, le tracce arrivano senza strati aggiuntivi. 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.

Fuori da quel perimetro cambia il quadro. Per agent eseguiti al di fuori del runtime AgentCore o al di fuori di AWS, l’osservabilità non arriva automaticamente. Serve inviare la telemetria in modo esplicito. AWS indica l’auto‑instrumentazione con AWS Distro for OpenTelemetry (ADOT) per far confluire i dati nel dashboard di osservabilità. Il messaggio è netto: integrazione nativa sul runtime AgentCore in AWS; altrove occorre configurare il flusso di metriche e tracce.

Questa distinzione incide sulle scelte architetturali. In ambienti misti bisogna decidere dove posizionare il runtime, come standardizzare l’export della telemetria e quali costi operativi introdurre per mantenere una vista unificata. Le fonti fissano i confini; il resto è lavoro di integrazione e governance.

4) Automazione di interfacce legacy con AgentCore Browser Tool

Molte operazioni restano bloccate dentro portali senza API. Amazon cita un caso assicurativo con “decine di migliaia” di modifiche l’anno su sistemi di amministrazione polizze. Operatori attraversano schermate stratificate e inseriscono dati a mano. Stessa dinamica in sanità, manifattura, retail e servizi finanziari, dove applicazioni critiche espongono solo HTML renderizzato lato server.

Qui entra Bedrock AgentCore Browser Tool. Il servizio apre una sessione dedicata, controllata e protetta, in cui un agente può eseguire i passaggi della UI come un operatore umano. Niente scripting fragile. Niente wrapper su API che non esistono. L’agente naviga, legge, clicca, compila moduli nell’interfaccia esistente. La combinazione con Strands Agents punta a orchestrare questi flussi a volume dentro il perimetro della sessione predisposta.

L’effetto è pragmatico. Le aziende possono automatizzare workflow che finora richiedevano interventi manuali. Ma l’esecuzione resta confinata nella sessione browser dedicata. La scelta lega automazione e osservabilità: se l’agente gira su AgentCore, le tracce sono native; altrimenti serve telemetria esplicita per la stessa visibilità.

5) Tensioni operative: interoperabilità, telemetria e segnali esterni

La direzione è chiara: architetture agentiche multi‑modello con strumenti operativi per portarle in produzione. Restano tensioni pratiche. La promessa di scegliere “il modello giusto per il compito” convive con la necessità di integrare runtime diversi e instradare la telemetria quando gli agent non risiedono su AgentCore. Le fonti non elencano costi o tempi, ma distinguono ciò che è automatico da ciò che richiede configurazione.

Dall’esterno arrivano segnali di convergenza su pratiche di introspezione e strumenti. Il 13 agosto 2026 è uscita llm‑gemini 0.33 con supporto a Gemini 3.7 Flash e due nuovi modelli di embedding. Nel changelog compaiono anche gemini‑3.6‑flash, gemini‑3.5‑flash‑lite, gemini‑embedding‑2 e gemini‑embedding‑001. Il plugin è compatibile con LLM 0.32, mostra reasoning traces e abilita strumenti lato server seguendo un pattern documentato. L’autore pubblica un comando d’esempio: llm -m gemini-3.7-flash -T CodeExecution 'use python to calculate (factorial of 13) * 3' Il messaggio è semplice: client e plugin espongono tracce e strumenti eseguibili anche al di fuori dei runtime proprietari.

Lo stesso post confronta i livelli di “thinking effort” nella generazione di immagini tra Gemini 3.6 Flash e Gemini 3.7 Flash. Nella 3.6 era disponibile anche “minimal”. Nella 3.7 questa opzione non c’è più. L’autore mostra tre versioni della stessa scena 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. Serve adeguare prompt o scelta del mode.

Letta insieme, la mappa è coerente. AWS offre una via per integrare modelli eterogenei senza rifare gli agenti e per gestire automazioni in portali senza API. Lo fa delineando dove l’osservabilità è nativa e dove va abilitata. Strumenti esterni spingono su tracce e tool server‑side a livello di client. Per chi costruisce sistemi, la domanda pratica cambia: quale modello per il compito, dove gira l’agente, come arrivano le tracce e come automatizzare ciò che non espone API.

Resta un punto aperto, operativo più che teorico: quando osservabilità e browser gestito vivono dentro AgentCore, la portabilità su ambienti non AWS passa dalla capacità di replicare telemetrie e flussi di esecuzione con strumenti espliciti; la scelta del perimetro diventa parte dell’architettura quanto la scelta del modello.