Building an AI assistant on AWS was one of the most engaging exercises I’ve done so far, right alongside building scalable infrastructure. I had worked through similar material before, but this time, for much of the systems setup and configuration I kept stopping to understand what was happening underneath.
The lab centered on an HR assistant designed to reduce repetitive HR work, retrieving company policy information and handling employee requests, including leave and benefits submissions. That meant connecting an agent to both a knowledge base and tools that could invoke Lambda functions and persist requests in DynamoDB.
The full lab write-up lives here: aws-restart/agentic-ai
AI already pulls at my curiosity. Having more AWS knowledge to bring into this exercise gave my curiosity somewhere to go.
Revisiting “increased significantly”
In an earlier post about the AWS Generative AI Practitioner work, I wrote that my understanding of “RAG and MCP, along with how the surrounding components let an AI system retrieve information and actually take action, had increased significantly.”
Coming back to this material, I kept thinking: I can’t believe I used the words “increased significantly.” I knew that of course there was so so much more to learn, but there was so much underneath those concepts that I hadn’t even yet known how to question.
My broader understanding of AWS and IT had grown in the meantime. The relationships between services and their different levels of management were becoming clearer, so familiar configuration steps started raising new questions. I could look at a setting and begin recognizing some of the work it represented—and that there is so, so much I am incapable of recognizing.
Seeing the engineering behind the console
That led to a recurring thought while working in the console:
“There’s no way it’s actually this simple.”
Pointing one service at another can take very little effort. But what enables that connection? How much of that would I have to implement myself without the managed service?
I could start seeing how configuration fields represented substantial engineering: hosting, retrieval, tool integration, and access control. A few fields in the console can configure access to capabilities that would otherwise require substantial implementation and operational work — with AWS having already abstracted much of the machinery.
I now better understand the relationship between the simplicity of the interface and how much work sits underneath it. I pondered how understanding what had been provided would make the configuration itself more meaningful: why it existed, what it enabled, and which decisions remained mine.
Each answer gave me enough context to ask something I couldn’t have asked a few minutes earlier. I found myself spending as much attention on the questions emerging from a configuration as on completing the configuration itself.
Following the system beneath the settings
RAG: from question to answer
RAG became a particularly satisfying example. I worked through retrieval-augmented generation until I could follow a basic semantic retrieval path in my head:
Query text (question) → embedding model → query vector → vector store / search → relevant text chunks → question + retrieved context → language model → answer.
The embedding model converts the question's meaning into a numerical representation, called a vector, that can then be mathematically compared to vectors of document chunks. The search retrieves relevant text, and that text becomes context for the language model’s response. The embedding model and the language model have different jobs in that process.
That immediately opened another set of questions. How did the documents become searchable in the first place? Why split them into chunks? Where are the embeddings stored? What happens when the source documents change?
Following those questions took me into chunking, vector storage, and synchronization. When I wondered how synchronization worked—how the knowledge base could stay current as source documents changed—I could already picture an event-driven process for detecting those changes and updating its indexed content: detect a source-document change, trigger ingestion, and update the vector index. My earlier AWS learning was giving me enough context to reason through a system I hadn’t built myself.
I could now connect what happened when documents entered the knowledge base with what happened when someone asked the assistant a question. Amazon Bedrock Knowledge Bases was managing much of that workflow, which helped explain why the console steps could be so short.
MCP: connecting the agent to actions
MCP gives the agent a common interface to discover and call tools. AgentCore Gateway provided that interface to the backend: the agent could call a Lambda function to save an employee request in DynamoDB. Testing showed me the agent retrieving policy information, invoking action tools, and declining requests outside its HR scope. Seeing a submitted request appear in DynamoDB let me verify the action beyond the assistant’s reply.
With AWS managing retrieval, tool access, and agent hosting, I could focus on how the system fit together and the choices I still owned: its information, tools, permissions, instructions, and tests.
Understanding earlier work differently
That understanding has also started reaching backward into earlier work. I can think about serverless labs I don’t remember particularly well and still understand their architecture better now. Events, function execution, permissions, and data moving between services make more sense because I have more context for their relationships. Even when the individual steps have faded, newer knowledge helps me reconstruct what was happening.
This is part of why returning to the AI exercise felt so rewarding. The AWS knowledge I had gained elsewhere enabled deeper questions here, and working through those questions gave me another way to interpret systems I had already built.
Answers make new questions possible
There’s a progression here that I can now recognize in my own learning. An answer changes what I’m able to notice. What I notice raises another question, sometimes one I couldn’t have formulated before because I was missing the knowledge needed to even see it.
That’s what gives the earlier “increased significantly” wording its meaning to me now. My understanding had increased, and continuing to build on it eventually let me see how much more there was underneath RAG, MCP, and the surrounding system. I expect that to keep happening as I learn more.
I’m eager to return to this kind of build again with even more knowledge and see what discoveries are revealed, enabled by the questions I’ll be capable of asking.
I understand how little I know and how much more there is to know. I plan to close the gap day by day.
