Skip to lesson

AWSAWS Certified Generative AI Developer - Professional2026-101.1 Analyze requirements and design GenAI solutions

Choose the pattern your evidence requires

Completed by the knowledge check

Learning objective

Choose direct inference, RAG, agents, or customization based on evidence, complexity, and trust requirements. Select the mechanism that resolves a demonstrated requirement rather than assembling every available feature.

Core idea

Choose a GenAI pattern by asking what is missing from a model call. If the request already contains all necessary evidence, direct inference might be enough. If evidence lives elsewhere, add retrieval. If task completion requires choosing and invoking external actions, consider an agent. If measured failures reflect a persistent task behavior that prompting cannot adequately teach, consider training-based customization.

These mechanisms can coexist, but each introduces a different dependency. Retrieval adds an evidence pipeline. Agents add decisions and execution authority. Customization adds a training and release lifecycle. More mechanisms do not automatically create more trust. Trust comes from verified evidence, bounded authority, and tests matched to the task.

How it works

Start with direct inference

Direct inference passes instructions and available input to a foundation model and consumes its response. A supplied document summary, a draft based on explicit facts, or classification of text might not require an external data source. The important condition is that the supplied input is sufficient for the task.

Keep a direct-call baseline even if you expect to add other mechanisms. It helps identify what an additional component actually improves. If summarization is poor because the prompt is ambiguous, a vector store does not resolve that defect. If the source document is too large or incomplete, changing wording alone might not resolve the evidence problem.

Direct inference still requires validation and fallback behavior. A plausible response can misrepresent supplied facts. Being a short architecture does not make it a low-risk workflow, especially when generated text drives a consequential decision.

Add request-time evidence with RAG

Retrieval-augmented generation (RAG) selects external information and places it in the generation context. Amazon Bedrock Knowledge Bases provides retrieval over connected data to support generated responses. This supplies private or changing information without requiring the answer to come from facts stored in model parameters.

Use RAG when the application must answer from an approved corpus, attribute claims, or respond to changes in that corpus. The decision is about evidence availability and governance, not only semantic similarity. You need an authoritative source, an ingestion and refresh policy, an authorization boundary, and a way to handle contradictory or absent evidence.

RAG does not establish truth by itself. The model can still misuse a retrieved passage, and a correct quotation can describe an obsolete policy. Evaluate retrieval and generation separately so a missing source does not get mistaken for a prompting problem. The detailed retrieval design belongs to 1.5.

Add bounded action selection with agents

An agent uses model-driven decisions to select steps or tools in pursuit of a goal. Consider one when the sequence genuinely depends on information discovered during execution. A fixed sequence of known steps can often remain a deterministic workflow with model calls inside it.

For example, an assistant that diagnoses an order problem might inspect shipment status, ask for missing details, and choose between a replacement request and a specialist handoff. Those choices require explicit tool contracts, validated arguments, authorization, completion tracking, and stop conditions. The model’s selection of a tool is not permission to run it.

AWS documentation calls the original Amazon Bedrock Agents service Amazon Bedrock Agents Classic and states that it is no longer open to new customers; existing customers can continue using it. AWS points new customers to Amazon Bedrock AgentCore for similar capabilities. AgentCore provides services for building, deploying, and operating agents with different frameworks and foundation models. The architecture pattern remains valid, but a new design must not assume access to Agents Classic.

Bound the agent by capability and consequence. Read-only search and irreversible account changes need different controls. A maximum-step policy helps contain loops, while confirmation of the external result prevents a fluent completion message from substituting for actual task completion. Agent implementation is developed in 2.1.

Customize after diagnosing behavior failures

AWS uses “customization” broadly: the Generative AI Lens includes prompting, RAG, agents, and training-based techniques. Here, training-based customization means Bedrock supervised fine-tuning, reinforcement fine-tuning, or distillation; the distinction keeps knowledge delivery separate from learned behavior.

Amazon Bedrock supervised fine-tuning uses labeled examples to adjust model parameters for the tasks those examples represent. Consider it when consistent style, specialized terminology, or a narrow repetitive task remains inadequate after a controlled prompting baseline.

Training-based customization is not a substitute for fetching the applicable record at request time. A tuned model cannot prove which policy version supports an answer merely because similar policies appeared in its training data. If the problem is missing current evidence, address the evidence path first.

Keep training and evaluation examples separate. Otherwise, improvements can reflect memorization instead of useful generalization. Include rare and adverse cases in the evaluation, and confirm that gains on the target behavior do not damage other required behavior. Specific customization methods and supported models belong to 1.2.

Key distinctions and trade-offs

The following comparison identifies the dependency each pattern introduces:

PatternRequirement it addressesAdditional burden
Direct inferenceTransform or reason over sufficient supplied inputPrompt design, output validation, and response handling
RAGUse external, private, current, or attributable evidenceSource governance, retrieval quality, freshness, and access filtering
AgentSelect and execute steps based on intermediate resultsTool security, step limits, recovery, and action verification
Training-based customizationImprove a repeatable learned behaviorTraining data, evaluation, versioning, and regression control

Pattern versus product: RAG and agents are architecture concepts. Choosing a product does not decide your evidence or authorization policy.

Dynamic planning versus fixed orchestration: Variation in the wording of an answer does not imply that the execution sequence needs model-driven planning. Prefer a fixed sequence when the required steps are known.

Information versus behavior: Retrieval supplies information for this request. Fine-tuning changes learned behavior across requests. Both can be useful, but their failure modes differ.

Architecture / decision scenario

An insurer needs an assistant to explain policy exclusions and prepare claim intake. Approved policy documents change, and explanations need source attribution. Start with RAG for explanations rather than training a snapshot of the policies into the model.

The intake form has a fixed validation sequence, so it remains a deterministic workflow. A later diagnostic feature needs to choose which supporting record to inspect; evaluate a bounded read-only agent for that feature. Human approval remains outside the model before any consequential claim action.

If the generated explanations repeatedly violate the required house style despite effective prompts, test customization on reviewed examples. That experiment leaves the retrieval requirement intact. Each mechanism resolves a measured problem, and each has a separate acceptance gate.

Common exam traps

  • Selecting an agent because the interface is conversational.
  • Using fine-tuning as the primary source of frequently changing policy facts.
  • Assuming citations prove source freshness or authorization.
  • Treating a tool call proposal as an authorized action.
  • Assuming Agents Classic is available to a new AWS customer.
  • Combining patterns without evidence that their added complexity helps.

What to remember

  • Start from the missing evidence, behavior, or execution capability.
  • Use retrieval for request-time knowledge and attribution.
  • Use agents when dynamic step selection is necessary and bounded.
  • Customize against demonstrated, repeatable behavior failures.
  • Recheck product eligibility separately from architecture fit.

Knowledge check

References