AWS teaches Strands Agents to work with any model on SageMaker

The corporate world of AI-agents is experiencing a moment that can be compared to the appearance of universal adapters for electronics: Amazon Web Services has shown how to make its Strands Agents agent framework work with literally any language model deployed on SageMaker, even if that model has no idea about Bedrock platform's standard API.

To understand the significance of this step, we need to go back a few months. AWS launched Strands Agents as an open framework for creating AI-agents — programs capable of independently planning actions, using tools, and solving multi-step tasks. The framework was initially tailored to models available through Amazon Bedrock, which created a convenient but closed ecosystem. Companies that wanted to use their own fine-tuned models or open LLMs like Llama, deployed on SageMaker AI endpoints, found themselves facing a wall of format incompatibility.

New guidance, published on the AWS Machine Learning blog, solves exactly this problem. Amazon engineers describe in detail the process of creating so-called custom model parsers — intermediate layers that translate Strands Agents requests into a format understandable by a specific model, and conversely transform the model's responses back into the structure expected by the framework. Essentially, it's a translator between two systems speaking different languages.

As a practical example, AWS demonstrates deploying Llama 3.1 using SGLang — a high-performance inference engine for language models — on SageMaker infrastructure. To simplify the containerization process, the ml-container-creator tool from AWS Labs is used, which automates the creation of Docker containers for ML models. After deploying the model, the developer implements a custom parser that intercepts Strands Agents calls, reformats them from Bedrock Messages API into a format compatible with the SGLang endpoint, receives the response, and transforms it back. Technically this is not rocket science, but without clear documentation and examples, the process could have turned into days of debugging.

Why is this really important? Because in the corporate environment, one model rarely solves all tasks. Companies train specialized models on their data, experiment with open architectures, combine multiple models in a single workflow. Until now, using such models in agent scenarios on AWS required either switching to Bedrock-compatible formats or writing custom orchestration from scratch. Now there is a standardized way to connect practically any LLM to the agent framework, while preserving all the advantages of Strands — tool management, reasoning chains, error handling.

This step fits into AWS's broader strategy of turning its ML platform into the most open ecosystem possible. Amazon clearly realized that attempting to lock clients into Bedrock is counterproductive in a world where new open models appear every week and corporations increasingly invest in their own fine-tuned solutions. Instead of competing with each new model, AWS offers infrastructure where anything can run, and now — an agent framework that can work with that "anything."

It's worth noting the competitive context. Google with Vertex AI Agent Builder and Microsoft with AutoGen and Semantic Kernel are actively developing their own agent platforms. However, AWS's approach with open custom parsers looks more flexible: instead of dictating which models to use, Amazon provides tools for integrating any. This could become the deciding argument for enterprise clients who don't want to depend on a single model vendor.

Looking ahead, we can expect the emergence of ready-made parsers for popular open models and inference engines — the community will surely begin creating a library of compatible configurations. For the AI-agents market, this means another step toward maturity: technology stops being the privilege of those using a specific model from a specific provider, and becomes available to any team ready to deploy an LLM on cloud infrastructure.