L’agente AI di Amazon è un puzzle di microservizi
Stripe e AWS propongono un'architettura AI agentica basata su grafi aciclici, gateway di controllo e orchestrazione distribuita per compliance e scalabilità.
Stripe ha sostituito i modelli monolitici con un grafo di sotto-task orchestrati e verificati
Non è il singolo modello da mille miliardi di parametri a fare la differenza in produzione.
È un grafo aciclico diretto. Stripe ha ripensato da zero il processo di compliance finanziaria scomponendo ogni revisione in sotto-task composabili organizzati come un grafo aciclico diretto di sotto-task, dove ogni nodo esegue un’operazione atomica e il flusso dati procede senza cicli. Niente chiamate monolitiche a un modello onnisciente, niente prompt chilometrici: il lavoro viene spezzato, orchestrato e verificato passo dopo passo.
A gestire il ragionamento su ogni nodo c’è il framework ReAct adottato da Stripe, che usa un LLM su Amazon Bedrock solo per la fase di reasoning. Quando il modello richiede uno strumento, il ciclo ReAct con esecuzione programmatica blocca immediatamente la generazione del testo e lancia il tool tramite codice deterministico. Il risultato rientra nel contesto solo dopo essere stato validato. Il passo di osservazione, che chiude ogni iterazione, il meccanismo anti-allucinazione integrato in ReAct impedisce al modello di inventare output o alterare i dati restituiti dagli strumenti. Non è un guardrail à la carte: è una gabbia architetturale che rende l’allucinazione strutturalmente impossibile.
Il problema che Stripe doveva risolvere era concreto e misurabile: l’indagine interna di Stripe sui flussi di lavoro aveva rivelato che gli analisti specializzati passavano fino all’80% del tempo a navigare sistemi frammentati, recuperando dati da fonti scollegate prima ancora di poter iniziare il ragionamento analitico. L’agente non sostituisce il giudizio umano: elimina l’attrito a monte, portando la macchina decisionale esattamente al punto in cui serve una valutazione.
Il gateway: dove l’agente incontra il mondo reale
AWS ha reso pubblica un’architettura di riferimento che mostra cosa serve per portare un sistema del genere in produzione, ed è qui che la scelta dei pezzi diventa rivelatrice. La strategia data mesh per applicazioni agentiche su AWS è organizzata in quattro strati precisi: Agent Layer, Gateway Layer, Tools Layer e Governed Data Mesh. Il Gateway è il punto dove si gioca la partita della sicurezza e del controllo.
Prima che qualsiasi richiesta tocchi un modello o uno strumento, l’interceptor di richiesta nella data mesh AWS esegue validazione JWT e applicazione dell’ambito di autorizzazione. A valle, gestisce tre operazioni critiche: filtraggio degli strumenti disponibili, redazione dei dati sensibili in uscita e logging di audit. Non è middleware decorativo: è il punto di innesto dove le policy aziendali diventano esecuzione automatica.
Il pezzo più interessante del Gateway è però la governance dei dati con Bedrock Guardrails, una componente chiamata AgentCore Policy che valuta input e output di ogni invocazione di strumento in tempo reale, cercando injection di prompt, contenuti dannosi e fughe di informazioni sensibili. Ogni chiamata a un tool MCP passa da questo checkpoint prima di ricevere una risposta. Non si fida del modello, non si fida dello strumento: verifica sempre.
Nel Tools Layer, AWS espone strumenti MCP per data mesh su funzioni Lambda: get_user_tables, get_schema, run_query e kb_search. Quattro primitive che compongono un’interfaccia completa verso il dato senza mai esporre direttamente il database. L’MCP — Model Context Protocol — qui non è un dettaglio implementativo: è il contratto che separa il ragionamento dall’esecuzione, ed è esattamente il tipo di confine architetturale che rende un agente testabile, manutenibile e, soprattutto, reversibile.
L’orchestrazione su scala documentale
Se il Gateway risolve il problema del controllo e della sicurezza, il piano dell’orchestrazione risolve il problema del volume. Huntington Bank doveva redigere dati sensibili da oltre 400 milioni di documenti e ha costruito la pipeline di redazione dati con AWS Step Functions usando map state in modalità distribuita per massimizzare la concorrenza. Un singolo workflow coordina migliaia di esecuzioni parallele senza colli di bottiglia centralizzati. Non c’è un mega-modello: c’è un grafo di esecuzione che tratta ogni documento come un’unità indipendente e scala linearmente con l’infrastruttura.
Questa è la vera architettura emergente dell’AI agentica secondo AWS: modelli piccoli e specializzati gestiti da un orchestratore dichiarativo, strumenti esposti tramite protocollo standard, un gateway che applica policy a ogni transizione di stato, e una data mesh che tiene il dato distribuito e governato alla fonte. È un puzzle di microservizi dove ogni pezzo ha un contratto esplicito.
Lo stack del costruttore
Per chi costruisce, il messaggio è netto: la direzione non è il modello unico addestrato su tutto lo scibile umano. È il sistema distribuito che sa quando fermare il ragionamento e chiamare uno strumento deterministico. La scelta architetturale non è tra un modello e un altro: è se il punto di controllo sta dentro il prompt o dentro l’orchestratore.
Il framework ReAct di Stripe, il Gateway con interceptor di AWS, gli strumenti MCP su Lambda, la map distribution di Step Functions: non sono pattern separati. Sono livelli dello stesso stack — uno stack dove la sicurezza non è un layer aggiuntivo ma il materiale di cui è fatto il Gateway, dove l’affidabilità non è una percentuale nel benchmark ma un meccanismo di osservazione che impedisce al modello di mentire, e dove la scala non si compra con GPU più grandi ma si progetta con grafi di esecuzione parallela. La scatola magica è morta: benvenuti nella cassetta degli attrezzi.