From My First AI Agent to an AWS Architecture Roaster: My Journey Through the AWSUG Madurai Builders Skill Sprint
In this blog, I share my experience completing the AWSUG Madurai Builders Skill Sprint, where I built AI agents using the Strands Agents SDK, Amazon Bedrock, and MCP servers. Along the way, I explored tool calling, memory, streaming responses, cloud debugging, and ultimately created an AWS Architecture Roaster that combines official AWS documentation with humorous architecture reviews.
When I signed up for the AWS User Group Madurai Builders Skill Sprint, I expected to learn how to build AI agents. What I didn't expect was to spend hours debugging AWS permissions, wrestling with Bedrock model access, discovering the power of MCP servers, and eventually building an AI that professionally insults cloud architectures.
Over the course of five challenges, I went from creating a simple local AI assistant to building a fully-fledged MCP-powered AWS Architecture Roaster. Along the way, I learned that modern AI systems are much more than just language models—they are ecosystems of tools, memory, external services, and orchestration.
This blog documents that journey, including the successes, failures, and lessons learned along the way.
Challenge 1: My First AI Agent
The first challenge served as an introduction to the Strands Agents SDK.
The task was simple: create an agent running locally using Ollama and the Llama 3.2 model. Coming into the challenge, I had interacted with AI assistants countless times, but I had never built one myself.
After setting up Ollama and connecting it to Strands, I created a basic agent and asked it: "Tell me a fun fact about Bangalore, India." It worked.
While the challenge itself was straightforward, it introduced an important idea: an AI agent is not the model itself. The model generates responses, but the agent acts as the layer that manages interactions and eventually coordinates tools, memory, and external services.
This challenge gave me my first look at how modern AI applications are structured under the hood.
What I Learned
- How Strands Agents are created
- How local models can be integrated using Ollama
The purpose of system prompts
- The distinction between an AI model and an AI agent
Challenge 2: Teaching the Agent to Use Tools
The second challenge introduced one of the most important concepts in agentic AI: tool usage.
Instead of relying solely on the language model, the agent could now invoke external functions to perform tasks more accurately.
I implemented a weather tool using the wttr.in API, an age calculator tool and a calculator tool provided by Strands. This challenge also marked my transition from local models to Amazon Nova Pro through AWS Bedrock.
That transition wasn't entirely smooth. The first time I ran the challenge, I was greeted with authentication errors and invalid security token messages. The code itself was correct, but my AWS credentials were not configured properly.
After setting up my credentials and resolving the permissions issue, the agent successfully began using tools.
For the first time, I could see the model deciding: "This is a calculation. I should use the calculator."
instead of attempting to estimate the answer itself.
What I Learned
- Tool calling and orchestration
- Bedrock model integration
- AWS credential management
- The importance of giving agents access to external capabilities
Challenge 3: Memory – The Most Frustrating Challenge
Challenge 3 introduced persistent memory.
The goal was simple in theory: "Remember things across conversations."
The implementation used the mem0 memory system combined with a FAISS vector store. The challenge began with a series of missing dependencies. The agent refused to run until I manually installed packages such as: mem0 and opensearch-py
After resolving those issues, I encountered another problem.
The memory tool itself appeared to be using an Anthropic model behind the scenes for memory extraction. Every time the agent attempted to store or retrieve information, AWS Bedrock returned an error indicating that the required Anthropic use-case permissions had not been configured for the account.
This led to a strange situation: The agent would confidently say: "I've remembered your name.", while simultaneously failing to actually store anything.
Although I never fully resolved the backend memory issue, the challenge taught me something valuable: Building AI systems isn't just about writing code. It often involves understanding dependencies, infrastructure, permissions, and third-party services.
What I Learned
- Vector databases and semantic search
- Long-term memory systems
- Dependency management
- Debugging cloud-based AI infrastructure
Challenge 4: Bringing Everything Together
Challenge 4 combined everything from the previous challenges.
The final agent included: calculator tool, weather tool, age calculator tool, memory integration and streaming responses
This challenge introduced another debugging adventure.
The agent initially crashed with a callback handler error: stream_handler() got an unexpected keyword argument 'init_event_loop'
At first glance, the error seemed intimidating, but after inspecting the callback implementation, I realized the function signature didn't match what the newer Strands SDK expected.
After fixing the callback handler, the agent successfully streamed responses and invoked tools in real time. Watching the agent dynamically decide which tools to use felt very different from the earlier challenges. It finally resembled the kind of AI assistant people interact with in real-world applications.
Even though the memory component still suffered from the backend issues discovered in Challenge 3, the overall architecture worked.
What I Learned
- Streaming AI responses
- Multi-tool orchestration
- Debugging SDK compatibility issues
- Combining multiple AI capabilities into one system
Challenge 5: Building Something Original
The final challenge had a simple premise: build something entirely your own using Strands Agents, Amazon Bedrock, and at least one MCP server. No instructions, no guided steps — just a blank canvas.
My first few ideas were pretty safe. An AWS Documentation Assistant. A learning coach. An interview prep bot. All of them would have worked, but none of them felt worth submitting as the final challenge. I wanted to build something people would actually remember.
The idea came from thinking about architecture reviews. Anyone who's sat through one knows the dynamic — an experienced engineer looks at your system design, and the feedback is blunt enough to sting but specific enough that you never forget it. I started wondering if I could recreate that with an AI agent.
That turned into the AWS Architecture Roaster. You describe your AWS setup, and the agent tears it apart — humorously, but using real AWS documentation to back every criticism. The goal wasn't just to be funny. It was to make the feedback stick.
The agent connects to the AWS Documentation MCP server, so when you describe your architecture it actually goes and looks things up rather than working from baked-in knowledge. Watching it pull from official docs and weave that into a response made it feel genuinely capable rather than just a clever prompt.
Getting the personality right took the most iteration. I wanted it to sound like a cloud architect who has reviewed one too many t2.micro monoliths and has officially lost patience — but whose criticism is still grounded and useful. Every joke needed a real recommendation behind it.
My favourite part ended up being the scoring system. Each response ends with an Architecture Score out of ten and a Roast Severity: Mild, Medium, Spicy, or Nuclear. But the one I'm most proud of is "Disappointed" — reserved for architectures that are actually good. If you follow best practices, the agent has nothing to work with, and it knows it. "I came here prepared to criticise someone. You've robbed me of that joy."
Looking back, this was the most fun I had in the entire sprint. It pulled together everything from the earlier challenges — agents, tools, prompts, Bedrock models, MCP integration — into something that felt like more than just a demo. AI agents don't have to just answer questions. With the right setup, they can be genuinely entertaining and still teach you something.
Final Thoughts
Before this sprint, I thought of AI agents as chatbots with slightly better prompts. That mental model didn't survive contact with the actual material.
By the end, it was clear that agents are something different — systems that coordinate models, tools, memory, and external services to do things a single prompt never could. Building from a simple local assistant all the way to an MCP-powered Architecture Roaster made that shift concrete rather than theoretical.
The bigger takeaway isn't about making models smarter. It's that the interesting work happens in the design around the model — what tools it can reach, what information it can pull, how it hands things off. That's where the useful stuff gets built.
Also, apparently, that's where you teach an AI to roast someone's cloud infrastructure. So there's that.
Thanks to AWS User Group Madurai for putting together a skill sprint that was actually fun to work through. Practical, well-paced, and genuinely left me with something to show for it.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article