AWS Shows Multi-Agent Music Pipeline on Bedrock AgentCore Runtime Instances

Runtime Instances versus MicroVMs

Amazon Bedrock AgentCore now offers two compute options for hosting agents. According to AWS, MicroVMs are the serverless option, with fast cold starts, session isolation and consumption-based pricing. Runtime Instances are the new option: AWS managed EC2 infrastructure meant for persistent, long-running agent workflows.

Both use the same runtime APIs and support custom frameworks such as CrewAI, LangGraph, LlamaIndex and Strands Agents, as well as MCP and A2A. The difference lies in the compute model. AWS lists the following contrasts:

• Session duration: up to 8 hours for MicroVM, up to 14 days for Runtime Instances.
• Agents per compute: one agent per microVM, while one EC2 instance can host multiple agents.
• GPU access: not supported on MicroVM, available on a supported instance family with Runtime Instances.
• Persistence: session-scoped for MicroVM, persistent storage on Amazon EBS for Runtime Instances.
• Pricing: consumption-based for MicroVM. Runtime Instances run in the customer's account, so AWS Savings Plans and On-Demand Capacity Reservations can be used.

When two agent runtimes share the same capacity provider, they can be invoked with the same runtimeSessionId. That places both on the same EC2 instance, where they share a filesystem and can collaborate on one task.

The three-agent music workflow

The example pipeline uses three specialized agents, each owned by a different team.

• Composition agent (Audio AI team): turns a producer's request into a musical brief with Claude Sonnet 4.6, then renders audio with ACE-Step, an open-source foundation model for music generation, on the instance's own GPU. It is packaged as a container image in Amazon ECR.
• Delivery agent (Audio Engineering team): reads the rendered track from the shared filesystem and measures it. It then asks Claude Sonnet 4.6 for a delivery chain (EQ, compression, limiting) based on those measurements rather than on the audio itself. Real signal processing applies the chain, and the result is measured again to confirm it hit the delivery target. It is also a container image in Amazon ECR.
• Compliance agent (Release Engineering team): independently re-measures the finished delivery, checks it against the targets the delivery agent claimed, and screens it for harmonic similarity against the studio's own back catalog. If the screen objects, it calls back to the composition agent for a replacement and re-screens. It is delivered as a zip file on Amazon S3.

The producer ends up with a playable .wav file and three reports explaining every decision, according to AWS.

What the setup enables

AWS highlights several capabilities. The composition agent runs ACE-Step directly on the instance's NVIDIA L4, rendering 20 seconds of 48 kHz stereo in about 9 seconds. The model and its dependencies live on a persistent volume, built once for a session and reused by every invocation in it, including after an overnight stop.

Teams can deploy independently: the Audio AI team can push a new composition image without coordinating with the other two teams, whose agents keep running untouched. Sessions can span days. A producer can work on composition on Monday, stop the session overnight and resume delivery on Tuesday, since the instance idles automatically and resumes on the next invoke. Container images from ECR and code packages from S3 can also coexist on one capacity provider.

Implementation notes

The walkthrough has five steps: define the agents, create a capacity provider that provisions the GPU instance and its persistent volumes, deploy each agent as its own runtime, invoke them with a shared session ID, and ship a new version of one agent without disturbing the others. The complete sample is in the AgentCore samples GitHub repository.

Prerequisites include an AWS account able to create infrastructure, the AWS CLI, a VPC with at least one subnet and security group, Bedrock model access for Anthropic Claude Sonnet 4.6, Finch or another OCI-compatible container tool, and Python 3.10+. AWS also requires boto3 1.36.0 or later, or botocore 1.43.72 or later, because older versions lack create_capacity_provider and the deploy script will fail.

Each agent in the sample is a Python application built with Strands Agents. AWS flags two commonly misconfigured details. The entrypoint parameter must be named "context", because the SDK dispatches on that name and it is the only way to read the session ID. The Agent should also be built inside the handler rather than at module scope, since a module-level Agent is shared across concurrent requests and Strands rejects re-entrant invocation. Conversation history is stored on the volume through FileSessionManager, which is how a session resumed days later remembers earlier decisions.

What it means for teams building agents

According to AWS, serverless sessions capped at a few hours do not suit creative workflows where several agents collaborate over days and build on each other's output. Runtime Instances target that case, adding GPUs, persistent volumes and colocation of multiple agents on one instance. Because the instances run in the customer's account, existing Savings Plans and capacity reservations can apply. The music pipeline serves as a reference for teams that want separate groups to ship their own agents independently while still sharing state.