Agenti AI su AWS: cosa delegare a Bedrock AgentCore

Quando gli agenti AI funzionano ma l’infrastruttura che li circonda sta diventando un secondo prodotto da sviluppare, vale la pena avviare un progetto pilota con Amazon Bedrock AgentCore. L’offerta attuale di AWS comprende 13 servizi e funzionalità modulari: conviene adottare quelli che eliminano un onere operativo ben preciso, mantenendo la responsabilità del comportamento dell’agente rispetto agli obiettivi aziendali.

Contenuti verificati sulla pagina prodotto e nella documentazione ufficiale di AWS il 30 ottobre 2026. L’elenco dei componenti riportato di seguito proviene dalla panoramica per sviluppatori, raggiungibile dalla pagina prodotto di AgentCore. L’analisi del lavoro che ciascun componente può sostituire è invece la valutazione tecnica proposta in questo articolo.

Che cos’è Amazon Bedrock AgentCore e come gestisce gli agenti AI?

AgentCore permette di affidare ad AWS alcune parti della gestione degli agenti in produzione. Gli agenti IA sono software che usano un modello per scegliere azioni, chiamare strumenti e svolgere un compito. Far funzionare questo ciclo in locale lascia ancora molto lavoro da fare su identità, esecuzione, stato, controllo degli accessi e debugging.

Si può immaginare una sala da concerto. Il comportamento dell’agente è l’esibizione. Runtime mette a disposizione il palco e l’infrastruttura di supporto; i controlli degli accessi presidiano gli ingressi; la memoria conserva il contesto utile; l’osservabilità registra ciò che è accaduto. Stabilire l’obiettivo dell’esibizione e valutarne la riuscita resta compito di chi la organizza.

AWS presenta esplicitamente AgentCore con la formula “Any framework. Any model.” La pagina prodotto cita LangChain, OpenAI Agents SDK, Claude Agent SDK, Strands SDK e la possibilità di usare un framework proprio. È il perimetro di compatibilità dichiarato da AWS: non garantisce che ogni funzionalità opzionale abbia le stesse integrazioni, né che migrare non richieda lavoro. Panoramica del prodotto AWS.

Un’altra scelta riguarda chi gestisce il ciclo operativo dell’agente. Con Runtime si distribuisce il proprio codice. Con Harness si descrive l’agente tramite una configurazione e si usa il ciclo gestito da AWS, basato su Strands Agents, il framework open source di AWS per gli agenti. La documentazione di Harness chiarisce questa distinzione. Un responsabile tecnico che dispone già di codice di orchestrazione funzionante dovrebbe valutare prima il percorso con Runtime.

Bedrock Agents e AgentCore: quale differenza?

Chi usa già Amazon Bedrock Agents non deve migrare solo perché esiste AgentCore. AWS conferma che gli utenti attuali di Bedrock Agents possono continuare a usarlo. Ha senso valutare AgentCore quando serve una sua specifica capacità di esecuzione, integrazione o gestione operativa. FAQ di AWS.

Oggi la distinzione utile va oltre «ciclo gestito oppure infrastruttura»: anche AgentCore offre un ciclo gestito, attraverso Harness. La prima domanda è se si vuole mantenere il controllo del codice di orchestrazione; da lì si sceglie il percorso adatto. Per valutare questa scelta, è utile tenere a portata di mano la mappa delle architetture per agenti AI, così una decisione sull’hosting non finisce per trasformarsi, senza volerlo, in una riprogettazione dell’intera applicazione.

I componenti di Bedrock AgentCore: quale lavoro sostituiscono

I componenti vanno scelti in base al lavoro che altrimenti bisognerebbe sviluppare e gestire in proprio. AWS li descrive come funzionalità modulari, utilizzabili insieme o separatamente. L’ultima colonna indica le responsabilità che restano in capo all’applicazione anche quando il servizio di supporto è fornito da AWS.

Un assistente per il supporto clienti potrebbe aver bisogno subito di Runtime, Gateway e Identity, aggiungendo Memory quando diventa utile conservare il contesto degli utenti che tornano. Payments non serve se l’assistente non acquista mai l’accesso a risorse esterne. Registry diventa utile quando è difficile trovare le risorse approvate all’interno dell’organizzazione. Adottare più componenti non è un obiettivo in sé.

