AWS Certified Generative AI Developer - Professional: Add RAG to the agent

Add rag to the agent. Day 19 is where

everything finally clicks together. This

is the moment AWS checks whether you

understand the difference between an

agent that acts blindly and an agent

that acts based on verified knowledge.

Because once agents can take actions,

being wrong is no longer just

embarrassing. It's dangerous.

Imagine this. A national railway deploys

an AI signal controller agent. Its job

is to respond to signal faults, check

maintenance rules, decide whether trains

should stop or continue, and notify

engineers. If this agent invents a rule,

acts on outdated procedures or guesses

safety steps, trains stop incorrectly,

or worse, trains collide. So, the

railway makes one rule absolutely clear.

This agent may only act based on

official manuals. That is why RAG is

added inside the agent. Here is the core

idea. You must lock in. An agent plans

actions. If its plan is based on general

knowledge, assumptions, or

hallucinations, it will take wrong

actions, not just give wrong answers.

This is the key exam rule. Agents

without rag hallucinate actions, not

just text. And AWS considers that

unacceptable.

Now, let's place rag in the agent loop.

This is exam gold. A user gives a goal.

The planner, the LLM starts reasoning.

Before it acts, it retrieves facts,

rules, and policies using rag. The

planner updates its plan using that

retrieved context. Only then does the

executive lambda tools act. The results

are observed. Memory is updated and the

loop continues. The critical point is

this. Rag happens before actions, not

just before the final answer. Let's see

what changes when rag is added. Without

rag, the planner might think signal

faults usually mean stopping trains.

That's a dangerous assumption. With RAG,

the planner retrieves the real rule.

Section 8.3. If fault code X12 occurs

during peak hours, trains must continue

at reduced speed. Now the plan changes,

the decision changes, the action

changes. RAG doesn't just change

wording, it changes behavior. Let's walk

through the railway example step by

step. A controller says, "There's a

signal fault near central station. What

should we do?" The planner does not act

immediately. It pauses and says, "I need

the official procedure." The agent

triggers rag. The query may be rewritten

for clarity. Titan embedded converted

into vectors. The vector store retrieves

signal fault rules, safety thresholds,

escalation procedures. Now the planner

updates the plan. Identify the fault

code. Check rule section 8.3. Decide

reduced speed versus full stop. Notify

maintenance. Only then does the

executive act. Lambda calls the

monitoring system. Lambda notifies

engineers. Finally, memory stores the

decision so the agent doesn't repeat

itself. This is a knowledged driven

agent. AWS expects you to know two rag

patterns for agents. The first is plan

then retrieve. The planner decides what

information it needs then rag fetches

it. This is best for complex safety

critical decisions and is what the exam

prefers. The second is retrieve then

plan. Rag runs first then the planner

reasons. This is faster but less

flexible and less safe. If the scenario

is safety critical, plan then retrieve

is the correct answer.

Now let's anchor this to AWS services.

The LLM planner runs in Amazon Bedrock.

Embeddings are created using Titan

embeddings v2. Retrieval comes from open

search serverless or a bedrock knowledge

base. Actions are executed by Lambda

tools. Memory lives in a vector store or

database. Tracing and debugging use

cloudatch and X-ray. If AWS asks, how

does an agent access enterprise

knowledge before acting? The answer is

rag inside the agent planning loop. One

more important distinction, guardrails

and rags solve different problems.

Guardrails block unsafe outputs. Rag

provides correct facts. If an agent

makes a wrong decision, guardrails won't

fix it. Rag will. This is a classic exam

trap. Memory and RAG together are

extremely powerful. The agent can

remember past retrievalss, previous

decisions, and outcomes. That means

fewer repeated searches, lower cost, and

faster decisions over time. Memory can

be short-term or long-term, but it

always works alongside RAG. Now, watch

for the traps. Do not add RAG only to

the final answer. Do not expect the LLM

to recall policies from training. Do not

use fine-tuning instead of RAG. Do not

let tools decide logic. The correct flow

is always rag informs the planner. The

planner decides. Tools execute. Here is

the one sentence to memorize. Rag gives

agents facts before they act. If you

remember that, day 19 is solved. Final

self test. An agent must decide

operational actions using internal

manuals. How should it be designed? Add

rag inside the agent planning loop

before tool execution. That's day 19

mastered.