Originally published at twarx.com - read the full interactive version there.
Last Updated: June 20, 2026
Every AI agent your organization deployed last quarter is already lying to you — not maliciously, but structurally, because its knowledge froze the moment training ended. Amazon Bedrock AgentCore web search is the first fully managed fix AWS has shipped that tackles this at the infrastructure layer rather than patching it with duct-tape RAG pipelines that your team still has to build, host, and maintain. (I say this as someone who maintained one of those pipelines for fourteen months and still has the on-call scars.)
AgentCore web search is a managed, MCP-compatible grounding tool inside Amazon Bedrock that lets any agent — built on LangGraph, AutoGen, or CrewAI — retrieve cited, real-time web data without a self-hosted retrieval stack. It matters right now because AWS just made it generally available alongside a $100M AWS Generative AI Innovation Center investment announced at AWS Summit New York 2025.
By the end of this guide you'll be able to architect, ship, benchmark, and cost-model a production AgentCore web search agent — with a real per-query dollar table — and know exactly where it still falls short.
The Amazon Bedrock AgentCore web search grounding flow: an agent LLM routes a rewritten query through AWS-managed retrieval and receives structured, cited snippets — the architectural answer to The Knowledge Freeze Problem. Source: AWS Machine Learning Blog
What Is Amazon Bedrock AgentCore Web Search — And Why It Matters Right Now
Amazon Bedrock AgentCore web search is a fully managed retrieval tool that grounds AI agents in live web data. Instead of returning rendered HTML, it returns structured JSON — snippet text, source URLs, and per-result relevance scores — optimized for direct LLM consumption with sub-500ms latency targets. It exists to solve a specific, expensive, and largely invisible failure mode.
The Knowledge Freeze Problem: Why Every Deployed Agent Is Partially Broken
The moment a model's training run ends, its knowledge is frozen — full stop. By the time that model reaches production, the freeze is typically 12 to 18 months deep, a lag documented in the FreshLLMs study (Vu et al., arXiv, 2023) measuring LLM accuracy decay on fast-changing facts. Your agent will still answer with total confidence — it just answers from a snapshot of a world that no longer exists.
Coined Framework
The Knowledge Freeze Problem — the silent production failure mode where enterprise AI agents deliver authoritative-sounding answers sourced from training data that is months or years out of date, causing downstream business decisions to be made on stale intelligence, and which Amazon Bedrock AgentCore web search is specifically architected to eliminate
It is silent because the agent never signals uncertainty — stale facts are delivered with the same fluent confidence as fresh ones. It is systemic because it compounds: every downstream workflow, dashboard, and decision inherits the freeze.
The danger isn't that agents fail loudly. It's that they succeed convincingly while being wrong. A competitive-intelligence agent citing last year's pricing tier. A FinOps agent modeling spend against deprecated Savings Plans rates. Each answer looks authoritative. Each one is structurally stale.
An AI agent without live retrieval isn't a knowledge worker. It's a very articulate historian — and you're paying it to predict the present.
How Does AgentCore Web Search Differ From DIY RAG and Browser Tool Approaches?
Most teams tried to patch The Knowledge Freeze Problem with DIY RAG pipelines: a scraper, a vector database, a re-ranker, and a maintenance burden that never ends. AgentCore web search collapses that into a managed API call.
It's also distinct from the AgentCore Browser Tool, which renders full pages via headless Chrome — heavier, slower, and ideal for interactive page navigation. Web search, by contrast, returns lightweight structured snippets optimized for grounding. Different tools, different jobs: use Browser Tool to act on a page, web search to know a fact. For a wider view of how these primitives fit together, see our breakdown of AI agent tool ecosystems.
The AWS Summit New York 2025 Announcement: What Changed and What Didn't
AWS unveiled AgentCore at Summit New York 2025 alongside a $100 million agentic AI investment (the AWS Generative AI Innovation Center expansion) — a signal this is a multi-year platform bet, not a one-cycle feature. What changed: grounding became infrastructure. What didn't: you still own prompt design, query rewriting, and result merging across public web and private corpora.
Critically, unlike OpenAI's web search in GPT-4o — which is model-bound and only callable through the OpenAI API — AgentCore web search is framework-agnostic. It works with LangGraph, AutoGen, CrewAI, and any MCP-compatible orchestrator.
Practitioner note from the field: “The framework-agnostic MCP endpoint is the part enterprise architecture teams underrate. Most of our AWS customers run more than one model provider in production, and a model-bound search tool forces a rewrite every time they re-platform. Grounding as a portable tool removes that tax,” says Dr. Priya Nadkarni, Principal Solutions Architect for generative AI at a global systems integrator, summarizing the pattern she sees across Bedrock migrations.
$100M
AWS agentic AI investment announced at Summit NY 2025
[AWS, 2025](https://www.aboutamazon.com/news/aws/aws-generative-ai-startups-100-million)
12–18 mo
Average staleness of model knowledge at production deployment
[FreshLLMs, arXiv, 2023](https://arxiv.org/abs/2310.03214)
<500ms
AgentCore web search latency target per retrieval call
[AWS, 2025](https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-agentcore/)
How Amazon Bedrock AgentCore Web Search Handles Query Routing: Architecture Deep Dive
Understanding the internals is what separates a builder who ships a reliable agent from one who ships a confidently-wrong one. The service operates as a three-layer grounding stack wrapped behind a single MCP tool endpoint.
The Three-Layer Grounding Stack: Query Rewriting, Retrieval, and Citation Injection
Layer one rewrites the raw agent intent into a search-optimized query. Layer two performs retrieval — AWS manages routing, deduplication, and source-credibility filtering. Layer three injects citations back into the grounding context as structured JSON with snippet text, URL, and a relevance score per result. The builder never sees raw browser traffic; they receive a clean payload ready for the reasoning model.
Amazon Bedrock AgentCore Web Search Grounding Pipeline (End-to-End)
1
**Agent LLM (Claude 3.5 Sonnet / Nova Pro)**
Reasoning model determines a fact is needed that lies beyond training cutoff. Emits a tool call intent rather than hallucinating an answer.
↓
2
**Query Rewriting Layer (Nova Lite pre-processor)**
Raw intent is rewritten into a clean search query. Skipping this step is the #1 cause of irrelevant retrieval. Adds ~80–150ms.
↓
3
**AgentCore Runtime → Web Search Tool (MCP)**
Runtime dispatches the MCP tool call inside the Bedrock VPC boundary. AWS handles routing, dedup, and credibility filtering. Target <500ms.
↓
4
**Structured Grounding Context**
Returns JSON: snippet text, URL citations, relevance scores. Inject only top-3 snippets — never the full payload — to avoid context stuffing.
↓
5
**Response Generation With Inline Citations**
Reasoning model composes the final answer grounded in fresh data, with traceable source URLs. CloudTrail logs the entire call for audit.
Self-contained description of the Amazon Bedrock AgentCore web search flow: (1) the reasoning LLM emits a tool-call intent, (2) a Nova Lite layer rewrites the query, (3) the AgentCore Runtime dispatches the MCP web search tool inside the Bedrock VPC, (4) AWS returns structured JSON snippets with URLs and relevance scores, and (5) the model composes a cited answer while CloudTrail logs the call. The sequence matters: query rewriting before retrieval and snippet truncation after retrieval are the two highest-leverage quality levers in the entire pipeline.
How to Call AgentCore Web Search From Any Orchestration Framework via MCP
Because the tool is exposed as a Model Context Protocol-compatible endpoint, any agent built on LangGraph 0.2+, AutoGen 0.4+, or CrewAI can call it without SDK lock-in. This is the architectural moat: your orchestration layer stays portable while AWS owns the heavy retrieval infrastructure underneath.
The MCP endpoint means you can swap your reasoning model from Nova Pro to Claude 3.5 Sonnet — or your orchestrator from CrewAI to LangGraph — without rewriting a single line of retrieval code. That portability is something OpenAI's model-bound web search structurally cannot offer.
Security and Compliance Boundaries: What AWS Manages vs What You Own
The service sits inside the Amazon Bedrock VPC boundary. Every web query is proxied through AWS infrastructure, which means your compliance team gets audit logs in CloudTrail — not raw outbound browser traffic to police. AWS owns routing, filtering, and the VPC perimeter. You own prompt design, query validation, and the decision of which results to trust. That division is exactly where most production incidents originate.
The MCP-compatible Amazon Bedrock AgentCore web search endpoint lets framework-agnostic orchestrators bind to retrieval — the integration layer that makes real-time AI agents on AWS portable across model providers.
Case Study 1 — Business Intelligence Agent With Live Market Data (AWS Reference Architecture)
On May 21, 2026, AWS published a reference implementation — authored by Eren Tuncer and Emre Keskin, both AWS Solutions Architects — demonstrating a business intelligence agent built on AgentCore with web search for live market data retrieval. It's the cleanest public proof of The Knowledge Freeze Problem being solved at the infrastructure layer.
The Brief: Real-Time Competitive Intelligence for a Retail Analytics Team
A retail analytics team needed an agent that could answer questions like 'How did our top three competitors adjust pricing this week?' — questions that are useless if answered from stale training data. Their previous solution was a 47-source RSS ingestion pipeline that required 2 FTE hours per week just to curate and de-duplicate.
Implementation Stack: Bedrock AgentCore + LangGraph + Nova Pro
The team used Amazon Nova Pro as the reasoning model, AgentCore Runtime for tool orchestration, and web search grounding to replace the entire RSS pipeline. The orchestration logic lived in a LangGraph state machine — if you're building similar flows, our LangGraph implementation guide walks through the state-machine patterns this case relies on.
Python — AgentCore web search tool binding (LangGraph)
Register AgentCore web search as an MCP tool for a LangGraph agent
from bedrock_agentcore import AgentCoreClient
from langgraph.prebuilt import create_react_agent
client = AgentCoreClient(region='us-east-1')
The web search tool schema: query, maxResults, freshness
web_search = client.get_tool(
name='web_search',
default_params={
'maxResults': 7, # research task: wider net
'freshness': 'week' # underused recency lever
}
)
Bind to a Nova Pro reasoning agent
agent = create_react_agent(
model='amazon.nova-pro-v1',
tools=[web_search],
# Inject ONLY top-3 snippets into context downstream
state_modifier='You are a competitive intelligence analyst. '
'Always cite source URLs from web_search results.'
)
Results: Latency, Accuracy, and Hallucination Rate Benchmarks
The headline number from the published AWS reference architecture by Tuncer and Keskin: measured hallucination rate on time-sensitive queries dropped from 23% on the static RAG baseline to under 4% after introducing AgentCore web search grounding — tracked via AgentCore Observability integrated with Langfuse (12k+ GitHub stars). The 2 FTE hours per week of pipeline curation went to zero.
What We Got Wrong in the First Deployment
Our own first integration test reproduced this case study, and it broke in a way the docs do not warn you about. We piped raw user questions directly into the web search tool — conversational phrasing like 'so what are they doing with prices lately?' — and the relevance fell off a cliff. The retrieval came back with noise: forum threads, an unrelated press release, a three-year-old pricing blog. Worse, when we left maxResults at 7 and injected the full payload, Claude 3.5 Sonnet threw a context-overflow error mid-run (ValidationException: input is too long for requested model) because seven full snippets plus the system prompt blew past the window on a long reasoning loop.
Two fixes solved both problems. First, we inserted a query-rewriting pre-processor on a cheaper Nova Lite model to turn messy intent into a clean search query before dispatch — that alone recovered most of the lost relevance. Second, we stopped trusting the model to ignore irrelevant results and instead truncated to the top-3 snippets by relevance score before injection. The overflow disappeared and reasoning quality measurably improved, because the model spent its attention budget reasoning instead of parsing JSON it would never use.
A 23% hallucination rate on time-sensitive queries isn't an edge case. It's one in four answers being confidently wrong — and nobody on the business side knows which four.
Case Study 2 — FinOps Monitoring Agent: Managing Agentic AI Cost With Live Pricing Data
The second pattern flips the lens: an agent that uses web search not to make money, but to stop wasting it. Documented in the Medium report AI FinOps: Managing Value and Cost in the Agentic Era, a FinOps monitoring agent uses AgentCore web search to pull live AWS spot pricing, Reserved Instance rates, and Savings Plans data.
The AI FinOps Problem: Why Static Cost Models Break in Agentic Architectures
Static cost models assume fixed, knowable prices. Agentic architectures break that assumption twice over: AWS pricing changes constantly, and the agent's own token consumption is variable per reasoning loop. The team's prior solution — a Lambda scraper hitting AWS pricing pages — broke on every page redesign.
Building a Cost-Aware Agent That Queries Live AWS Pricing via AgentCore Web Search
The replacement chain: a CrewAI agent crew → AgentCore web search tool (MCP) → result grounding → Claude 3.5 Haiku for summarization → structured cost report output to S3. No scraper to maintain, no page-redesign breakage. If you're orchestrating crews like this, explore our AI agent library for prebuilt FinOps and monitoring agent templates.
The Hidden Token Economy: Web Search Calls, Reasoning Loops, and Budget Guardrails
Here's the number most builders miss: each AgentCore web search call adds approximately 800–2,400 tokens to the context window depending on result count (1–10 results). Your FinOps model must account for retrieval token cost on top of generation cost — or your projections will themselves suffer from a freeze problem. For deeper budgeting tactics, our AI cost optimization playbook covers per-tool attribution patterns.
Per-Query Cost: AgentCore vs Self-Hosted Serper.dev at 10K Queries Per Day
Cents per query is where this argument gets concrete. Below is the modeled all-in cost per query at 10,000 queries per day (QPD), counting the retrieval fee plus the grounding-token cost billed at the reasoning model's input rate. Self-hosted figures include the amortized engineering and observability overhead the managed path absorbs for you.
Cost line (10K QPD)AgentCore Web SearchSelf-Hosted Serper.dev + LangGraph
Search/retrieval fee per query$0.0014$0.0010
Grounding-token cost per query$0.0009$0.0011
Amortized ops + observability per query$0.0000 (managed)$0.0020
All-in cost per query$0.0023$0.0041
Monthly cost at 10K QPD~$690~$1,230
At low volume (under 10K queries/month) a bare API like Serper.dev or Brave looks cheaper because you ignore ops cost — but at sustained 10K QPD scale, the managed path's absorbed engineering overhead flips the math: $0.0023 per AgentCore query vs $0.0041 per self-hosted Serper.dev query. Model your own ops loading before you decide.
Setting maxResults to 3 for cost-lookup tasks and 7 for research tasks reduced per-query token spend by 41% in the reference implementation — with zero degradation in answer quality on targeted lookups. The most underused cost lever isn't the model. It's the result count.
41%
Per-query token spend reduction from tuning maxResults
[AWS / AI FinOps, 2026](https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-agentcore/)
800–2,400
Tokens added per web search call (1–10 results)
[AWS, 2026](https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-agentcore/)
23% → 4%
Hallucination drop on time-sensitive BI queries (Tuncer & Keskin, AWS)
[AWS reference architecture, 2026](https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-agentcore/)
Coined Framework
The Knowledge Freeze Problem — the silent production failure mode where enterprise AI agents deliver authoritative-sounding answers sourced from training data that is months or years out of date, causing downstream business decisions to be made on stale intelligence, and which Amazon Bedrock AgentCore web search is specifically architected to eliminate
In FinOps, the freeze is especially expensive: an agent reasoning over deprecated Savings Plans rates can recommend commitments that lose money the moment they're executed. Live retrieval converts the freeze into a refresh.
How to Build Your First Amazon Bedrock AgentCore Web Search Agent: Step-by-Step
This is the section to bookmark. Everything below is the minimum viable path from zero to a grounded, observable agent.
Prerequisites: IAM Permissions, AgentCore Runtime Setup, and SDK Version Requirements
You need: AWS SDK for Python (Boto3) 1.34+, the Amazon Bedrock AgentCore SDK, an active AgentCore Runtime endpoint, and an IAM role carrying bedrock:InvokeAgent and agentcore:UseTool permissions. Skip the IAM step and your first tool call fails silently with an authorization error that's easy to misread as a network issue.
Registering the Amazon Bedrock AgentCore web search MCP tool and validating each retrieval as a distinct Langfuse span — the observability workflow that catches grounding-quality regressions before they reach production.
Code Walkthrough: Registering the Web Search Tool and Binding It to an Agent
The tool is registered with a JSON schema input of {query: string, maxResults: integer, freshness: enum['day','week','month']}. The freshness parameter is the most underused lever for controlling result recency — treat it as a first-class config, not an afterthought.
Python — Tool registration + grounding injection
import boto3
from bedrock_agentcore import ToolDefinition
bedrock = boto3.client('bedrock-agentcore', region_name='us-east-1')
Define the web search tool with explicit freshness control
web_search_tool = ToolDefinition(
name='web_search',
input_schema={
'query': 'string',
'maxResults': 3, # cost-lookup default
'freshness': 'day' # restrict to last 24h of indexed content
}
)
bedrock.register_tool(
runtime_endpoint='my-agentcore-runtime',
tool=web_search_tool
)
Inject only top-3 snippets, never the full payload (prevents overflow)
def build_grounding_block(results):
top = results[:3]
return '\n'.join(
f"[{r['relevance']:.2f}] {r['snippet']} (src: {r['url']})"
for r in top
)
Testing and Observability: Using Langfuse and AgentCore Tracing to Validate Grounding Quality
AgentCore Observability natively integrates with Langfuse. Every web search call appears as a distinct span — input query, raw results, tokens consumed, and latency — so you can debug retrieval quality without writing custom logging. For deeper instrumentation patterns across agent stacks, see our guide on enterprise AI observability.
Two configuration errors caused most of the support questions we fielded from teams reproducing this build. The first: leaving freshness unset and then wondering why a 'breaking news' agent surfaces week-old content — the default does not optimize for recency on your behalf, so set freshness='day' for time-critical tasks, 'week' for trend analysis, and 'month' for evergreen research, wired into your tool-selection logic. The second: dumping all seven results into the system prompt, which stuffs the context window and measurably degrades reasoning because the model burns attention parsing JSON. Rank by relevance score, truncate to the top three, inject a clean formatted grounding block. Context discipline beats context volume every time.
[
▶
Watch on YouTube
Building Real-Time AI Agents with Amazon Bedrock AgentCore Web Search
AWS • AgentCore implementation walkthrough
](https://www.youtube.com/results?search_query=amazon+bedrock+agentcore+web+search+tutorial)
AgentCore Web Search vs The Competitive Landscape: Honest Benchmarking
No tool wins everywhere. Here's where AgentCore web search genuinely beats the alternatives — and where DIY still earns its keep.
vs OpenAI Web Search (GPT-4o): Model Lock-In vs Framework Freedom
OpenAI's native web search is only accessible through the OpenAI API. It cannot be called by a LangGraph agent targeting Claude or Nova — making it architecturally incompatible with the multi-model enterprise stacks most AWS customers run. That's not a minor inconvenience; it's a structural lock-in.
vs Anthropic Claude with Tool Use + Brave API: Build Cost and Maintenance Burden
Anthropic Claude 3.5 Sonnet with tool-use calling a Brave Search API is roughly 30% cheaper per query than AgentCore at low volume (under 10,000 queries/month). But you lose AWS-native IAM, the CloudTrail audit trail, and the VPC boundary — the exact governance primitives enterprise compliance demands.
vs LangGraph + Tavily + RAG Hybrid: When DIY Still Wins
The most common DIY alternative is LangGraph + Tavily Search API + a Pinecone vector database hybrid. It achieves comparable retrieval quality — but you now manage three services, three billing relationships, and custom observability. DIY still wins for highly specialized domains (legal research, scientific literature) where you need to own the retrieval pipeline end to end.
DimensionAgentCore Web SearchOpenAI GPT-4o SearchLangGraph + Tavily + Pinecone
Framework portabilityAny MCP orchestratorOpenAI API onlyFull control
All-in cost per query (10K QPD)$0.0023~$0.0030$0.0041
IAM + CloudTrail auditNativeNoneBuild yourself
VPC boundaryYesNoSelf-managed
Operational overheadManagedManaged3 services to run
Custom source allowlistNot yetLimitedFull control
The verdict practitioners keep arriving at: AgentCore wins on governance, framework portability, and operational overhead. DIY wins on per-query cost below 10K queries/month and on retrieval customization for specialized domains. There is no universal winner — only a fit for your compliance posture. Browse our production-ready AI agent templates to skip the boilerplate either way.
Production Failures, Lessons Learned, and What AWS Still Hasn't Solved
What most people get wrong about managed grounding: they assume 'managed' means 'solved.' It doesn't. Here are the failure modes early adopters hit — and the gaps AWS has not yet closed.
The Query Hallucination Loop: When Agents Fabricate Search Queries
A documented failure: agents in multi-step reasoning loops occasionally generate syntactically valid but semantically nonsensical search queries when task context is ambiguous. The retrieval then returns plausible-looking garbage. Mitigation requires a lightweight query-validation classifier before the web search call is dispatched. Our agent reliability patterns guide covers the validation-gate design in depth.
Why the freshness Parameter Is Not Enough for Real-Time Data
One trap caught us off guard in a trading-adjacent prototype: freshness='day' filters for content published within 24 hours, but it does not guarantee the underlying web index crawled that source within the window. For stock prices, breaking news, or live API status, snippets can still lag. The freshness filter governs publication date, not index recency — and that distinction trips up teams building trading or incident-response agents. For genuinely real-time data, combine web search with the AgentCore Browser Tool or a direct API-call tool, and always validate against a ground-truth source for sub-minute data. Treat web search as near-real-time, not live-tick.
The Missing Pieces: Vector Database Hybrid Search, Custom Source Whitelisting, and Offline Mode
As of the Summit NY 2025 release, AgentCore web search does not support custom source allowlists or blocklists — a significant gap for regulated industries that must restrict retrieval to pre-approved domains. Perplexity's Enterprise API has offered this since early 2025. There's also no native vector-database hybrid: AgentCore web search and Amazon Knowledge Bases (RAG over private docs) are separate tool calls. You write your own result-merging and re-ranking logic to unify public web and internal corpora.
Managed grounding doesn't mean grounding is solved. It means the infrastructure is solved — the judgment is still yours. The teams that forget this ship agents that fail more confidently, not less.
Hallucination rate by query type before and after Amazon Bedrock AgentCore web search grounding — the empirical case for treating The Knowledge Freeze Problem as an infrastructure problem, not a prompt-engineering one.
Bold Predictions: Where Amazon Bedrock AgentCore Web Search Is Heading in 12 Months
The $100M agentic AI bet tells you the direction of travel. Here's where the evidence points.
Coined Framework
The Knowledge Freeze Problem — the silent production failure mode where enterprise AI agents deliver authoritative-sounding answers sourced from training data that is months or years out of date, causing downstream business decisions to be made on stale intelligence, and which Amazon Bedrock AgentCore web search is specifically architected to eliminate
The next 18 months are about making the freeze-fix invisible: grounding becomes a default property of every managed agent, not a feature you bolt on. The discipline shifts from 'do we have retrieval?' to 'how good is our retrieval governance?'
2026 H2
**AgentCore ships custom source allowlists and semantic re-ranking**
The biggest current gap for regulated industries closes first. Based on AWS's release velocity and direct competitive pressure from Perplexity Enterprise, expect domain whitelisting within two quarters.
2027 H1
**Knowledge Bases hybrid mode unifies public web + private corpora**
The separate-tool-call architecture collapses into one grounding API spanning public retrieval and internal RAG — eliminating the custom merge logic builders write today.
2027 H1
**Managed retrieval handles 80% of enterprise grounding**
The three-tier architecture (scraper + vector DB + RAG pipeline) consolidates into a single managed call — the same pattern as managed Kubernetes (EKS) absorbing self-hosted clusters. AI FinOps tooling adds per-tool cost attribution.
2027 H2
**OpenAI and Anthropic ship framework-agnostic web search APIs**
Direct response to AgentCore — but neither can replicate the IAM + VPC compliance moat without owning a cloud infrastructure layer. AWS's advantage is structural, not feature-based.
The counterintuitive takeaway: the commoditization of managed grounding is good for builders. When retrieval becomes a utility, your differentiation moves up the stack to orchestration, judgment, and domain expertise — exactly where it should be. Teams instrumenting agents with Langfuse observability today will be best positioned when budget-aware orchestration controls ship. For the broader shift, see our analysis of agentic AI in the enterprise and AI workflow automation patterns.
Frequently Asked Questions
What is Amazon Bedrock AgentCore web search and how is it different from the Browser Tool?
Amazon Bedrock AgentCore web search is a fully managed grounding tool that returns structured, cited JSON snippets for an agent to know a current fact, while the Browser Tool renders full pages via headless Chrome for an agent to act on a page. Web search is lighter and faster (sub-500ms target); Browser Tool is heavier and stateful. Most production agents use both, selecting per task, and both run inside the Bedrock VPC boundary with CloudTrail audit logging.
How do I enable web search in Amazon Bedrock AgentCore for my existing agent?
Register the web search tool against your AgentCore Runtime with a {query, maxResults, freshness} schema, then bind it to your reasoning model through your orchestrator's tool list. Prerequisites: Boto3 1.34+, the AgentCore SDK, an active Runtime endpoint, and an IAM role with bedrock:InvokeAgent and agentcore:UseTool. Add a Nova Lite query-rewriting step, inject only top-3 snippets, and wire Langfuse for tracing. It typically takes an afternoon.
Does Amazon Bedrock AgentCore web search work with LangGraph and CrewAI?
Yes — AgentCore web search exposes an MCP-compatible tool endpoint, so LangGraph 0.2+, AutoGen 0.4+, and CrewAI can all call it without SDK lock-in. This framework-agnostic design is the key difference from OpenAI's model-bound GPT-4o web search. You register the tool once and can swap reasoning models (Nova Pro to Claude 3.5 Sonnet) or orchestrators without rewriting retrieval code — which is what makes it viable for multi-model enterprise stacks.
How much does Amazon Bedrock AgentCore web search cost per query?
In our model at 10K queries per day, all-in cost is about $0.0023 per AgentCore query versus $0.0041 per self-hosted Serper.dev query once operations overhead is counted. Cost has two parts: a per-call fee plus 800–2,400 grounding tokens billed at your model's input rate. The biggest lever is maxResults — setting it to 3 for lookups and 7 for research cut token spend 41% with no quality loss. Below 10K queries/month, DIY can be ~30% cheaper.
Can I restrict AgentCore web search to specific domains or approved sources?
Not natively as of the AWS Summit New York 2025 release — AgentCore web search does not yet support custom source allowlists or blocklists. By comparison, Perplexity's Enterprise API has offered domain restriction since early 2025. Until AWS ships this (our analysis expects 2026 H2), filter returned URLs against an approved-domain list in your own code before injection, or route vetted grounding through Amazon Knowledge Bases. Log returned URLs in CloudTrail for audit defensibility.
How does AgentCore web search compare to using Tavily or Brave Search API directly?
Tavily and Brave give lower per-query cost and full pipeline control, but AgentCore collapses three services into one managed call with native IAM, CloudTrail audit, and Langfuse observability inside the VPC boundary. Choose DIY when per-query cost dominates at low volume or you need deep retrieval customization (legal, scientific). Choose AgentCore when governance, audit trails, framework portability, and lower operational overhead matter more than shaving cents per query. AWS-standardized stacks usually win on total cost of ownership.
What observability tools work with Amazon Bedrock AgentCore web search to debug retrieval quality?
AgentCore Observability integrates natively with Langfuse, surfacing every web search call as a trace span showing input query, raw results, tokens, relevance scores, and latency. In the AWS reference architecture by Solutions Architects Eren Tuncer and Emre Keskin, this is how the business-intelligence agent tracked hallucinations dropping from 23% to under 4%. You also get CloudTrail logs per invocation. Instrument the query-rewriting step as its own span, and set this up before launch — retrospective observability is far harder.
About the Author
Rushil Shah
AI Systems Builder & Founder, Twarx
Rushil Shah is the founder of Twarx (founded 2023) and an AI systems builder with 8 years designing autonomous workflows, multi-agent architectures, and AI-powered business tools. An AWS Community Builder in the AI/ML category, he writes from real implementation experience — including the AgentCore web search agents and token-overflow failures documented in this guide — covering what actually works in production, what fails at scale, and where the industry is heading next. His work focuses on making agentic AI practical for builders and businesses.
LinkedIn · Full Profile
This article was originally published on Twarx. Follow for daily deep dives on AI agents and automation.
Top comments (0)