Most AWS generative AI projects are not new architectures. They are one of four familiar shapes wearing different service names. Twenty eight parts in, you have met every component. This part is where they snap together.

I will lay out the four reference patterns I actually reach for, chatbot, RAG, agentic, and batch, with the AWS services on each, the design decision that defines it, and where it falls over. The goal is that you can name the shape of your next feature before you open the console, because the shape decides almost everything else.

Four shapes cover most builds

Start by sorting your feature into one of four buckets, because the bucket dictates the services, the cost model, and the risk. A chatbot is a synchronous request and response, one prompt in, one answer out, no external data beyond what is in the prompt. RAG, retrieval augmented generation, is the same synchronous shape with a retrieval step bolted on the front so the model answers from your documents instead of its training data. An agentic system lets the model decide which tools to call and loops until a goal is met, which means it can take actions and change state. Batch is asynchronous, you hand Bedrock a file of thousands of prompts and collect the results later at half the price.

These are not rigid. Real systems combine them, an agent that runs a RAG query as one of its tools, a chatbot that falls back to a batch job for heavy reports. But the base shape still decides the spine of the design. Get the shape wrong and you fight the platform the whole way, standing up an agent framework for what is really a single grounded answer, or calling a real time endpoint a million times for work that could have gone to batch overnight.

The updated AWS Well-Architected Generative AI Lens now ships eight named architecture scenarios and a separate Agentic AI Lens that landed in 2026, which tells you AWS sees the same clustering. My four are the load bearing ones under those scenarios. Here is the map.

A chatbot that answers in real time

The plainest pattern, and the one to reach for first when you are tempted by something fancier. A user sends a message, a client calls the Amazon Bedrock Converse API against a model, the model streams back an answer. Front the model with API Gateway and a Lambda function, put Bedrock Guardrails in the path to filter input and output, and keep conversation history in DynamoDB keyed by session. That is the whole thing. No vector store, no agent loop, no training.

The defining decision is the model, because a chatbot pays per token on every turn and latency is felt directly. For most assistant traffic Amazon Nova Lite at 0.06 dollars per million input tokens and 0.24 per million output is the sane default, moving to Nova Pro or a Claude model only where answer quality on hard turns justifies the jump. Turn on prompt caching for the system prompt so you are not paying to re-read the same instructions every message. This pattern also benefits most from streaming, since a user watching tokens appear tolerates a two second full response far better than a two second blank screen.

When is a bare chatbot wrong? The moment a correct answer depends on facts the model was never trained on, your policies, your inventory, last week ticket. At that point you are forcing users to paste context that should be retrieved, and you have outgrown the pattern. That is the jump to RAG.

RAG for answers grounded in your data

RAG is the chatbot with a memory of your documents. The user question first hits a retrieval step that pulls the most relevant chunks from a vector store, those chunks are stuffed into the prompt, and the model answers from them. On AWS the managed path is Amazon Bedrock Knowledge Bases, which handles the ingestion, chunking, and embedding for you and exposes a single RetrieveAndGenerate call. Point it at documents in S3, choose an embeddings model such as Amazon Titan Text Embeddings, and pick a vector store.

The vector store is the decision that matters, and there are now real choices. Knowledge Bases supports OpenSearch Serverless, Aurora PostgreSQL, Neptune Analytics, and the newer S3 Vectors, plus third party stores like Pinecone and MongoDB Atlas. OpenSearch Serverless is the default quick create and the safe pick for low latency retrieval at scale. S3 Vectors is the one to know about for cost, it trades some query speed for a much cheaper store, which fits a large corpus queried occasionally rather than a hot support bot. Aurora PostgreSQL earns its place when you already run Postgres and want vectors next to relational data. The full RAG ingestion and grounding story is in Part 12, this is where it fits in the catalog of shapes.

The trap in RAG is treating retrieval as solved once the pipeline runs. It answers, so it looks done, but retrieval quality is the whole game and the model cannot fix a bad chunk it was handed. Wire the grounding checks from Guardrails and the evaluation job from Part 23 around it, or you ship a system that sounds confident and cites the wrong paragraph.

What changes when the agent acts for you

An agent is a model given tools and a loop. Instead of answering in one shot, it reasons about a goal, decides which tool to call, reads the result, and repeats until it is done or gives up. That loop is what makes agents useful and what makes them dangerous, because a tool call can send an email, update a record, or spend money. The synchronous chatbot touches nothing. An agent touches your systems.

On AWS the production path is Amazon Bedrock AgentCore, which reached general availability in late 2025 and is a set of components you compose rather than one box. Runtime executes the agent, Gateway sits between the agent and its tools and enforces policy on every call, Identity lets the agent act on behalf of a user with scoped credentials, and Memory carries context across sessions. There are more components, Code Interpreter, Browser, Observability, Evaluations, but those four are the spine. The older Bedrock Agents feature still works and is simpler for a single agent with a few action groups, covered in Part 13. Reach for AgentCore when the agent needs governed tool access, real identity, or more than one agent working together.

The defining decision here is not the framework, it is the blast radius of the tools. Give an agent read only tools and the worst case is a wrong answer. Give it a tool that writes to production and the worst case is real damage at machine speed. Route every tool call through the Gateway so policy is enforced in one place, scope the Identity credentials to exactly what the task needs, and keep a human approval on anything irreversible. An agent with an unscoped write tool is the fastest way to turn a hallucination into an incident.

