Amazon Bedrock ora permette di cambiare modello a metà conversazione

Il cambio di modello a sessione attiva è possibile grazie alla memoria disaccoppiata dall’elaborazione

C’è un dettaglio tecnico nell’annuncio di oggi che vale la pena fermarsi a leggere due volte: con Amazon Bedrock AgentCore harness, ora generalmente disponibile, è possibile effettuare un cambio di provider a sessione in corso senza perdere il contesto accumulato. Non si tratta di un’opzione secondaria nel changelog — è la manifestazione più concreta di un’architettura che tratta la memoria come un primitivo indipendente dal modello, disaccoppiando ciò che l’agente sa da chi lo sta elaborando. E questo cambia molto in termini di come si progetta e si fa evolvere un sistema agentivo in produzione.

Sotto il cofano: primitivi, memoria e orchestrazione dichiarativa

Per capire perché il mid-session model swap funziona, bisogna guardare all’architettura sottostante. Il harness non è un semplice wrapper attorno a un modello linguistico: è un sistema che orchestra un insieme di primitivi distinti — Runtime, Memory, Gateway, Browser, Identity e Observability — ognuno con una responsabilità ben definita e sostituibile indipendentemente dagli altri. È un’architettura a componenti nel senso classico del termine, applicata alla costruzione di agenti AI.

Il cuore del disaccoppiamento è la gestione della memoria. Quando si crea un harness tramite CreateHarness senza specificare esplicitamente un’istanza di memoria, il sistema ne effettua il provisioning automaticamente, con strategie predefinite ragionevoli: SEMANTIC e SUMMARIZATION. La prima indicizza le informazioni per recupero semantico; la seconda condensa le conversazioni passate mantenendone l’essenza. Entrambe vivono al di fuori del modello, su un layer persistente gestito da AgentCore Memory. Questo significa che quando si invoca InvokeHarness con un provider diverso rispetto alla sessione precedente, il contesto non è nella KV-cache del modello precedente — non c’è mai stato. È in un archivio esterno, accessibile a qualsiasi modello si scelga di utilizzare nel passo successivo.

Il risultato pratico è che, come precisano la documentazione tecnica di AgentCore, un cambio di modello come modifica di configurazione non richiede di riscrivere una riga di codice applicativo. Si aggiorna la specifica del harness — quale modello usare, quali strumenti esporre tramite Gateway — e il resto del sistema continua a funzionare invariato. È la stessa logica di un’interfaccia ben definita in un sistema a microservizi: se rispetti il contratto, puoi cambiare l’implementazione.

Cosa cambia per chi costruisce agenti

Per anni, il vero collo di bottiglia nello sviluppo di agenti non è stato trovare un modello abbastanza capace. È stato tutto il codice intorno: gestire lo stato della conversazione, implementare retry logic, esporre strumenti in modo sicuro, loggare le tracce in CloudWatch per il debug, gestire l’autenticazione con Identity. Come AWS stessa riconosce, “the bottleneck wasn’t intelligence. It was orchestration and infrastructure.” Questo boilerplate non aggiunge valore all’agente — lo ritarda.

Il contesto competitivo è rilevante qui. Già a marzo 2025, OpenAI aveva rilasciato Responses API, Agents SDK e strumenti integrati per costruire agenti affidabili, e Anthropic con Claude Code ha spinto sull’automazione dei task di sviluppo. La risposta di Amazon non è un SDK alternativo, ma un livello di astrazione superiore: non scrivi l’orchestrazione, la dichiari. Il managed agent harness converte quel lavoro in configurazione, spostando il baricentro cognitivo dello sviluppatore dall’infrastruttura alla logica dell’agente. È un cambio di livello di astrazione — non dissimile dal passaggio da scrivere socket a scrivere API REST — ed è questo il vero salto di produttività che AWS sta vendendo con la GA di oggi.

Sul pricing, la struttura è coerente con l’architettura a componenti: non esiste una fee aggiuntiva per il harness in sé. Si paga solo per le capacità sottostanti effettivamente consumate — Runtime, Memory, Gateway — in base all’utilizzo reale. Chi costruisce agenti semplici non sovvenziona chi costruisce pipeline complesse.

Il messaggio di fondo è semplice: l’infrastruttura per un agente in produzione è un problema risolto, se scegli di non risolverlo da solo. Con AgentCore harness, il tempo che prima andava in session management, retry, logging e wiring dei tool ora può andare nella cosa che effettivamente differenzia il tuo agente da qualsiasi altro — la logica con cui ragiona, le fonti a cui accede, le decisioni che prende. Il resto è configurazione.