Guided project + Final exam
Put it all together: design a RAG + agent assistant on AWS and earn your badge.
6 min read
You've reached the final lesson of the track. There's no new content to memorize here — there's a project to build, a recap to lock things in, and an exam to earn your badge. This is the moment to connect everything you've learned and realize you can already design a real AI system.
The Project: Document Assistant
The project is deliberately simple to state: design the architecture of an assistant that answers questions about internal company documents. No heavy code — the deliverable is the diagram and the decisions behind it.
The company has PDFs of policies, technical manuals, and contracts. Users ask questions in natural language. The system must answer accurately, cite the source, scale without a dedicated server, and have predictable costs.
Constraints that make the project real:
- Documents change every week → incremental ingestion.
- Different users have access to different document subsets → tenant isolation or metadata filtering.
- The company doesn't want invented answers → guardrails and mandatory citation.
- The assistant needs to know today's date and fetch a policy number from a legacy system → it needs tools.
Those four constraints force you to use almost everything from the track: RAG, agent, tool calling, guardrails, memory, and FinOps. This isn't an academic exercise — it's the kind of briefing you receive in a discovery meeting.
Step by step: architecture decisions
- 1
1. Choose the model
On Amazon Bedrock, start with Claude 3 Haiku for fast, cheap production responses; reserve Claude 3 Sonnet or Titan for tasks that need longer reasoning. Document the criterion: latency, cost per token, and context window (lesson 16).
- 2
2. Build the Knowledge Base
Use Bedrock Knowledge Bases with S3 as the source. Define chunking by section (not fixed size) to preserve semantic context. Add tenant and effective-date metadata to each chunk — this enables filters at search time (lessons 6 and 18).
- 3
3. Define the agent's tools
Two tools are enough:
get_current_date()(returns ISO date) andlookup_policy_number(policy_id)(calls legacy API via Lambda). Write precise OpenAPI schemas — the model uses the schema to decide when to call (lesson 7). - 4
4. Configure memory and session
Short-term memory: conversation window managed by AgentCore (last N turns). Long-term memory: not needed here — the user has no relevant persistent profile. Document the decision; don't add complexity without reason (lesson 12).
- 5
5. Add guardrails
Enable Bedrock Guardrails to block prompt injection, filter PII in output, and refuse out-of-scope questions (e.g., requests for malicious code). Define fallback behavior: default response + event log (lesson 10).
- 6
6. Estimate and control cost
Calculate: input tokens (prompt + retrieved chunks) × model price + output tokens × price. Set a budget alert in AWS Budgets. Consider embedding caching for static documents. Review whether cost per conversation is acceptable for the expected volume (lesson 19).
- 7
7. Sketch the diagram
Grab a sheet or open Excalidraw. Draw the flow: user → API Gateway → AgentCore → (Knowledge Base OR Lambda tools) → model → response. Add S3, CloudWatch, and Guardrails. If the diagram fits on one A4 sheet and any colleague understands it without explanation, it's good.
Reference Architecture: RAG + Agent Assistant
Full document assistant flow — from the user's question to the grounded answer, through the agent loop with RAG and external tools.
- API Gateway · REST / WebSocket
- AgentCore · loop ReAct + sessão
- Bedrock Guardrails · PII · injection · scope
- Modelo (Bedrock) · Claude 3 Haiku
- Knowledge Base · RAG gerenciado
- OpenSearch Serverless · índice vetorial
- S3 · PDFs + metadados
- Lambda · get_current_date()
- Lambda · lookup_policy_number()
- API Legada · Sistema de apólices
- CloudWatch · logs · métricas · alertas
In practice, what separates an architect from a developer who read about AI isn't code — it's the ability to look at a briefing and quickly map: which component solves which problem, where the risks are, and what it will cost. The diagram you sketch in this project already demonstrates that reasoning. It doesn't need to be pretty; it needs to be correct and defensible. If you can explain every arrow to a skeptical colleague, you passed the project.
The track in five modules: the connecting thread
You started by understanding what AI is and how a model learns (module 1) — without that foundation, everything else would be magic. Then you went deep into LLMs: tokens, context, embeddings, and prompting. You learned that the model is a mathematical function with an input/output contract, and that prompt quality determines response quality.
In module 3, you added memory and facts with RAG, and learned to give the model access to the external world with tool calling and structured output. You also learned to measure whether the system works (evals) and to protect it (guardrails).
Module 4 assembled the agent: the ReAct loop, short- and long-term memory, patterns like reflection and multi-agent, and MCP as an integration protocol. You stopped seeing the agent as a chatbot and started seeing it as an autonomous process with state.
Module 5 grounded everything in AWS: Bedrock for managed models, AgentCore for production agents, Knowledge Bases for managed RAG, FinOps for cost, and the critical decision of when not to use AI.
This lesson's project is the synthesis. Every decision you made in the previous steps has a foundational lesson behind it. That's not coincidence — it was the track's design.
What you can do now
Next steps: where to go from here
This track covers fundamentals. It doesn't end here — it opens doors.
Go deeper in practice: pick one of the components that interested you most — RAG, agents, or security — and build a real prototype. The foundational knowledge you have now will accelerate that work significantly. You'll understand mistakes before making them.
Continue on the site: I regularly publish in-depth articles on AI architecture, real case studies, and analyses of new AWS services. The articles start from this track's level — you'll understand everything without needing extra context.
The e-book: I'm preparing an e-book that consolidates the track with expanded diagrams, decision checklists, and additional references. Newsletter subscribers get it first.
Certifications: if your goals include AWS certifications, this track's fundamentals cover a significant portion of the AI/ML domain in AWS Certified Solutions Architect and AWS Certified Machine Learning — Specialty. You're not starting from zero.
The community: share your project diagram. Post it, discuss it, get feedback. Architecture is learned much faster when you defend your decisions to other people.
Now, one last thing before the exam.
Track recap
Tap a card to flip it.
Common questions before the exam
Does the exam have trick questions or is it straightforward?
It's straightforward. The questions test understanding of concepts and the ability to apply them — not memorization of definitions. If you understood the lessons, you'll do well.
Can I retake the exam if I don't pass?
Yes. Review the flashcards and the lessons for the topics you missed before trying again.
Does the badge expire?
The badge for this track doesn't expire. It represents fundamentals — which are stable. When the track is updated with new content, you can choose to retake the exam to earn the updated version.
Do I need to complete the project to take the exam?
It's not required, but I strongly recommend it. The process of making architecture decisions activates knowledge in a way that reading alone doesn't.
You are ready
Twenty-two lessons ago you started with 'what is AI'. Now you can design a RAG + agent system on AWS, defend every architecture decision, and estimate cost before writing a single line of code. That's what an AI architect does. Take the exam, earn the badge, and keep building — the field is evolving fast, but the fundamentals you learned here will last.