Web Search on Amazon Bedrock is the piece everyone’s talking about since the August 10, 2026 AWS Weekly Roundup, but the more interesting engineering problem shows up the moment you already have a Knowledge Base in production. Now your agent has two retrieval tools instead of one, and something has to decide which one to call, when, and how much of the open internet you’re comfortable letting it touch. This is the architecture piece — hybrid grounding — not the “how do I turn the feature on” piece, which we covered separately. If you haven’t read the setup walkthrough yet, start there; this one assumes you’ve already got a web-search-enabled agent running.
Why hybrid grounding beats either tool alone
A Knowledge Base is a RAG pipeline over documents you control — internal wikis, contracts, product specs, support tickets. It’s precise, it’s private, and it’s exactly as current as your last ingestion job. Web Search on Amazon Bedrock is the opposite shape: broad, public, and current as of right now, with none of the precision that comes from curating a private index. Neither tool alone answers “what’s our refund policy for a product that got recalled yesterday” — that question needs your internal policy document and today’s recall news in the same response. Hybrid grounding is just wiring an agent so both tools are on the table and something sane decides which one (or both) to invoke per turn.
Wiring both tools onto one agent
Bedrock Agents already support multiple action groups and multiple Knowledge Base associations on a single agent — Web Search on Amazon Bedrock just becomes another entry in that list. As with the syntax in our engineering deep-dive, treat field names below as illustrative; this is a days-old feature and the finalized API surface may differ slightly.
import boto3
client = boto3.client("bedrock-agent", region_name="us-east-1")
# Associate the private Knowledge Base
client.associate_agent_knowledge_base(
agentId="AGENT_ID",
agentVersion="DRAFT",
knowledgeBaseId="KB_ID",
description="Internal product docs, contracts, and policy documents.",
knowledgeBaseState="ENABLED"
)
# Attach the live web search tool as an action group
client.create_agent_action_group(
agentId="AGENT_ID",
agentVersion="DRAFT",
actionGroupName="live-web-search",
parentActionGroupSignature="AMAZON.WebSearch",
actionGroupState="ENABLED"
)
Routing logic: who decides where to look?
You have two real options here, and most production setups end up using both.
Model-driven routing. Let the foundation model itself decide which tool to invoke, based on your system instruction. This leans on the same tool-use reasoning that already powers function calling in Bedrock Agents — the model reads the question, checks what it has available, and picks. A prompt like this does a lot of the work:
instruction = (
"You have two tools: an internal knowledge base for company-specific "
"policies, contracts, and product documentation, and a live web search "
"for current public information. Always check the knowledge base first "
"for anything about our company's internal policies or products. Use "
"web search only for information that is time-sensitive, external, or "
"not something your internal documents would cover. If a question needs "
"both, use both and clearly attribute each fact to its source."
)
Deterministic pre-routing. For higher-stakes applications, don’t leave it entirely to the model’s judgment. Classify the incoming query first — a lightweight intent check, a keyword rule, or a small classifier call — and constrain toolChoice before the main inference call ever fires. If a query pattern-matches to “internal policy question,” restrict the tool set to the Knowledge Base only and skip web search entirely, both for latency and to avoid pulling in irrelevant public content. Reserve full tool access for queries that plausibly need both.
def resolve_tool_choice(query: str) -> dict:
time_sensitive_markers = ["today", "latest", "current", "this week", "recent"]
if any(m in query.lower() for m in time_sensitive_markers):
return {"auto": {}} # allow both KB and web search
return {"tool": {"name": "knowledge_base_search"}} # KB only, skip the web
In practice, model-driven routing with a well-written instruction handles the majority of cases fine. Deterministic pre-routing earns its complexity in regulated or customer-facing contexts where an unnecessary web search is itself a risk, not just a latency cost.
Guardrails: controlling what the agent is allowed to fetch
This is the part you shouldn’t skip. A Knowledge Base only ever surfaces content you already vetted and ingested. Web Search on Amazon Bedrock, by definition, can surface anything indexed on the public internet — which means your content filtering obligations just expanded to include material you never reviewed and don’t control. Bedrock Guardrails is the mechanism for keeping that in check, and it applies to both the query going out and the content coming back.
guardrail_config = {
"guardrailIdentifier": "web-search-guardrail-v1",
"guardrailVersion": "1",
"contentFilters": {
"denyTopics": ["medical-advice", "legal-advice", "competitor-pricing-scraping"],
"sensitiveInformationFilter": ["PII", "financial-account-numbers"]
},
"wordFilters": {
"blockedDomainsAppliedToTool": ["web_search"]
}
}
Two things worth calling out. First, apply the guardrail to the tool’s output, not just the model’s final response — filtering after the model has already reasoned over unfiltered web content defeats half the point. Second, keep an allowlist or denylist of domains where it matters (regulated industries especially): a web search tool with no domain constraints will happily pull from low-quality or unreliable sources with the same confidence as a reputable one, and the model has no innate way to tell the difference unless you tell it what “reputable” means for your use case.
Conflict resolution: when the two sources disagree
The scenario nobody plans for until it happens: the Knowledge Base says one thing, the live web says another. Your internal pricing doc says a plan costs $49/month; a stale competitor comparison page indexed by the search tool implies something different. Don’t let the model silently pick a winner. Instruct it to surface the conflict rather than resolve it invisibly:
instruction = (
"If information from the knowledge base conflicts with information from "
"web search, do not silently choose one. State both findings, note the "
"source of each, and flag the discrepancy to the user explicitly."
)
This is a small prompt addition that prevents a genuinely bad failure mode — an agent that quietly overrides your carefully maintained internal documentation with whatever a random public webpage said today. Internal sources should generally win for anything about your own company; web sources should generally win for anything about the external world. Say that explicitly rather than assuming the model will infer the right priority on its own.
Observability across two retrieval paths
Once an agent has two tools that can both plausibly answer a given question, your logging needs to capture which one actually fired, not just what the final answer said. At minimum, log the tool invoked per turn, the query sent to it, the number of results returned, and whether a Guardrail intervened. That data is what lets you tune the routing instruction later — if you notice the model is reaching for web search on questions your Knowledge Base could have answered faster and more precisely, that’s a signal to tighten the system prompt or move toward deterministic pre-routing for that query pattern.
The pattern to take away
Hybrid grounding isn’t complicated once you frame it correctly: Knowledge Bases for what you know, Web Search for what’s happening right now, a routing layer that picks intelligently between them, and Guardrails wrapped around the one tool that reaches outside your perimeter. That’s a genuinely more capable agent than either retrieval pattern alone — and it’s a lot less infrastructure than building your own web-freshness pipeline just to bolt onto a RAG system you already had working.
At Enkompass (enkompass.net), this is our home turf. We’ve shipped production Bedrock and SageMaker workloads that actually move the needle, not just demo well. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.