Strands Agents and the Model-Driven Approach

Until recently, building AI agents meant wrestling with complex orchestration frameworks. Developers wrote elaborate state machines, predefined workflows, and extensive error-handling code to guide language models through multi-step tasks. We needed to build elaborate decision trees to handle “what if the API call fails?” or “what if the user asks something unexpected?” Despite this effort, agents still broke when they encountered scenarios that weren’t anticipated.

Strands Agents SDK embraces a model-driven approach that eliminates this brittleness entirely. Instead of trying to predict and code for every possible scenario, we let modern large language models drive their own behavior, make intelligent decisions about tool usage, and adapt dynamically to whatever comes their way. This approach is more resilient because it lets models reason through problems dynamically. When an API call fails, the model doesn’t crash – it reasons about alternatives. When a user asks something unexpected, the model doesn’t follow a predetermined “I don’t understand” path – it figures out how to help, using the tools available. The model’s reasoning capabilities handle edge cases better than any state machine we could write.

The model-driven approach emerged from AWS teams’ real-world experience building production agents for Kiro, Amazon Q Developer, and AWS Glue. What we discovered changed how we think about agent architecture entirely: the orchestration frameworks we’d built to guide earlier models were now getting in the way of what modern LLMs could do naturally.

Using the model as the orchestrator doesn’t mean sacrificing developer control, however. Strands provides a clean, simple interface that gets you started in minutes, while offering powerful configurability when you need it. Built-in evaluation tools help you understand and validate agent behavior, ensuring you maintain confidence even as models make autonomous decisions. This balance between simplicity and flexibility is what makes the model-driven approach practical for both rapid prototyping and production systems. Strands evolves with you.

In this post, we’ll explore how the model-driven approach emerged from real-world production experience and show you practical patterns for building agents that think for themselves.

When orchestration becomes a limitation

Traditional agent frameworks emerged when language models needed heavy guidance. Developers built elaborate state machines, predefined workflows, and complex orchestration logic because models couldn’t reliably reason about their next steps. We would write hundreds of lines of code just to handle the flow between “gather information,” “analyze data,” and “provide response” – and still end up with agents that broke when users asked questions in unexpected ways.

The AWS teams that I worked with building Amazon Q Developer experienced this firsthand. We initially used traditional orchestration frameworks, but changes in product requirements and user behavior required significant science and engineering effort to calibrate the system to handle new use cases. Machine learning (ML) routers and classifiers would return rigid outputs for guardrails – static text like “I’m sorry, I can’t answer that question” – without offering alternatives or explanations in an interactive manner that was helpful and felt intelligent.

Modern models are sophisticated enough to be their own orchestrators. This was the key insight that changed everything for us. While structured workflows still have their place – particularly for compliance requirements or well-defined business processes – the model-driven approach eliminates the need for rigid orchestration in most scenarios.

When the Q Developer teams switched to a model-driven approach, the system could dynamically handle changing product requirements and respond coherently no matter what was thrown at it. Instead of rigid guardrail responses, the agent could offer alternative solutions and use guardrail output as context so that the model understood why it couldn’t answer certain inputs. This enabled a single personality and tone across multi-agent systems, allowed engineers across Amazon to contribute their subject matter expertise while maintaining coherence. It also provided the right context to the model at the right time with powerful tools for helpful, intelligent responses.

When you provide a model with tools, it doesn’t just execute them mechanically. It reasons about the best approach, considers multiple strategies, and adapts its behavior based on what it discovers. A model analyzing a performance issue might start with system metrics, realize the bottleneck is actually in the database, pivot to query analysis, and then suggest both immediate fixes and long-term architectural improvements – all without being explicitly programmed for that sequence.

The operational benefits were transformative. What previously took months to develop now took weeks. Our teams could quickly make use of the latest large language model (LLM) features like tool calling, extended and interleaved thinking, multi-agent systems, meta agents, MCP, and A2A – all while keeping a simple interface for developers that can be fully customized for production deployments of AI agents.

This philosophy extends beyond single agents. Whether you’re building a simple data analysis agent or a complex multi-agent system, the model decides when to collaborate with other agents, when to delegate tasks, when to dig deeper into a problem, and when to provide a final answer.

