PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For Hemapriya Kanagala, building a first AI agent with AWS AgentCore was less about getting a model to respond and more about making the surrounding system work: tools, permissions, backend actions, memory, deployment, and monitoring. Her fictional customer-support agent eventually passed six capability-level tests, but the work showed why an agent’s answer is only as reliable as the systems it can reach and the results they return.
What the project was meant to do
Kanagala built the project as part of Udacity’s Future AWS Agent Engineer Nanodegree Program, supported through the AWS AI & ML Scholarship. The fictional customer-support agent was designed to handle requests such as “Where is my order?” and “What is the return policy?” It was also meant to process refunds, remember customer information across sessions, calculate loyalty discounts, and browse live websites.
She describes Amazon Nova 2 Lite through Amazon Bedrock as handling request understanding and tool selection, with Strands providing the agent framework. The rest of the build connected that model-driven behavior to services that supplied information or performed work. These are the responsibilities in her project, not a comparison of competing products.
How the AgentCore system fit together
The useful way to understand this architecture is to follow the work a request needs to accomplish. AWS describes AgentCore as a modular platform that can work with different frameworks and foundation models; the components in Kanagala’s build served distinct roles.
#1 Best Overall
| Capability | Role in the project |
|---|---|
| AgentCore Runtime | Hosted the deployed agent. |
| AgentCore Gateway | Connected the agent to backend tools and resources. AWS documents Gateway targets for Lambda functions and REST API services, with schemas defining tools and authorization configuration controlling access. AWS Gateway documentation. |
| API Gateway and Lambda | Exposed order operations and performed backend work, respectively. |
| Bedrock Knowledge Base | Supplied product and policy information for questions such as “What is the return policy?” |
| AgentCore Memory | Supplied retrieved customer context across sessions. |
| Code Interpreter | Handled the loyalty-discount calculation. |
| Browser Tool | Interacted with live webpages. |
| CloudWatch | Supported runtime monitoring. |
These functions are complementary, not interchangeable: a Knowledge Base retrieves application information, Memory provides prior customer context, Gateway and connected services invoke backend operations, Code Interpreter handles calculations, and Browser accesses live pages. For a broader view of the platform’s modular services, see AWS’s AgentCore overview.
Why the surrounding system was the hard part
Kanagala says the number of service names made it difficult at first to see how the pieces fit together. Rather than treating “the agent” as a single model, she found it more manageable to ask what each component did, what it connected to, and what should happen if it failed. Her guiding question became: “What is the next thing I need to understand?”
Rank #2
- Deck-building game: Build your own deck of AWS services during the game. Gradually expand your deck and build better architectures than your fellow players!
- Ideal for both AWS professionals and those wanting to explore cloud services through gameplay!
- Perfect for team building: Play during breaks or events to share knowledge and foster collaboration!
- 2-4 players, 20-30 minutes playing time
- Contents: 144 cards
That shift matters because a capability can be correctly configured in one place and still fail at the boundary between services. In her example, the Browser Tool was configured, but the runtime could not start a browser session until it had a required permission. After she added it, she reports that the test worked. The episode illustrates that IAM and resource access are part of implementing a feature, not housekeeping to defer until later.
Make backend results—not model claims—the source of truth
A refund request is not complete merely because the agent says it is. The important sequence is: the agent recognizes the intent, invokes the refund tool, the backend processes the request, the result returns to the agent, and only then does the agent tell the customer what happened. Kanagala’s concise lesson is that “a model saying that something happened and a system actually performing that action are two different things.”
This distinction applies to other actions too. An agent should report the result it receives from an operation, rather than turning a requested action into an unsupported claim of success. In an application that changes orders or money, the backend outcome is the evidence the customer-facing response should reflect.
Calculations still need ordinary software checks
Kanagala reports that her first loyalty calculation was wrong because she treated points and dollar values incorrectly. She corrected the calculation, but the mistake showed that adding an AI interface does not remove familiar software risks: incorrect formulas, hidden assumptions, edge cases, configuration errors, and bugs. A model can select a calculation tool; the calculation itself still needs correct inputs and logic.
Rank #4
Deploying an agent is not the same as validating it
Kanagala says she tested six capabilities separately and that all six eventually worked. Her account is a report of those project tests, not independent verification or evidence that the application was production-ready.
- Track an order.
- Process a refund.
- Answer a question using the Knowledge Base.
- Retrieve customer information across sessions.
- Calculate a loyalty discount.
- Browse a live website.
Separate checks make it easier to identify whether a failure lies in request handling, a tool connection, permissions, backend behavior, or the result returned to the agent. AWS’s current AgentCore developer guide documents ways to create and manage agents, including the CLI, Python SDK, MCP server, AWS SDK, console, and AWS CLI. AWS notes that the CLI and Python SDK do not cover every operation available through the AWS SDK; using other AWS services such as Lambda alongside the AgentCore SDK can require AWS SDK integration. The console also offers an agent sandbox for testing. Interface details can change, so use the live documentation for current procedures.
Best Value
Monitoring continues after deployment
Kanagala says she used CloudWatch to monitor the AgentCore runtime and create a CPU usage alarm. For a production version, she identifies further areas to monitor: failed requests, errors, latency, tool failures, resource usage, service health, and costs. These are operational considerations she recommends, not measured results from her project.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
