Lesson 2: Switching Model Providers

Code for this lesson can be found here.

Model Choice as System Architecture

Different models are good at different things. Some are optimized for coding tasks or long-running workflows, while others are better at planning, deep research, or are optimized for speed and low-latency tasks.

As the agent systems you build become more sophisticated, it’s common to use different models powering different agents within the same system. You might use one model for orchestration, another for specialized coding tasks, and another for validation or evaluation steps.

And in some cases, it’s useful to use a completely different model provider for different tasks like evaluations, so you aren’t relying on the same model and training patterns for both generation and verification.

We’ll cover strategies for building those kinds of multi-agent systems later in the course, but the important thing right now is understanding that model choice becomes a part of your architecture because different models have different strengths, costs, latency characteristics, and tool use behaviors. This is one of the reasons Strands abstracts model providers behind a common interface: You instantiate a model class, pass it to the agent, and everything else stays the same.

Working with the Defaults: Amazon Bedrock

Let’s look at how it works. We’ll start with the default provider, Amazon Bedrock.

When you create an agent with no model arguments, Strands uses Bedrock with Claude Sonnet 4.6 in us-west-2. In production, you usually want to be explicit about what model you’re using and how it’s configured. So instead, we import BedrockModel.

Then we create an instance of our model and pass in a specific model ID like claude-opus-4-6, and then we pass that directly to the instance of the agent when we create it. Now we can give this a run.

Now the agent is using Opus instead of the default model.

Switching to Anthropic and OpenAI APIs

But maybe you want to use Anthropic’s APIs directly instead of running it on Bedrock. Well, the pattern stays the same.

We import AnthropicModel, then we can create the instance of our Anthropic model, passing in an Anthropic API key, and then you would pass this into the agent instead of the Bedrock model.

You could swap this same thing out for an OpenAI model as well, and it works the same way.

Running Local Models with Ollama

Now let me show you another interesting option you can set up with Strands: using local models with Ollama. Ollama lets you run models directly on your own hardware without cloud inference APIs.

In Strands, you would create an Ollama model provider just like this, and then you would point it at the local Ollama server that you have running. I have Gemma running locally already, so we can provide this model provider to our agent, save the file, and then give it a run.

Local models are useful for low-cost experimentation, offline development, and privacy-sensitive workflows. There are trade-offs, though. Local models are often smaller and less capable than frontier hosted models, and tool calling quality can vary significantly depending on the model. You’ll want to test carefully for your own specific use case.

Looking Ahead

In the next video, we’ll look more at tools and Model Context Protocol, or MCP, which is one of the main ways agents connect to external systems and capabilities.

Learn more: Model Providers