What happened?
In a technical blog post dated August 14, 2026, Amazon Web Services (AWS) introduced a multi-agent architecture that combines Amazon Bedrock AgentCore with Amazon SageMaker AI. The approach aims to let developers use managed foundation models alongside their own cost-optimized or domain-specific models without rewriting the agent framework.
In the sample architecture, three different model-hosting paths were unified within a single Bedrock AgentCore container. The orchestrator agent uses Claude Haiku 4.5, the budget agent uses Claude Sonnet 4.6 via Bedrock, while the financial analysis agent calls a Qwen 3.5 9B model deployed with vLLM on SageMaker AI through an OpenAI-compatible API.
Why does it matter?
Enterprise developers often have to balance cost optimization, data residency, and model flexibility requirements. The architecture AWS demonstrated aims to meet all three requirements within a single production pipeline by combining different models for different workloads.
The blog post also highlights an important technical gap: while the Bedrock AgentCore runtime automatically traces agents with OpenTelemetry, this tracing only covers Bedrock model calls. Token usage for OpenAI-compatible endpoints on SageMaker is not visible by default, making cost tracking and latency debugging harder. AWS addresses this by suggesting a solution that creates a custom gen_ai.chat span and manually extracts token usage from Strands Agents' internal metrics.
Models used in the architecture
| Agent | Model | Hosting | Task |
|---|---|---|---|
| Orchestrator | Claude Haiku 4.5 | Amazon Bedrock | Classifying and routing user intent |
| Budget agent | Claude Sonnet 4.6 | Amazon Bedrock | 50/30/20 budget allocation, structured output |
| Financial analysis agent | Qwen 3.5 9B | Amazon SageMaker AI (vLLM, ml.g6e.2xlarge) | Stock analysis and portfolio construction |
What's known
- Qwen 3.5 9B was deployed on a single ml.g6e.2xlarge instance with an L40S GPU using a Deep Learning Container with vLLM 0.22.1.
- The system uses the 'agents as tools' pattern from the Strands Agents library.
- Deployment was carried out in the ap-south-1 region via the bedrock-agentcore-starter-toolkit.
- The full source code was shared in AWS's associated GitHub repository.
What's next?
AWS states in the blog post that this architecture is presented as a reference implementation, showing how developers can bring their own mix of models to production using a similar setup. The company also notes that Bedrock model availability varies by region and advises developers to check supported models in AWS documentation.
The real decision is utilisation, not the model
The interesting part of this architecture is not the choice of models but the mixing of billing shapes. Bedrock charges per token; the GPU instance on SageMaker runs by the hour whether requests arrive or not. Self-hosting a model is therefore settled not by asking whether it is cheaper per token, but by asking how full that instance can be kept.
At low traffic an idle L40S costs more than a managed model doing the same work; under heavy, sustained load the reverse holds. If there is a data-residency requirement the calculation closes before it opens — there, hosting is not a cost preference but an obligation.
The most valuable part of the post is that it admits a gap: AgentCore's automatic tracing sees only Bedrock calls, and token usage at the SageMaker endpoint is not recorded by default. Closing that hole by hand-rolling a span exposes the hidden price of mixed hosting — a component whose cost you cannot see is a component you cannot optimise.