{"id":31385,"date":"2026-08-07T20:16:08","date_gmt":"2026-08-07T11:16:08","guid":{"rendered":"https:\/\/aireviewirush.com\/?p=31385"},"modified":"2026-08-07T20:16:09","modified_gmt":"2026-08-07T11:16:09","slug":"runtime-cases-persistent-compute-for-manufacturing-ai-brokers-on-amazon-bedrock-agentcore","status":"publish","type":"post","link":"https:\/\/aireviewirush.com\/?p=31385","title":{"rendered":"Runtime cases: persistent compute for manufacturing AI brokers on Amazon Bedrock AgentCore"},"content":{"rendered":"


\n<\/p>\n

\n\n\n\n
\n
\n \"Voiced<\/a>\n <\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Once you transfer AI brokers from prototype to manufacturing, the infrastructure challenges multiply. Your brokers must persist state throughout multi-step workflows that run for hours or days. They should coordinate with different brokers, share context, and generally entry GPUs for specialised duties. Amazon Bedrock AgentCore runtime microVMs present a totally managed surroundings for invocations that may run for as much as 8 hours and assist stateful workflows by way of managed session storage. Some workloads additionally profit from devoted, larger-capacity environments \u2014 for instance, when brokers must run repeatedly for a number of days, entry GPUs or the underlying OS, or run a number of collaborating brokers on the identical host.<\/p>\n

At the moment, I\u2019m blissful to announce runtime cases, a brand new complementary compute choice in Amazon Bedrock AgentCore Runtime<\/a> that offers your brokers persistent, managed infrastructure purpose-built for advanced agent workloads.<\/p>\n

What you get<\/strong><\/span>
\n
Runtime cases offers AWS-managed EC2 infrastructure the place you deploy a number of brokers in a single runtime, every with their very own dependencies and artifact sorts. Your brokers can collaborate on the identical host inside shared periods that persist for as much as 14 days. The service helps GPU acceleration for compute-intensive duties, session cease\/restart to save lots of prices throughout idle intervals, and containerized deployments for groups that need to ship independently. For data that should survive past a session, runtime cases pairs naturally with Amazon Elastic Block Retailer (Amazon EBS)<\/a> and AgentCore Reminiscence, which supplies your brokers long-term recall throughout periods and environments.<\/p>\n

Earlier than right this moment, in the event you wished to maintain your brokers operating for days or they wanted GPU entry, or multi-agent coordination, you needed to construct and handle that infrastructure your self. You provisioned EC2 cases, configured networking, arrange session administration, dealt with scaling, and stitched collectively monitoring. Runtime cases handles all of that for you whereas integrating with the identical AgentCore APIs, id controls, and observability you already use with AgentCore Runtime microVMs.<\/p>\n

A couple of issues that ought to make agent builders smile: your brokers can name one another as instruments inside a shared session, iterating autonomously till the job is completed. You deliver any framework (CrewAI<\/a>, LangGraph<\/a>, LlamaIndex<\/a>, Strands) and any mannequin. Packaging is minimal, a @app.entrypoint<\/code> decorator and a zipper file or container picture. And in case your workflow spans days, hibernate Monday evening and resume Wednesday morning with all the pieces intact.<\/p>\n

Runtime microVMs and runtime cases are complementary compute choices that you should use independently or collectively by way of the identical AgentCore runtime APIs. A light-weight orchestrator agent on runtime microVM can coordinate and dispatch work to specialised employee brokers operating on cases. The orchestrator handles API calls, job routing, and end result aggregation utilizing runtime microVM\u2019s quick scaling, whereas staff on Situations carry out compute-intensive duties like code compilation, safety scanning, or GUI automation that require persistent state and direct OS entry.<\/p>\n

Let me present you the way it works
\n
<\/strong><\/span>I constructed two brokers for this demo: a code author agent that generates Python code from pure language descriptions, and a code reviewer agent that analyzes the generated code for bugs, safety points, and elegance enhancements. Each brokers share the identical file system, so the reviewer can learn regardless of the author produces with none information switch or API calls between them.<\/p>\n

Right here is the code author (simplified, no error dealing with):<\/p>\n

author = Agent(\n    mannequin=\"us.anthropic.claude-sonnet-4-5-20250929-v1:0\",\n    system_prompt=(\n        \"You're a senior Python engineer. \"\n        \"Given a job, return ONLY a single Python code block \u2014 no prose.\"\n    ),\n)\n\n@app.entrypoint\ndef handler(occasion, context):\n    job = occasion.get(\"job\") or occasion.get(\"immediate\")\n    session_id = getattr(context, \"session_id\", None) or occasion.get(\"session_id\")\n    session_dir = SHARED_DIR \/ session_id\n    session_dir.mkdir(mother and father=True, exist_ok=True)\n\n    code = str(author(job))\n    (session_dir \/ \"code.py\").write_text(code)\n\n    return {\"agent\": \"author\", \"wrote\": str(session_dir \/ \"code.py\"), \"code\": code}<\/code><\/pre>\n
Right here is the code reviewer agent (simplified, no error dealing with):<\/p>\n
reviewer = Agent(\n    mannequin=\"us.anthropic.claude-sonnet-4-5-20250929-v1:0\",\n    system_prompt=(\n        \"You're a strict Python code reviewer. \"\n        \"Given code, return 3 bullet factors: bugs, model, strategies.\"\n    ),\n)\n\n@app.entrypoint\ndef handler(occasion, context):\n    session_id = getattr(context, \"session_id\", None) or occasion.get(\"session_id\")\n    code_path = SHARED_DIR \/ session_id \/ \"code.py\"\n    code = code_path.read_text()\n    evaluation = str(reviewer(f\"Overview this code:nn{code}\"))\n\n    return {\"agent\": \"reviewer\", \"learn\": str(code_path), \"evaluation\": evaluation}\n<\/code><\/pre>\n
Every agent is a Python utility utilizing Strands Brokers<\/a> with an @app.entrypoint<\/code> decorator and a mannequin of its selection. I bundle each as a zipper file. For this demo, I exploit the AWS Administration Console<\/a>. It’s also possible to use the AgentCore CLI<\/a>, the AWS Command Line Interface (AWS CLI)<\/a> or infrastructure as code.<\/p>\n
Step 1: Create a capability supplier.<\/strong><\/p>\n
A capability supplier defines the EC2 infrastructure your brokers run on. Within the AgentCore console, I choose Runtime<\/strong> within the left navigation, then choose the Capability suppliers<\/strong> tab and Create capability supplier<\/strong>.<\/p>\n
\"ACI<\/p>\n
I give it a Identify<\/strong>, choose Linux (64-bit ARM) because the Working system<\/strong>, and select c7g.2xlarge<\/code> because the Allowed occasion sorts<\/strong>. This provides me 8 vCPUs and 16 GiB of reminiscence, sufficient for each brokers to run comfortably aspect by aspect.<\/p>\n
Additional down, I configure the VPC<\/strong>, subnets<\/strong>, and safety teams<\/strong> for community entry. Underneath Storage configuration<\/strong>, I maintain the default gp3 quantity. Underneath Service entry<\/strong>, I choose Create a brand new service position<\/strong> and let the console create the infrastructure position that manages EC2 cases on my behalf.<\/p>\n
I choose Create capability<\/strong> supplier and wait a number of seconds. The standing strikes to Lively<\/strong>.<\/p>\n
\"ACI<\/p>\n
\"ACI<\/p>\n
Word the capability supplier configuration abstract: working system, occasion kind, subnets, safety group, occasion profile, and infrastructure position. As soon as created, solely the outline might be edited, so confirm your settings earlier than you proceed.<\/p>\n
\"ACI<\/p>\n
Step 2: Create a runtime and deploy the primary agent.<\/strong><\/p>\n
Again on the Runtime<\/strong> web page, I choose Create runtime<\/strong>. I give it a Identify<\/strong>, choose Situations because the Compute kind<\/strong>, and select the Capability supplier<\/strong> I created within the earlier step.<\/p>\n
\"ACI<\/p>\n
Underneath Agent supply<\/strong>, I choose S3 Supply<\/strong>, then Add to S3<\/strong>. I select my agent zip file (ACIDemoWriter.zip<\/code>), set the Language runtime<\/strong> to Python 3.13,<\/code> and specify agent.py<\/code> because the Agent entry level<\/strong>. That is the file that accommodates my @app.entrypoint<\/code> embellished operate. Underneath Permissions<\/strong>, I choose Create default position<\/strong> to let the console provision the IAM position my agent wants.<\/p>\n
\"ACI<\/p>\n
I choose Create runtime<\/strong> and await the standing to turn into Prepared<\/strong>.<\/p>\n
I repeat the identical course of for my code reviewer agent. I create a second runtime, choose the identical capability supplier, add my reviewer agent zip file, and await it to turn into Prepared<\/strong>. Each brokers now share the identical underlying EC2 infrastructure.<\/p>\n
\"AgentCoreThe console reveals me a View invocation code<\/strong> part with ready-to-use Python, TypeScript, and JavaScript snippets to invoke my agent programmatically. However for this demo, I exploit the built-in check characteristic. I choose Check<\/strong> on the author agent\u2019s web page.<\/p>\n
\"AgentCoreStep 3: Invoke brokers and observe collaboration.<\/strong><\/p>\n
The Runtime playground<\/strong> opens. On the high, I see three fields: Runtime agent<\/strong>, Endpoint<\/strong>, and Session ID<\/strong>. The console generates a session ID robotically. I pay attention to it as a result of I’ll reuse it with the reviewer agent.<\/p>\n
Within the Enter<\/strong> subject, I kind a JSON payload asking the author agent to generate code:<\/p>\n
{\"immediate\": \"write a fibonacci suite\"}<\/code><\/pre>\n
I choose Run<\/strong>. After a number of seconds, the Output<\/strong> panel reveals the agent\u2019s response. The author agent generated a Python module with two implementations of a Fibonacci sequence (a list-based operate and a generator) and wrote it to \/tmp\/agentcore-session\/ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2\/code.py<\/code>. Discover the session ID within the file path. That listing is the shared file system for this session.<\/p>\n
\"AgentCore<\/p>\n
Step 4: Invoke the reviewer agent in the identical session.<\/strong><\/p>\n
Now I swap the Runtime agent<\/strong> dropdown to ACIDemoReviewer<\/strong>. The vital half: I paste the identical session ID (ca5ec24d-07f5-4eeb-add1-5ba416bf9eb2)<\/code> within the Session ID<\/strong> subject. That is what connects the 2 brokers.<\/p>\n
I kind a easy immediate:<\/p>\n
{\"immediate\": \"evaluation the code\"}<\/code><\/pre>\n
I choose Run<\/strong>. The reviewer agent reads the file the author produced from the shared session listing and returns an in depth code evaluation. It finds no important bugs however suggests including kind hints, enter validation, and simplifying the sting case dealing with.<\/p>\n
\"AgentCoreThe 2 brokers by no means exchanged messages or referred to as one another\u2019s APIs. They collaborated by way of the shared file system that runtime cases present inside a session. You may prolong this sample to any variety of brokers: a check agent that runs the code, a documentation agent that generates README information, a safety agent that scans for vulnerabilities, all sharing the identical working listing.<\/p>\n
Key particulars
\n          
<\/strong><\/span>Right here are some things to know as you get began:<\/p>\n