Building production agents using AWS’s open source Strands Agents SDK

Most developers working with AI today can get a model to respond to a prompt. A surprising few have shipped an agent that holds up in production. The distance between those two points is where most agentic projects stall: frameworks that lock you into their abstractions, systems that behave like black boxes when something goes wrong, and an enterprise readiness bar that keeps moving every time a new requirement surfaces.

This was the problem Ashita Prasad, Developer Advocate at AWS, chose to address head-on at DevSparks Bengaluru 2026, across a two-hour hands-on workshop where 170 developers opened their laptops and built alongside her. The session used Strands Agents, an open source SDK developed by AWS, taking participants from a basic agent all the way to one with guardrails, persistent memory, and observability built in.

Why existing frameworks fall short

Ashita framed the problem in three parts before writing a single line of code. First, the learning curve between understanding agentic concepts and implementing them is steep and rarely acknowledged.

Second, most frameworks trade flexibility for convenience, constraining developers in ways that become painful at scale.

Third, and most consequentially, the systems remain opaque. "You do not know what the agent is doing behind the scenes, what tool calls it is doing, what messages it is sending," she said. "It still remains a black box, and because it is a black box, it becomes very challenging for you as a developer to build and maintain them."

Strands Agents takes a model-driven approach to address this, letting the underlying LLM dynamically decide whether to call a tool, return a response, or continue reasoning, while exposing the full agentic loop to the developer. The loop itself is straightforward: a user prompt goes in, the model decides what to do next, tools get called if needed, results feed back into the model, and a final response comes out. What Strands handles is all the plumbing in between.

Building up, layer by layer

The workshop moved through a progression of labs, each adding a capability to the agent that the participants were building. It started with the most minimal possible agent: a model, a system prompt, and a user query. From there, participants added tools, first a custom weather function, then community-built tools like a calculator that come packaged with Strands out of the box.

The model provider lab introduced Ollama, which lets developers run LLMs locally, an important inclusion for anyone without access to a cloud model subscription. Participants built a file operations agent powered by a local Llama 3.2 model that could read, list, and write files in a directory, demonstrating that the same Strands architecture works regardless of where the model lives.

The AWS services lab stepped up the complexity considerably. Participants built a restaurant booking agent that created, retrieved, and deleted bookings stored in DynamoDB, and pulled restaurant information from an Amazon Bedrock Knowledge Base indexed in OpenSearch Serverless.

Ashita made a deliberate architectural point here: standardized operations like database writes do not need the agent to reason. "If I want to create a booking, it creates a booking. It's just like an entry in the database. There is no question of any ambiguity here," she said. Knowing when not to use the LLM is as important as knowing when to use it.

The MCP tools lab covered both transport mechanisms, standard input/output for local servers and streamable HTTP for remote ones, and showed how multiple MCP servers can be connected simultaneously. The streaming lab followed, covering async iterators and callback handlers as two complementary approaches to keeping users informed during longer agent runs.

The production layer

The final two labs addressed what separates a workshop demo from something deployable. The guardrails lab used Amazon Bedrock Guardrails to configure topic-level blocks, content filters for categories like violence, prompt attack detection, and specific word triggers, all with customizable response messaging for blocked inputs and outputs. The use case was concrete: an agent with access to a customer database should never surface PII like Aadhaar or PAN numbers, regardless of how the query is phrased.

The memory lab tackled a different class of production problem. Strands agents store conversation history within a session by default, but that memory disappears when the session ends. Using Mem0 and OpenSearch Serverless, participants saw how to persist user preferences and context across sessions, so an agent remembers who it is talking to the next time around.

Taken together, the two labs reflected a consistent design principle running through the entire workshop: production readiness is not a feature to be added at the end. Observability, safety, and memory are architectural decisions that need to be made from the start.

Taking it further

The full codebase is also available on GitHub under the Strands Agents Samples repository, and every lab runs locally with Ollama for developers without a cloud model provider. Multi-agent labs covering swarms and agent graphs are part of the same repository for those ready to go further.

The session ended with a cleanup reminder for anyone running labs on their own AWS account, a practical note that landed with the right audience.