Most developers working with artificial intelligence today can get a model to respond to a query. However, few have managed to launch an agent that operates stably in a production environment. The problem slowing down most agent projects lies in frameworks that restrict abstractions, systems that function as black boxes when errors occur, and constantly growing enterprise readiness requirements.
Ashita Prasad, an advocate developer at AWS, addressed this issue during a two-hour hands-on workshop, DevSparks Bengaluru 2026. During this event, 170 developers worked with her using Strands Agents—an open-source SDK developed by AWS. The session allowed participants to create a basic agent and then enhance it with built-in guardrails, persistent memory, and observability capabilities.
Before starting the coding, Ashita highlighted three aspects of the problem. First, there is a steep learning curve between understanding agent concepts and their actual implementation. Second, most frameworks sacrifice flexibility for convenience, which becomes problematic when scaling. Third, and most critically, the systems remain opaque. She noted that the user does not know what the agent is doing behind the scenes, what tool calls it is making, or what messages it is sending, turning it into a black box and hindering development and maintenance.
Strands Agents uses a model-based approach, allowing the base language model to dynamically decide whether to call a tool, return an answer, or continue reasoning, while fully exposing the agent's operational cycle to the developer. This cycle is simple: a user request comes in, the model determines the next step, tools are called if necessary, results are returned to the model, and finally, a final answer is formed. Strands handles all the necessary infrastructure between these stages.
The workshop proceeded through a series of labs, each adding new functionality to the agent being created. It started with a minimal agent: a model, a system prompt, and a user query. Participants then added tools, beginning with a custom weather function, and subsequently community-provided tools like a calculator included with Strands.
The model provider lab featured Ollama, enabling developers to run large language models locally, which is important for those without access to a cloud model subscription. Participants built a file-handling agent using the local Llama 3.2 model, which could read, list, and write files in directories, demonstrating that the Strands architecture is universal regardless of model location.
The AWS services lab significantly increased the complexity. Participants created a restaurant booking agent capable of creating, retrieving, and deleting booking records stored in DynamoDB, as well as extracting restaurant information from the Amazon Bedrock Knowledge Base indexed in OpenSearch Serverless.
Ashita emphasized an important architectural point: standard operations, such as writing to a database, do not require the agent to go through a reasoning process. She explained that creating a booking is akin to a database write, lacking ambiguity. Knowing when not to use an LLM is as important as knowing when to apply it.
The MCP tools lab covered both data transmission mechanisms: standard input/output for local servers and streaming HTTP for remote ones, and also demonstrated the ability to connect multiple MCP servers simultaneously. This was followed by a streaming lab that examined asynchronous iterators and callback handlers as two complementary ways to inform users during a long-running agent operation.
The last two labs focused on what differentiates a workshop demonstration from a deployable product. In the guardrails lab, Amazon Bedrock Guardrails was used to configure topic-level blocks, content filters for categories such as violence, prompt injection detection, and triggering based on specific words. Customizable response messages were provided for blocked inputs and outputs. A specific use case involved an agent with access to a customer database that must never disclose Personally Identifiable Information (PII), such as Aadhaar or PAN numbers, regardless of the query phrasing.
The memory lab tackled another production challenge. Although Strands agents default to saving conversation history within a session, this memory disappears after the session ends. Using Mem0 and OpenSearch Serverless, participants learned how to persist user preferences and context across sessions so that the agent remembers the interlocutor upon the next interaction.
Collectively, these two labs reflected a single design principle that permeated the entire workshop: production readiness is not a feature added at the end. Observability, security, and memory are architectural decisions that must be made from the very beginning.
The full source code is available on GitHub in the Strands Agents Samples repository, and each lab can be run locally using Ollama for developers who do not have a cloud model provider. The same repository features multi-agent labs covering agent swarms and graphs for those who wish to delve deeper into the topic.
The workshop concluded with a reminder about the necessity of cleaning up resources for those who conducted labs in their own AWS accounts, which proved to be a useful tip for the target audience.
