Source: AWS Machine Learning Blog — 2026-07-07
Summary
AWS published a full reference build — blog post plus a public GitHub repo — for a serverless image-editing agent that runs entirely on Amazon Bedrock AgentCore harness with no hand-written orchestration code. A user uploads a photo, types an instruction like "change the car color to blue," and the agent picks the correct Stability AI editing tool (inpaint, outpaint, or search-and-replace) itself, returning the edited image in seconds. The whole stack — React frontend, Lambda security proxy, AgentCore agent with memory, and three tool Lambdas — deploys with a single command.
Key Takeaways
- AgentCore harness is doing the orchestration work that would normally require a hand-rolled agent loop: you declare what the agent does (its tools and instructions), and the harness runs it inside a stateful, isolated microVM with memory, tool routing, and observability built in — no custom routing logic to write or maintain.
- The architecture has four pieces: a React frontend on AWS Amplify (upload + natural-language instruction), an AWS Lambda proxy acting as the security boundary between the frontend and the agent, the AgentCore harness agent itself (with AgentCore Memory for cross-turn context), and three separate tool Lambdas that each call a different Stability AI model through Bedrock.
- Model routing is split by task cost: basic conversational turns route to Claude Haiku 4.5, while actual image-edit requests route to Claude Sonnet 4.6 — and AgentCore Memory preserves conversation context across that model switch, so the user never notices the handoff.
- Tool selection is entirely agent-driven: given a prompt like "extend the image 200 pixels to the right," the agent decides on its own that this calls for the outpaint tool rather than inpaint or search-and-replace — there's no if/else routing logic written by the developer.
- The full solution — auth, encrypted storage, three tools, and the frontend — deploys with a single command, and the complete source is public at github.com/aws-samples/sample-serverless-image-editing-agent-bedrock-agentcore-harness.
Reel Script
Hook (~17s, 38 words): Someone types "make the car blue" into a chat box, and an AI agent picks the exact right image-editing tool out of three options, runs it, and hands back the result — and the developer never wrote a single line of routing logic to make that decision happen.
Core Concept (~75s, 170 words): This is a reference build AWS published for Bedrock AgentCore harness, and the interesting mechanism is what the harness is actually replacing. Normally, if you build an AI agent that has multiple tools — say, three different image-editing functions — you have to write the logic that decides which tool to call based on what the user asked for. That's the "orchestration" work: parsing intent, matching it to a tool, handling the handoff. AgentCore harness removes that step. You just declare the tools and their descriptions, and the harness — running the whole thing inside an isolated microVM — lets the model itself read the incoming request and pick the right tool. Think of it like the difference between writing a dispatcher that routes calls to the right department versus hiring a receptionist smart enough to just listen and send the call to the right desk herself. The model is the receptionist; AgentCore is the phone system that gives her the tools and remembers the caller between calls.
Hands-On (~130s, 290 words): The architecture is four pieces, and it's worth walking through because it's a genuinely reusable pattern. A React frontend hosted on AWS Amplify is where the user uploads a photo and types the instruction. That request doesn't go straight to the agent — it passes through an AWS Lambda proxy first, which acts purely as a security boundary, so the frontend never talks to the agent runtime directly. The agent itself runs on AgentCore harness, and it's paired with AgentCore Memory, which is what lets it hold conversation context across turns — including across a model switch, since basic chat gets routed to the cheaper Claude Haiku 4.5 while actual edit requests get routed to the pricier Claude Sonnet 4.6. That's a concrete cost-control pattern worth screen-capturing: cheap model for "what can you do," expensive model only when the user commits to an actual edit. Below the agent sit three separate tool Lambdas, each wrapping one Stability AI capability accessed through Bedrock — inpaint (fill in a masked region), outpaint (extend the canvas), and search-and-replace (swap one object for another by description). When a user says "extend the image 200 pixels to the right," nothing in the code special-cases that phrase — the agent's own reasoning maps "extend" to the outpaint tool. The entire thing, frontend included, deploys with one command, and AWS put the full source on GitHub rather than just describing it in prose — worth pulling up on screen since it's a legitimate template, not a toy demo.
Takeaway (~24s, 52 words): This is a genuinely copyable pattern for anyone building a multi-tool agent, not just an image editor — model-tiering by task cost, plus tool selection you don't hand-code. If you're prototyping an agent with more than one tool, clone the repo and read the harness config before you write your own orchestration layer.