Batch for volume when latency does not matter

Batch is the pattern teams forget, and it is the one that saves the most money. If you need to run a model over thousands or millions of records and nobody is waiting on any single answer, you do not want real time calls. You want Amazon Bedrock batch inference. You write a JSONL file where each line is one prompt, drop it in S3, start a model invocation job, and Bedrock processes the whole file asynchronously and writes results back to S3, usually within 24 hours. The price is 50 percent of on-demand for the same model.

The fit is obvious once you look for it: overnight summarization, bulk classification, generating embeddings for a corpus, running a model as a judge over an evaluation set, enriching a data warehouse. None of these need an answer this second, and paying real time rates for them is pure waste. The defining decision is honesty about latency tolerance. If the answer can wait an hour, it can almost certainly wait for batch, and you have just halved that line on the bill.

The catch is throughput management. Batch is capped at 10 jobs per model per Region running at once, so a pipeline that submits hundreds of jobs needs a queue, typically Lambda plus DynamoDB, that holds jobs and submits a new one as a slot frees. Plan for that at design time, not when the eleventh job fails.

import boto3

bedrock = boto3.client("bedrock", region_name="us-east-1")

job = bedrock.create_model_invocation_job(
    jobName="nightly-ticket-summaries",
    roleArn="arn:aws:iam::111122223333:role/BedrockBatchRole",
    modelId="amazon.nova-lite-v1:0",
    inputDataConfig={
        "s3InputDataConfig": {"s3Uri": "s3://my-batch-in/tickets.jsonl"}
    },
    outputDataConfig={
        "s3OutputDataConfig": {"s3Uri": "s3://my-batch-out/"}
    },
)

print(job["jobArn"])   # arn:aws:bedrock:us-east-1:...:model-invocation-job/xxxx

Expected output: a jobArn string you poll with get_model_invocation_job until status is Completed, then read results from the output prefix. Failure mode one: more than 10 in-flight jobs for this model in this Region raises a ServiceQuotaExceededException, which is the queue signal, not an error to retry blindly. Failure mode two: a malformed JSONL line does not fail the job, it is rejected and skipped, so reconcile output record count against input before you trust the batch.

How the four patterns compare

Lined up side by side, the patterns separate cleanly on the two axes that decide most designs, how fast you need the answer and how much a mistake can cost. A chatbot is fast and safe. RAG is nearly as fast and safe, with the added job of keeping retrieval honest. Agentic is slow and risky, because the loop takes time and the tools can act. Batch is the slowest by design and the cheapest, with the narrow risk of processing a bad file at scale.

The four patterns on their defining traits. Latency figures are typical, not guaranteed, and depend on model, payload, and Region.

Where these architectures break

The failures cluster by pattern, and they are predictable. Chatbots break on cost creep and context loss. Cost creep is a slow bleed from an oversized model on cheap traffic, fix it by defaulting to Nova Lite and promoting only the turns that need it. Context loss is a session table that forgets, or grows so large the prompt balloons, so cap the history you replay.

RAG breaks on retrieval, always. The pipeline runs, the answers look plausible, and the wrong chunk is quietly feeding wrong facts. There is no fixing this from the model side, only from evaluation and grounding checks on the retrieval itself. Agentic breaks on scope. An agent handed a broad write tool and a vague goal will eventually take an action you did not intend, and the Gateway policy and scoped Identity are the only things standing between a bad plan and a real change. Batch breaks on the file. A malformed JSONL, a wrong model ID, or the 10 job cap turns a clean run into a partial one, and the fix is validation before submit and reconciliation after.

Notice the pattern in the failures. Each one is the cost of the thing that pattern added. RAG added retrieval, so retrieval is where it breaks. Agentic added action, so action is the risk. Design the controls around what your pattern added, not around a generic checklist.

Which pattern to reach for first

Here is the order I actually work in. Ask first whether anyone is waiting on the answer. If not, it is batch, and you have just found the cheapest path. If someone is waiting, ask whether a correct answer needs your private data. If not, it is a chatbot, the simplest thing that works. If it does, it is RAG, and your real job becomes retrieval quality. Only if the feature has to take actions in your systems, not just produce text, do you climb to agentic, and then you spend your design budget on the Gateway and Identity, not the model.

When is this framing wrong? When a single feature genuinely spans shapes, a support assistant that chats, retrieves, and can file a ticket. Then you compose, but you still build it one shape at a time and add the risky pieces last. Before you call any design done, validate three things: that you picked the leftmost pattern that meets the need, that the control matching what that pattern added is actually wired, retrieval eval for RAG, Gateway policy for agentic, and that you are not paying real time rates for work that could wait. The vendor neutral version of this decision tree lives in the GenAI Series, and the Azure equivalents of these four shapes sit in the Azure Gen AI Series. The final part steps back from the parts and gives the verdict on where AWS generative AI actually stands against the field.

This week, take the last feature you shipped or scoped and name its shape out loud. If it is an agent that could have been a RAG query, you have found next week work, and probably a cheaper, safer version of the same thing.

References

• Generative AI Lens, AWS Well-Architected Framework
• Agentic AI Lens, AWS Well-Architected Framework
• Amazon Bedrock AgentCore
• Process multiple prompts with batch inference, Amazon Bedrock
• Amazon Bedrock pricing

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts