AWS Builder Center

Builder Center

Multi‑Agent AWS Builder on AgentCore Runtime

A walkthrough showing how to build, test locally, and deploy a small multi-agent AWS Builder using Amazon Bedrock AgentCore Runtime — covering architecture planning, IaC, security review, deployment steps, and observability.

sweta jha

Deploying on AgentCore Runtime: A Multi-Agent AWS Builder Workflow

Agentic AI demos are easy to build. Production agents are harder because you need isolation, identity, observability, long-running execution, deployment automation, and a repeatable way to test changes. Amazon Bedrock AgentCore Runtime is designed for that production step: it gives agents a secure, serverless runtime while staying framework and model agnostic.
In this post, I’ll walk through a simple multi-agent AWS Builder that takes an application idea and turns it into an architecture plan, infrastructure outline, security review, and deployment checklist. The same pattern can be expanded into a real internal platform agent for cloud teams.

What We Are Building

The workflow has one orchestrator and four specialist agents:
  • Architect: designs service boundaries and AWS architecture
  • IaC Engineer: converts the plan into infrastructure tasks
  • Security Reviewer: checks IAM, data handling, logging, and operational risk
  • Deployment Lead: creates the release and smoke-test workflow
The orchestration is intentionally simple. Each specialist receives the user goal plus the context produced by earlier agents. The final response is a build brief that a developer can use as a starting point.
1
2
3
4
5
6
7
flowchart LR
U["User prompt"] --> O["Orchestrator"]
O --> A["Architect"]
O --> I["IaC Engineer"]
O --> S["Security Reviewer"]
O --> D["Deployment Lead"]
D --> R["Final build brief"]

Why AgentCore Runtime

AgentCore Runtime lets you host agents or tools in a secure serverless environment. The AWS docs highlight several capabilities that matter for real agents: framework flexibility, support for different model providers, protocol support for MCP and A2A, isolated sessions, long-running workloads, persistent filesystem state, built-in identity, observability, large payloads, and streaming.
That means you can start with normal Python code, test locally, and deploy the agent without designing a custom runtime layer from scratch.

Project Structure

1
2
3
4
5
6
7
8
9
10
11
agentcore-multiagent-builder/
├── app/
│ └── AWSBuilderAgent/
│ ├── main.py
│ ├── agents.py
│ ├── llm.py
│ └── local_test.py
├── workflow.md
├── pyproject.toml
└── blog/
└── deploying-on-agentcore-runtime.md

Runtime Entrypoint

The entrypoint uses the AgentCore Python SDK. The handler accepts a payload, extracts a prompt, and returns a structured multi-agent result.
1
2
3
4
5
6
7
8
9
10
from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
def invoke(payload: dict) -> dict:
return handle_request(payload)

if __name__ == "__main__":
app.run()
The rest of the code is plain Python, so it remains easy to test locally.

Local Test

Before deploying, run the agent locally:
1
2
3
4
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
python -m app.AWSBuilderAgent.local_test "Build a serverless order tracking app on AWS"
The sample defaults to mock responses so readers can understand the orchestration without needing AWS credentials. To use Amazon Bedrock, set:
1
2
3
export AWS_BUILDER_USE_BEDROCK=true
export AWS_REGION=us-east-1
export BEDROCK_MODEL_ID=us.anthropic.claude-sonnet-4-20250514

Deploying on AgentCore Runtime

Install the AgentCore CLI:
1
2
npm install -g @aws/agentcore
agentcore --version
Create a code-based project:
1
2
3
4
5
6
agentcore create \
--name AWSBuilderAgent \
--framework Strands \
--model-provider Bedrock \
--memory none \
--build CodeZip
Test locally with the AgentCore development server:
1
agentcore dev
Preview the deployment:
1
agentcore deploy --plan
Deploy:
1
2
agentcore deploy
agentcore status
Invoke the deployed agent:
1
agentcore invoke --prompt "Design a multi-agent customer support workflow on AWS"
Inspect logs and traces:
1
2
agentcore logs --since 30m
agentcore traces list

What I Like About This Pattern

The important part is not that there are four agents. The useful part is that each agent has a clear responsibility and a narrow output. That makes the workflow easier to debug and easier to improve. If the security review is weak, you improve that agent. If the IaC output is too vague, you improve that prompt or connect it to a code-generation tool.
AgentCore Runtime then gives the workflow a deployment path: local development, deployment preview, runtime endpoint, invocation, logs, and traces.

Cleanup

When you are done experimenting:
1
2
agentcore remove all
agentcore deploy

Final Thoughts

For me, the best way to think about AgentCore Runtime is as the production host for agentic workloads. You can keep your preferred framework and model, but move the agent into an environment built for isolation, observability, identity, and scale.
This multi-agent AWS Builder is deliberately small, but the workflow is the same one I would use for a more serious internal cloud assistant: start local, split responsibilities, test the orchestration, deploy with a plan, observe every run, and iterate from traces instead of vibes.
Repository
All code from this post is available at: https://github.com/its-me-sweta/multiagent-ai-agentcore-runtime
# agentic-ai# agents# aws-builders# ai
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article