The agent loop: Where intelligence meets action

At the heart of this philosophy lies the agent loop – a natural cycle of reasoning and action that reflects how intelligent systems think and work. This approach builds upon the ReAct paradigm (ReAct: Synergizing Reasoning and Acting in Language Models), which demonstrates how language models can generate both reasoning traces and task-specific actions in an interleaved manner, creating greater synergy between thinking and acting.

The model engages in continuous reasoning, asking questions like:

• “What am I trying to accomplish here?”
• “What information do I need?”
• “Which tools would be most effective?”
• “How do these results change my understanding?”
• “Should I continue exploring or provide an answer?”

This internal reasoning process is what makes model-driven agents so powerful. They don’t just execute predefined steps – they think, adapt, and evolve their approach in real-time.

Guiding intelligence through context

While the model drives its own behavior, that behavior is shaped by the context it receives. In the model-driven approach, you guide agent intelligence not through rigid control structures, but through carefully crafted context that includes system prompts, tool specifications, and conversation history.

Think of it like hiring a skilled consultant. You don’t micromanage their every step – instead, you give them clear objectives, explain what resources are available, and provide relevant background. The model-driven approach works the same way.

System prompts establish the agent’s role and goals – they set the foundational identity and high-level objectives that guide all decision-making. Instead of dictating specific steps, effective system prompts describe what success looks like and provide principles for decision-making. Rather than “First check the database, then validate the input, then process the request,” you might write “You help users analyze their data efficiently and accurately, always validating inputs before processing.”

Tool specifications define capability boundaries and usage guidance – they communicate not just what tools are available, but how and when they should be used. Well-designed tool descriptions become part of the model’s reasoning process. A tool description like “Use this for complex mathematical calculations that require precision” helps the model choose appropriately between a calculator tool and writing Python code.

Conversation history maintains task continuity and evolving context – it provides the specific details that allow agents to maintain coherence across interactions. As conversations grow longer, managing this context becomes crucial for maintaining performance while preserving relevant information. Context management is crucial to model-driven agents – it’s the difference between an agent that maintains coherent, intelligent conversations and one that loses track of important details or exceeds token limits. Strands provides a simple interface that lets developers define agent system prompts, tools, and context management behavior without getting lost in implementation complexity.

Sliding window approaches keep recent messages and discard older ones: simple and efficient. Summarization techniques preserve key information from longer conversations within token limits – better for complex, evolving discussions. The goal is giving the model the most relevant context for making good decisions about your specific use case.

This represents a major shift from procedural programming to contextual programming. Instead of writing “if this, then that” logic, you’re crafting the context that helps the model figure out the best approach itself.

from strands import Agent
from strands_tools import calculator, file_write, python_repl

# Simple: Get started in seconds
agent = Agent(
    tools=[calculator, file_write, python_repl],
    system_prompt="You are a helpful assistant that can perform calculations and verify them with code."
)

# The model autonomously decides: calculate first, then verify with code
agent("Calculate the compound interest on $10,000 at 5% annually for 10 years")

This design philosophy extends throughout Strands. You can build sophisticated agents without getting lost in configuration, but every aspect remains customizable when your use case demands it.

Scaling model-driven agents with Strands

The model-driven approach scales naturally while maintaining the same clean developer experience. A single agent equipped with appropriate tools can handle complex tasks that would traditionally require multiple specialized components. When you do need multiple agents, the models coordinate themselves through several proven patterns. Strands provides four main approaches for multi-agent coordination, each suited to different use cases:

• Agents-as-tools: Hierarchical systems where specialists serve as intelligent tools
• Swarms: Autonomous collaboration with self-organizing teams of agents
• Graphs: Structured workflows with deterministic execution paths
• Meta agents: Dynamic agents that can modify their own orchestration behavior

Whether you’re building simple hierarchies or complex adaptive systems, Strands keeps the interface clean while providing the configurability needed for production systems.

Agents-as-tools: Hierarchical intelligence

When a single agent needs specialized expertise, agents-as-tools transforms other agents into intelligent tools. This creates natural hierarchies where an orchestrator agent delegates to specialists, maintaining clear separation of responsibilities while leveraging the model-driven approach at every level. How does the orchestrator decide which specialists to consult? The model reasons through the request just like it would reason about tool selection. When a user asks “Plan a business trip to Tokyo and research the market opportunity there,” the orchestrator recognizes this requires both travel planning and market research expertise. It might consult the travel advisor first to understand logistics, then use those constraints to guide the research analyst’s work.

from strands import Agent, tool

@tool
def research_analyst(request: str) -> str:
    """Research specialist for market analysis"""
    research_agent = Agent(
        system_prompt="You are a research specialist who gathers and analyzes market information.",
        tools=[web_search, calculator]
    )
    return str(research_agent(request))

@tool
def travel_advisor(request: str) -> str:
    """Travel planning specialist for logistics and recommendations"""
    travel_agent = Agent(
        system_prompt="You are a travel planning specialist who helps with logistics, bookings, and recommendations.",
        tools=[flight_search, hotel_search, weather_api]
    )
    return str(travel_agent(request))

# Orchestrator decides when to consult specialists and how to synthesize their input
executive_assistant = Agent(
    system_prompt="You coordinate with specialists to provide comprehensive assistance.",
    tools=[research_analyst, travel_advisor]
)

The orchestrator model decides which specialists to consult and how to synthesize their input – no predetermined workflows required. This pattern works well when you need clear expertise boundaries and want delegation patterns with a main leading agent.

Swarms: Autonomous collaboration

Swarms enable agents to collaborate autonomously in a self-organizing manner, deciding when to hand off tasks to each other. This works well for creative collaboration and emergent problem-solving where multiple perspectives add value.

Consider a market research project where you need to analyze a new product opportunity. A traditional approach might follow a rigid sequence: research → analysis → writing. But real research is messier – you might discover during analysis that you need additional data, or realize while writing that a different analytical framework would be more compelling.

from strands import Agent
from strands.multiagent import Swarm

researcher = Agent(name="researcher", system_prompt="You research topics thoroughly...")
analyst = Agent(name="analyst", system_prompt="You analyze data and create insights...")
writer = Agent(name="writer", system_prompt="You write comprehensive reports...")

# Agents coordinate autonomously through model-driven handoffs
market_research_team = Swarm([researcher, analyst, writer])

In a swarm, the researcher might start gathering information, then hand off to the analyst when they’ve found interesting patterns. The analyst might discover gaps and hand back to the researcher for more specific data. The writer might join the conversation early to help shape the research direction based on what will make a compelling narrative.

The key difference from agents-as-tools is shared context. In hierarchical systems, the orchestrator decides what information to pass between specialists. In swarms, all agents have access to the same conversation history, enabling more fluid collaboration and high-level instructions. You can tell a swarm “research this market opportunity” without specifying exactly how the work should be divided – the agents figure it out based on their shared understanding of the evolving task.

Swarms trade predictable execution for emergent capabilities, making them ideal for complex research tasks, brainstorming scenarios, and creative projects where the best approach isn’t clear upfront.

Graphs: Structured workflows

Graphs provide deterministic workflows where execution follows predefined paths. While individual agents within the graph use model-driven execution, the graph structure ensures specific sequences and dependencies are maintained.

This pattern excels for business processes that require mandatory checkpoints or compliance requirements. For example, a financial analysis workflow might require research → risk assessment → regulatory review → final recommendation, with each step building on the previous one and certain steps requiring specific approvals.

from strands import Agent
from strands.multiagent import GraphBuilder

builder = GraphBuilder()

builder.add_node(researcher, "research")
builder.add_node(analyst, "analysis")
builder.add_node(writer, "report")

builder.add_edge("research", "analysis")
builder.add_edge("analysis", "report")

graph = builder.build()

AWS teams have used graphs for data pipeline orchestration where certain transformations must happen in sequence, and for compliance workflows where audit trails require specific step-by-step documentation. The model-driven approach still applies within each node – the research agent can adapt its approach based on what it discovers – but the overall flow remains predictable.

The limitation of graphs is their rigidity. If the analyst discovers they need additional research, they can’t directly request it – the workflow would need to complete and potentially restart. This makes graphs ideal for well-understood processes but less suitable for exploratory or creative work.

Meta agents: Dynamic orchestration

Meta agents are single agents equipped with tools that let them think about thinking – they can dynamically create other agents, orchestrate workflows, and engage in recursive problem-solving. They represent the ultimate expression of the model-driven approach: agents that can architect their own orchestration techniques.

Think of a meta agent as a senior architect who can not only solve problems but also decide how to structure the problem-solving approach. When faced with a complex challenge, it might reason: “This requires both deep research and creative synthesis. I should create a swarm of specialists and then use a graph to ensure the final deliverable meets quality standards.”

from strands import Agent
from strands_tools import graph, swarm, use_agent, think, workflow

meta_agent = Agent(
    system_prompt="You can dynamically create specialized agents and orchestrate complex workflows.",
    tools=[graph, swarm, use_agent, think, workflow]
)

Unlike other patterns where you define the agents and tools upfront, meta agents can spawn new specialists and create custom tools on demand. Analyzing a new technology trend? The meta agent might create domain experts for regulatory implications, market dynamics, and technical feasibility – agents that didn’t exist until the specific need arose. It might also develop specialized tools for data collection, analysis frameworks, or reporting formats tailored to that specific domain.

This dynamic agent and tool creation enables systems that grow and adapt rather than following fixed patterns.

Building confidence through evaluation

The model-driven approach requires robust evaluation to build confidence that agents are performing as expected, especially when they’re making autonomous decisions about tool usage and task orchestration.

Since model-driven agents make dynamic decisions rather than following predetermined paths, evaluation becomes both more important and more nuanced. You need to assess not just whether the agent got the right answer, but whether it made good decisions about how to approach the problem.

The model-driven approach transforms how we think about evaluation itself. Traditional testing with static datasets becomes insufficient when agents adapt their behavior dynamically. This shift requires new evaluation paradigms that match the intelligence of the systems being tested.

LLM judges offer a powerful approach for evaluating agent responses at scale, but they must be carefully calibrated to align with end user expectations. An LLM judge that prioritizes technical accuracy might miss nuances that matter to actual users, such as tone, helpfulness, or practical applicability.

Simulated users driven by LLMs enable dynamic testing with evolving datasets, creating realistic interaction patterns that static test cases cannot capture. However, these simulated users must also be calibrated to behave like real end users rather than idealized test scenarios. The goal is authentic user behavior, not perfect user behavior.

Key evaluation dimensions for model-driven agents include:

• Tool selection appropriateness – Did the agent choose the right tools for the task?
• Reasoning quality – Does the agent’s approach make logical sense?
• Adaptability – How well does the agent handle unexpected scenarios?
• Efficiency – Does the agent accomplish tasks without unnecessary steps?

The non-deterministic nature of model-driven agents means you need statistically significant baselines and continuous evaluation to track performance over time. This investment in evaluation enables you to confidently deploy agents that make autonomous decisions.

The paradigm shift: From rigid control to dynamic adaptation

The model-driven approach represents a fundamental shift in how we think about AI agents. Instead of trying to control every aspect of agent behavior through complex orchestration, we provide the right tools, context, and objectives, then let the model determine the best approach dynamically.

This shift addresses a core problem: predetermined logic struggling to handle an unpredictable world. Traditional frameworks break when users ask questions in unexpected ways, when APIs return unexpected responses, or when business requirements change. They fail because they can only handle scenarios that developers anticipated and coded for.

Model-driven agents adapt. When an API call fails, they reason about alternatives. When a user asks something unexpected, they figure out how to help using available tools. When requirements evolve, they adjust their approach without needing code changes. This adaptability comes from leveraging the model’s reasoning capabilities rather than fighting against them.

The approach taken in Strands enables agents to handle changing requirements and data while reducing the complexity developers need to manage. You can have both: the simplicity to get started quickly and the power to configure everything when production demands it.

The model-driven approach isn’t about building better orchestration frameworks. It’s about recognizing that modern LLMs have evolved beyond needing such rigid guidance. By leveraging the model’s reasoning capabilities for orchestration, we can build agents that are both more capable and easier to develop. This philosophy is the foundation that everything else in Strands is built upon. Go to the Strands Agents website to try it out today.

Looking for more open source content? Be sure to follow AWS Open Source on LinkedIn!