One of the most common questions I get asked is: "How should I connect my knowledge base to my bot?" The answer used to be simple. Now there are three legitimate options, and picking the wrong one leads to either over-engineering or under-delivering.
The three options are:
- Option 1: Lex codehook Lambda calling Bedrock Knowledge Base APIs directly
- Option 2: The built-in
AMAZON.QnAIntentin Lex - Option 3: Amazon Connect AI Agents
Each operates at a different level of abstraction, gives you a different degree of control, and fits different use cases. Let me break them down.
Option 1: Lex Codehook → Bedrock Knowledge Base APIs
How It Works
A customer asks a question. Lex classifies it into an intent (or a catch-all). The intent triggers a codehook Lambda function. Inside that Lambda, you call the Bedrock Knowledge Base RetrieveAndGenerate or Retrieve API, pass the customer's utterance as the query, get back a generated answer grounded in your knowledge base documents, and return it to Lex as the response.
You own every step of the pipeline. You control which knowledge base to query, how to format the prompt, what guardrails to apply, how to handle low-confidence responses, and what to do when no relevant documents are found.
Strengths
- Maximum control — you decide the model, the prompt template, the retrieval strategy, and the response format
- Custom logic — you can enrich the query with customer context (account type, history, segment) before sending it to the KB
- Multi-KB routing — your Lambda can decide which knowledge base to query based on intent, slot values, or customer profile
- Response shaping — you can post-process the generated answer (truncate for voice, add SSML, strip citations)
- Fallback control — you define exactly what happens when the KB returns nothing useful
Weaknesses
- More code to maintain — you're building and owning the integration layer
- Latency responsibility — you need to manage cold starts, timeouts, and retry logic
- No out-of-the-box conversation management — follow-up questions and context don't carry over unless you build it
Use when: You need fine-grained control over the RAG pipeline. You have custom business logic that determines which KB to query or how to format answers. You need to enrich queries with customer context. You're building a production system where you need full observability over every step.
Avoid when: You just need a simple FAQ bot and don't want to maintain Lambda code. Your team doesn't have the development capacity to own a custom integration layer.
Option 2: AMAZON.QnAIntent (Built-in Lex Intent)
How It Works
You add the AMAZON.QnAIntent to your Lex bot and point it at a knowledge source — a Bedrock Knowledge Base, Amazon Connect FAQ documents, or custom data. When a customer utterance doesn't match any of your defined intents, QnAIntent activates automatically. It queries the configured knowledge source using generative AI and returns a conversational answer directly to the customer.
No Lambda required. No code to write. Lex handles the retrieval, generation, and response delivery natively.
Strengths
- Zero code — configure entirely in the Lex console, no Lambda needed
- Fast to deploy — you can have a KB-powered FAQ bot running in minutes
- Automatic activation — catches questions that don't match your defined intents (acts as a smart fallback)
- Managed conversation — Lex handles follow-up questions and context within the QnA flow
- Multiple knowledge sources — supports Bedrock KBs, Connect content, and custom document stores
Weaknesses
- Limited customisation — you can't control the prompt template, model parameters, or response format at the same granularity as Option 1
- Activation logic is fixed — it fires when no other intent matches; you can't conditionally enable/disable it based on context
- Less observability — harder to debug why a particular answer was generated
- Not active during slot elicitation — if the bot is mid-flow collecting a slot value, QnAIntent won't fire for off-topic questions
Use when: You want to handle general FAQ-type questions without building custom intents for each one. You need a quick deployment with minimal development effort. Your knowledge base content is relatively stable and doesn't require dynamic query enrichment. You want a smart fallback that catches questions your defined intents don't cover.
Avoid when: You need dynamic query enrichment (e.g. injecting customer-specific context). You need to control which KB is queried based on conversation state. You need granular control over the prompt or model parameters. You need the KB to respond while mid-slot-elicitation.
Option 3: Amazon Connect AI Agents
How It Works
Amazon Connect AI Agents are a layer above Lex. You configure an AI agent within Connect, attach one or more knowledge bases (including Bedrock Knowledge Bases), and the agent reasons autonomously over customer queries. It can access tools, invoke actions, and drive multi-step resolutions — not just answer questions.
AI agents operate within the Connect assistant framework. They handle both self-service (customer-facing) and agent-assist (supporting human agents in real time) scenarios. They maintain full conversation context, can access customer profiles, and can take actions beyond just returning text.
This is the highest level of abstraction. You're not configuring intents or writing Lambda functions — you're defining an agent's purpose, attaching knowledge sources and tools, and letting it reason.
Strengths
- Agentic reasoning — the AI decides how to use the KB, when to ask clarifying questions, and when to take action
- Multi-KB support — attach multiple knowledge bases and the agent determines which to query based on the question
- Action authority — beyond answering questions, agents can invoke tools (update records, create cases, trigger workflows)
- Dual-use — same agent can serve customers directly (self-service) and assist human agents (real-time suggestions)
- Managed by Connect — guardrails, conversation history, and escalation paths are handled by the platform
- No Lex bot required — for pure KB Q&A use cases, you can bypass Lex entirely
Weaknesses
- Less deterministic — agentic reasoning means you have less control over exactly how a query is handled
- Newer service — still maturing; less community knowledge and fewer battle-tested patterns
- Tighter coupling to Connect — designed for the Connect ecosystem; less portable than a Lex + Lambda architecture
- Guardrail management — you need to carefully define what the agent can and cannot do to avoid unintended actions
Use when: You want an end-to-end AI-powered experience that goes beyond answering questions — the agent should reason, decide, and act. You're building within the Connect ecosystem and want the tightest integration with customer profiles, cases, and agent workspace. You have multiple knowledge bases and want the AI to figure out which to use. You want both self-service and agent-assist from the same configuration.
Avoid when: You need highly deterministic, predictable responses (e.g. compliance-critical scripts). You need fine-grained control over every step of the retrieval and generation pipeline. You're not on Amazon Connect and need a portable solution. Your use case is purely FAQ with no action-taking required.
Comparison at a Glance
| Codehook + Bedrock KB | QnAIntent | Connect AI Agents | |
|---|---|---|---|
| Code required | Yes (Lambda) | No | No |
| Setup complexity | High | Low | Medium |
| Control over RAG pipeline | Full | Limited | Moderate |
| Dynamic query enrichment | Yes | No | Yes (via customer profile) |
| Multi-KB routing | Custom (you build it) | Limited | Native (agent decides) |
| Can take actions | Yes (in your Lambda) | No | Yes (native tools) |
| Conversation context | Manual (you manage it) | Managed by Lex | Managed by Connect |
| Best for | Custom, high-control use cases | Quick FAQ / smart fallback | End-to-end agentic resolution |
| Portability | High (standard APIs) | Medium (Lex-specific) | Low (Connect-specific) |
How to Decide
Ask yourself these questions:
"Do I just need to answer customer questions from a knowledge base with minimal effort?"
→ Use QnAIntent. It's the fastest path to value with zero code.
"Do I need to control the prompt, enrich the query with customer data, or route to different KBs based on logic?"
→ Use Codehook + Bedrock KB APIs. You need that control layer.
"Do I want the AI to not just answer questions but actually resolve issues — access data, take actions, and reason across multiple steps?"
→ Use Connect AI Agents. That's what they're designed for.
Can You Combine Them?
Yes — and in many cases you should. A common architecture:
- Lex handles intent classification for well-defined, deterministic flows (make a payment, check a balance, book an appointment)
- QnAIntent acts as the fallback — catching general questions that don't match a structured intent
- Connect AI Agents handle complex, multi-step resolutions where the bot needs to reason, look up data, and take action
- Codehook + Bedrock KB is used within specific intents where you need precise control over how knowledge is retrieved and presented
They're not mutually exclusive. The right answer for most production deployments is a combination — structured intents where you need determinism, QnAIntent for FAQ coverage, and AI Agents for the complex tail.
The key principle: Use the simplest option that meets the requirement. Don't build a custom Lambda pipeline for something QnAIntent handles out of the box. Don't use QnAIntent for something that needs action-taking authority. Match the tool to the problem.