Code Interpreter e Runtime rispondono a esigenze diverse. Runtime ospita l’agente; Code Interpreter fornisce una sandbox per il codice che l’agente esegue. Se manca soltanto un ambiente isolato per eseguire codice, conviene valutare questa esigenza con la guida alle sandbox di codice per agenti AI prima di spostare l’orchestrazione.

Le scelte architetturali che restano al team

Il confine da tracciare separa l’infrastruttura gestita dalle decisioni che spettano all’applicazione. In un ipotetico flusso di assistenza, l’agente potrebbe leggere un ordine, spiegarne lo stato e proporre un’azione. AWS può fornire l’infrastruttura di esecuzione e di accesso, ma è l’applicazione a dover stabilire a chi appartiene l’ordine e se quell’azione è consentita.

Bedrock AgentCore Runtime: isolare una sessione non significa attribuirla a un utente

Runtime può isolare l’esecuzione senza sapere a quale cliente appartiene una sessione. AWS documenta ambienti microVM dedicati alle sessioni, con separazione delle risorse di calcolo, memoria e filesystem. La stessa documentazione precisa che AgentCore non impone l’associazione tra sessioni e utenti: deve mantenerla il backend del client. Sessioni di Runtime.

Nel caso dell’assistente per il supporto clienti, un identificativo di sessione inviato dal browser non dimostra che la sessione appartenga a quel cliente. Occorre autenticare la richiesta, individuare nel backend la sessione autorizzata e limitare gli accessi a valle ai dati di quel cliente. Il confine infrastrutturale e la decisione autorizzativa dell’applicazione sono responsabilità distinte.

Bedrock AgentCore Memory: scegliere quale contesto conservare

Memory sostituisce l’infrastruttura di gestione del contesto; la scelta di cosa inserirvi resta al team. AWS supporta sia il contesto delle conversazioni a breve termine sia le informazioni conservate a lungo termine tra una sessione e l’altra. Documentazione di Memory.

Ricordare che un cliente preferisce risposte concise è diverso dal conservare il saldo ufficiale di un ordine. La fonte autorevole dei dati aziendali deve restare nell’applicazione. Va deciso come l’agente recupera i dati aggiornati, quali informazioni emerse nella conversazione può conservare e cosa accade quando una preferenza memorizzata non è più valida. Un servizio di memoria non prende queste decisioni di progettazione dei dati al posto del team.

Bedrock AgentCore e MCP: Gateway gestisce le connessioni

Gateway è utile quando collegare gli strumenti è diventato un lavoro tecnico ripetitivo. Model Context Protocol, o MCP, è un’interfaccia condivisa per rendere gli strumenti accessibili agli agenti. Gateway può trasformare API e funzioni AWS Lambda in strumenti compatibili con MCP e collegarsi a server MCP esistenti. La documentazione attuale comprende anche l’instradamento verso altri agenti e modelli. Documentazione di Gateway.

Per un assistente che gestisce richieste sugli ordini, conviene esporre prima un’operazione circoscritta, come la verifica dello stato della consegna, anziché uno strumento generico per interrogare il database. Gateway può veicolare la chiamata; resta all’API il compito di definire il significato dell’operazione, i record a cui può accedere e se un nuovo tentativo possa ripetere un effetto collaterale.

Bedrock AgentCore Identity: alle credenziali servono regole aziendali

Identity gestisce chi agisce e le credenziali utilizzate; Policy governa le azioni consentite sul gateway. Identity fornisce identità per i carichi di lavoro e gestione delle credenziali per accedere a risorse AWS e servizi di terze parti, anche per conto di un utente. Documentazione di Identity.

Policy valuta il traffico che attraversa un AgentCore Gateway associato prima di consentire l’accesso agli strumenti. Questo perimetro conta: non si deve presumere che una policy sul gateway governi anche una chiamata di rete diretta e indipendente che l’agente può effettuare. Le operazioni sensibili devono passare dal punto di controllo previsto, limitando i percorsi che permettono di aggirarlo. Documentazione di Policy.

Un’identità usata per il supporto clienti potrebbe essere autorizzata a leggere un ordine ma non a emettere un rimborso. Le istruzioni del modello devono descrivere quel flusso di lavoro, mentre gli strumenti e i livelli di autorizzazione devono far rispettare i permessi.

Bedrock AgentCore Observability: una traccia documenta l’esecuzione, non ne certifica la riuscita

Observability aiuta a ricostruire il comportamento; Evaluations aiuta a valutarlo. AgentCore offre viste dell’esecuzione e telemetria compatibile con OpenTelemetry, un formato standard per tracce e metriche, con dashboard basate su Amazon CloudWatch. AWS distingue le metriche integrate dalle tracce aggiuntive e dai metadati aziendali che il team raccoglie tramite la strumentazione dell’applicazione. Documentazione di Observability.

Per l’assistente di supporto, bisogna registrare se la ricerca dell’ordine richiesto è stata completata e se un’azione è stata approvata. Una chiamata a uno strumento può riuscire sul piano tecnico e rispondere comunque alla domanda aziendale sbagliata.

Evaluations fornisce valutazioni integrate e personalizzate, comprese quelle affidate a modelli. Occorre definire casi rappresentativi propri ed esaminare gli errori con conseguenze rilevanti. La documentazione di Evaluations specifica i framework e le modalità di strumentazione supportati: va verificato il percorso scelto, senza estendere a ogni funzionalità la compatibilità generale dichiarata per la piattaforma.

I limiti da considerare in fase di progettazione

La durata delle risorse di calcolo va distinta da quella dello stato utile all’applicazione. La documentazione attuale di AWS sul ciclo di vita prevede un timeout di inattività predefinito di 15 minuti e una durata massima delle risorse di calcolo microVM di 8 ore. Instances, l’alternativa che esegue capacità gestita di Amazon Elastic Compute Cloud nel proprio account, consente di configurare una durata fino a 14 giorni, entro i vincoli delle impostazioni del relativo provider di capacità. Impostazioni del ciclo di vita, Instances.

Una sessione logica può riprendere su risorse di calcolo appena predisposte. Per impostazione predefinita, lo stato in memoria e quello nel filesystem locale seguono il ciclo di vita delle risorse di calcolo; lo storage di sessione, se configurato, può conservare i dati del filesystem tra arresto e ripresa. Occorre stabilire esplicitamente cosa deve sopravvivere a un’interruzione. Ciclo di vita e storage delle sessioni.

Prima di scegliere quali funzionalità adottare, va consultata la matrice AWS delle funzionalità disponibili per regione. «Disponibile su AWS» non basta per un’applicazione vincolata a una regione specifica.

Quando conviene adottare AgentCore

Ha senso procedere quando una lacuna operativa precisa blocca il rilascio e il componente gestito corrispondente soddisfa i requisiti. La scelta va valutata in base all’isolamento dell’esecuzione, all’accesso autorizzato agli strumenti, alla conservazione dello stato, alla possibilità di diagnosticare i problemi e al lavoro necessario per gestire in proprio queste capacità.

Per chi sviluppa, il momento giusto per un progetto pilota è quando la logica dell’agente funziona ma resta in attesa dell’hosting o dell’integrazione con gli strumenti. Mantenere il ciclo esistente su Runtime rende l’esperimento più circoscritto rispetto a cambiare contemporaneamente framework e piattaforma di distribuzione.

Per chi gestisce i sistemi, il vantaggio è più evidente quando tutti gli agenti richiedono gli stessi meccanismi per credenziali, controlli degli accessi e analisi degli incidenti. Conviene scegliere un flusso di lavoro che permetta di verificare queste responsabilità, includendo un errore da diagnosticare.

Per chi decide gli acquisti tecnologici, le domande sono quale lavoro ricorrente viene eliminato e quali nuove integrazioni restano da realizzare. Servono comunque responsabili identificati per la configurazione AWS, la progettazione dei permessi, il comportamento dell’applicazione e la gestione degli interventi in reperibilità.

Meglio aspettare se lo stack attuale offre già i controlli necessari e non c’è un problema concreto da risolvere. Per migrare servirebbe un’altra ragione, come una funzionalità che lo stack non può fornire. Non occorre intervenire se il flusso di lavoro è una sequenza fissa di operazioni note e non richiede un agente che scelga l’azione successiva.

Se la decisione dipende dalla spesa, è utile consultare i prezzi di AgentCore pubblicati da AWS insieme alla guida ai prezzi di Amazon Bedrock del sito.

Un primo progetto pilota con la CLI di AWS

Si parte dal template AWS basato su codice, per poi aggiungere un’operazione aziendale rappresentativa. Questo percorso segue la guida rapida attuale di Runtime e la guida completa alla CLI. Deriva dalla documentazione: il deployment non è stato testato per questo articolo.

La guida completa richiede Node.js 20.12 o successivo, npm, Python 3.10 o successivo, il gestore delle dipendenze Python uv, credenziali AWS configurate, permessi di deployment e accesso ai modelli. Il template usa CodeZip, quindi Docker non è necessario.

1. 1

   Installazione e creazione del progetto

   Usare un account o un ambiente AWS di sviluppo.

   npm install -g @aws/agentcore
   agentcore --version
   agentcore create --name MyProject --template agent-python-strands

   Il template include un Runtime chiamato agent e una risorsa AgentCore Memory. Vanno esaminati entrambi nella configurazione generata.

2. 2

   Prova in locale

   cd MyProject
   agentcore dev --mode browser

   Provare l’agente nell’inspector locale, poi arrestare il server prima di proseguire nello stesso terminale.

3. 3

   Build, deployment e invocazione

   agentcore build
   agentcore deploy
   agentcore status
   agentcore invoke --runtime agent --payload '{"prompt":"Hello, what can you do?"}'

   Il deployment crea le risorse AWS tramite AWS Cloud Development Kit, o CDK.

4. 4

   Verifica e rimozione delle risorse

   agentcore logs runtime
   agentcore traces runtime list

   Eseguiti nella directory di questo progetto pilota, i comandi seguenti ne rimuovono le risorse e smantellano lo stack distribuito:

   agentcore remove all --yes
   agentcore deploy --yes

Prima di introdurre traffico di produzione, sostituire il saluto con un compito circoscritto, come la ricerca di un ordine di prova. Le verifiche di accettazione consigliate dipendono dall’applicazione: restituzione dei dati corretti, rifiuto degli accessi non autorizzati, visibilità nella traccia di una chiamata a uno strumento fallita e comprensione del comportamento di ripresa dopo un’interruzione. Sono criteri per valutare il progetto pilota, non dichiarazioni sulle prestazioni di AWS.

Dove le aspettative superano la realtà

L’esecuzione gestita non dimostra che l’agente prenda decisioni aziendali corrette. Hosting, tracciamento, valutazione e applicazione delle policy affrontano problemi diversi. Nessuno di questi servizi solleva il team dalla scelta di un compito utile, dalla definizione delle azioni ammissibili e dall’analisi degli errori.

Anche “Any framework” non deve diventare una promessa di integrazione senza lavoro. La flessibilità della piattaforma lascia al team la verifica di dipendenze, autenticazione, strumentazione e contratti di ciascun servizio adottato.

Infine, adottare tutti i componenti non dimostra di essere pronti per la produzione. Un assistente di supporto con accesso in sola lettura non migliora acquisendo facoltà di pagamento o un browser di cui non ha bisogno. Le capacità vanno aggiunte quando un compito concreto le richiede, includendo nella revisione anche l’ampliamento dei permessi.

Da dove partire lunedì

Scegliere un compito già affidato a un agente e mettere per iscritto quale responsabilità operativa lo sta rallentando. Sperimentare soltanto le capacità di AgentCore necessarie a eliminare quel ritardo. Confrontare il deployment ottenuto, la gestione degli errori e l’onere delle responsabilità residue con lo stack attuale. Estendere l’adozione quando i risultati lo giustificano.

Ricevi nella newsletter guide pratiche per sviluppare e gestire sistemi AI.