Costruire un agente AI che modifica immagini a partire da istruzioni in linguaggio naturale richiede normalmente un loop di orchestrazione, il routing dei tool, la gestione della memory e un ambiente di compute. Amazon Bedrock AgentCore harness gestisce l’intero stack tramite configurazione: si dichiara cosa fa l’agente e l’harness lo esegue in una microVM isolata e stateful, con memory, tool routing e observability integrati. Per chi lavora con agenti su cloud, il punto interessante è che l’agente diventa configurazione, non codice: cambiarne il comportamento è una chiamata API, non un deploy.
Il post mostra un editor di immagini serverless dove l’utente carica una foto, descrive una modifica in linguaggio naturale (“cambia il colore dell’auto in blu”, “estendi l’immagine di 200 pixel a destra”) e riceve il risultato in pochi secondi. Un agente basato su Claude Sonnet 4.6 scompone la richiesta in passi e orchestra le chiamate ai tool, ciascuno associato a un modello Stability AI, poi applica un watermark con un comando shell sulla microVM (senza costo in token).
Architettura e definizione dell’agente
L’architettura ha quattro livelli: un frontend React su AWS Amplify, un proxy AWS Lambda che fa da confine di sicurezza tra le credenziali del browser e l’API dell’harness, l’agente AgentCore harness con AgentCore Memory per la persistenza della conversazione, e tre funzioni Lambda che chiamano i foundation model Stability AI via Amazon Bedrock. Le immagini sono su S3 con cifratura KMS, l’autenticazione usa Amazon Cognito e l’infrastruttura è definita con AWS CDK, deployabile con un unico comando.
L’agente è interamente definito da parametri passati all’API create_harness: model, system prompt, tool, lista degli allowed tool, max iterations e timeout. Nessun loop di orchestrazione, nessuna logica di esecuzione dei tool, nessun handler di streaming o retry: l’harness gestisce tutto. I tre tool (inpaint, outpaint, search-and-replace) sono dichiarati con il loro schema su un AgentCore Gateway e collegati a funzioni Lambda, esposti come tool MCP; l’agente seleziona il tool giusto in base al prompt tramite il reasoning del modello.
Switch di modello e post-processing
L’harness accetta un parametro model a ogni invocazione: il proxy Lambda indirizza la chat semplice a Claude Haiku 4.5 (latenza più bassa) e gli edit a Claude Sonnet 4.6 (selezione dei tool di qualità superiore), mentre AgentCore Memory conserva l’intera history (per 30 giorni) e la riformatta per il modello attivo, così il contesto si mantiene tra gli switch. Allo stesso modo si possono iniettare persona di settore (Real Estate, Retail, Automotive) senza redeploy. Dopo la generazione, InvokeAgentRuntimeCommand esegue uno script Python direttamente sulla microVM per applicare il watermark, senza reasoning del modello né consumo di token, pattern utile per post-processing deterministico.
Il post è esplicito sui limiti: l’harness è in preview e non ha ancora un construct CDK nativo, e conviene per pattern di tool-calling lineari; se serve orchestrazione custom (pre-processing tra i turni, una state machine LangGraph, codice arbitrario prima e dopo ogni chiamata) meglio AgentCore Runtime, che gira sulla stessa infrastruttura e consente di partire dall’harness e migrare quando la complessità cresce.
- AgentCore harness elimina il codice di orchestrazione: l’agente è definito da parametri API, con tool routing, memory e observability integrati.
- Lo switch di modello e persona avviene per invocazione senza perdere il contesto, grazie ad AgentCore Memory.
- InvokeAgentRuntimeCommand consente post-processing deterministico sulla microVM senza consumare token; per orchestrazione complessa si passa ad AgentCore Runtime.
Fonte: Build a serverless image editing agent with Amazon Bedrock AgentCore harness — https://aws.amazon.com/blogs/machine-learning/build-a-serverless-image-editing-agent-with-amazon-bedrock-agentcore-harness/
Hai qualcosa da aggiungere? Unisciti alla discussione.