I Built My First AWS Agent Workflow, and the Hardest Part Was Getting It to Stop Assuming Things

TL;DR I recently finished a project from Udacity's Future AWS Agent Engineer Nanodegree Program, which I was able to take through the AWS AI & ML Scholarship. I built a customer support agent using Amazon Bedrock AgentCore, AgentCore Gateway, AWS Lambda, DynamoDB, and an FAQ. The agent had to understand whether a customer was reporting a bug, asking a question that could be answered from the FAQ, or asking for something that needed human support. I finished it in about two days and passed on my first attempt with a correctness score of 0.83. I did not have enough time to go back and refine it or run another evaluation round because there was a lot happening in my life at the time. The part I learned the most from was actually one of my evaluation failures. For a bug report, I had told the agent that it needed 3 things before creating a ticket: a description of the problem, steps to reproduce it, and the environment where it happened. But in 2 test cases, the model understood what the customer was talking about and created the ticket even though one of those required pieces of information was missing. That made me realize something I had not thought about enough before: understanding a request is not the same as having enough information to safely take an action. That is the main lesson I took from this project. Building an agent is not only about making the model capable of answering. It is also about being clear about when it should act, when it should ask for more information, and when it should stop and hand the request to a person. I know there are already many great articles about AWS, AgentCore, and AI agents, and I have learned from many of them myself. I am still learning too, so this is simply my experience of building this project, what confused me, what the evaluation showed me, and what I would do differently next time. Table of Contents - I Want to Start With Something Honest - What I Built and How the Pieces Fit Together - The Prompt Was Doing More Than I Expected - The Evaluation Showed Me Where I Was Wrong - What I Would Change and What I Learned - If You Are Also Starting Out - I Would Love to Hear From You - A Small Thank You - My Final Takeaway - 🤝 Let's Stay Connected I Want to Start With Something Honest I finished another project recently, and this one was a little different for me. It was part of the Future AWS Agent Engineer Nanodegree Program from Udacity, which I was able to take through the AWS AI & ML Scholarship. I finished the project in roughly 2 days. I was working around a lot of other things happening in my life, so I was trying to make the most of the time I had and keep moving. I passed the project on my first attempt, which I was really happy about, but I also knew I had not spent the time I normally would on refining it. If I had more time, I would have gone back, looked at the evaluation results more carefully, improved the prompt, added more test cases, and run another evaluation. I did not do that this time. The final correctness score was 0.83. At first, I felt like I should probably wait until I had a higher score before writing about the project. Then I thought about what I had actually learned from it. The 2 things that did not work perfectly were some of the most useful parts of the project for me. That is what I wanted to share. There are already a lot of really good articles about building agents, AWS services, and AgentCore. I have learned from many of them myself. This is not meant to be another article that tries to explain everything about agent development. Instead, I wanted to share what the project looked like from my side as someone who is still learning. Because when you are a beginner, sometimes the hardest part is not the code. It is understanding what all the pieces are actually doing and why they need to be there. What I Built and How the Pieces Fit Together The project was a fictional customer support system for an online shop. A customer could send a message, and the agent had to understand what the customer needed and decide what to do next. There were three possible behaviors. The first was BUG_REPORT. If a customer said something like, “The checkout page crashes every time I click Pay,” the agent needed to recognize that as a technical problem. But recognizing it as a bug was not enough to create a ticket. Before doing that, the agent needed to collect three specific pieces of information: description, steps to reproduce, and environment. The second was PLATFORM_QUESTION. These were questions about things such as orders, shipping, returns, refunds, payments, products, accounts, and privacy. For these questions, the agent had an FAQ that it was expected to use instead of making up an answer from what it generally knew. The third was OTHER_REQUEST. If the request was not a technical bug and could not be answered using the FAQ, the agent needed to direct the customer to human support. Once I stopped looking at each AWS service separately and looked at how they worked together, the architecture became much easier for me to understand. The flow was essentially: This is the architecture I built for the project. The routing was handled through the system prompt rather than through a separate classifier or condition node. So what does each AWS service actually do here? If you are new to AWS, the service names can make a project like this look much more complicated than it really is. What helped me was thinking about what each piece was responsible for instead of trying to understand every AWS service at once. Amazon Bedrock AgentCore Managed Harness was the environment around the agent. In simple terms, it gave me the structure needed to run the agent with its model, instructions, and tools without having to build all of that setup myself. The model was responsible for understanding the customer's message and deciding what to do next based on the instructions it was given. It was the part doing the actual language understanding and decision-making. The system prompt defined how the agent was supposed to behave. This was especially important in my project because the routing logic was written into the prompt. The prompt told the model how to recognize the 3 types of requests and what rules to follow for each one. AgentCore Gateway connected the agent to the backend tool. The model was not directly changing the database. Instead, once the required information had been collected, the agent could call the tool through the Gateway. AWS Lambda handled the actual backend operation. When the agent called the tool with the required information, Lambda processed the request and created the bug report. Amazon DynamoDB stored that bug report. This was also a useful thing for me to understand because it showed that the agent's response was not just text. If the agent returned a ticket ID, there was an actual record stored in DynamoDB behind that response. And the FAQ was the controlled source of information for platform questions. The agent was expected to use the information provided there instead of relying on general knowledge when answering those questions. Once I looked at it this way, the architecture stopped feeling like a collection of unfamiliar AWS names. The model understood the customer's message, the prompt told it what rules to follow, the Gateway connected it to an action, Lambda performed that action, and DynamoDB stored the result. For platform questions, the FAQ provided the information the agent was allowed to use, while requests outside those boundaries went to human support. That simple way of looking at the system helped me more than memorizing what each AWS service does on its own. One thing that confused me at first was the word “classifier.” When I first saw that requirement, I imagined there would be a separate component whose only job was to classify the customer's message and then send it to the right part of the system. That was not what I built. In my implementation, the routing logic was part of the system prompt. The model was instructed to choose one of the 3 routes and then follow the rules for that route. Understanding this changed how I looked at the prompt. I initially thought of the prompt mostly as instructions for how the agent should respond. In this project, it was doing much more than that. It was also defining what information the agent needed, when it was allowed to take an action, what information it could use to answer a question, and when it needed to stop and involve human support. The Prompt Was Doing More Than I Expected Before this project, I mostly thought about a system prompt as a way of telling the model how to behave. Something like: “You are a helpful customer support assistant.” That is useful, but it is not enough when the model is also making decisions and using tools. In this project, the prompt was not just telling the agent how to respond. It was also telling it what it was allowed to do and what information it needed before doing it. The Prompt Was Setting the Rules For a BUG_REPORT, the prompt explained what counted as a bug and what information was required before a ticket could be created. The 3 required fields were description, steps to reproduce, and environment. If something was missing, the agent had to ask for that information one field at a time. It was not supposed to call the tool until all 3 were available. The prompt also defined the other 2 routes. A PLATFORM_QUESTION had to be answered using the provided FAQ, while an OTHER_REQUEST had to be directed to human support. The FAQ part was interesting to me because it showed why an agent sometimes needs to be told what information it can and cannot use. Suppose a customer asks: “How long do I have to return an item?” The FAQ says that most items can be returned within 30 days of delivery, as long as they are unused and in their original packaging, unless the item arrived defective. So the agent can answer that using the information it was gi