What Bedrock AgentCore Web Search means for production AI agents.

Why grounding just became a first-class AWS feature

Every team building an AI agent eventually hits the same wall: the model's training data has a cutoff date, and the world does not. An agent that needs to answer a question about this week's pricing change, a competitor's product launch, or a regulatory update published yesterday cannot get there from its weights alone, and an internal knowledge base, however well maintained, only covers what someone inside the company chose to document. The gap between what a model knows and what a user is actually asking about is where most production agent failures live.

On August 21, 2026, AWS moved Web Search on Amazon Bedrock AgentCore to general availability in the US East (N. Virginia) region, a fully managed tool that lets agents ground their answers in current, cited web knowledge without the query or the result ever leaving the customer's AWS account. It arrived the same week Google's A2A protocol formally joined the Linux Foundation's Agentic AI Foundation alongside Anthropic's Model Context Protocol, and a few days after Google Cloud folded Vertex AI and Agentspace into a single Gemini Enterprise Agent Platform. Taken together, these are not three unrelated announcements. They are the same signal from three different vendors: the plumbing an AI agent needs to operate safely and usefully in production is becoming standard, governed infrastructure rather than something each engineering team quietly assembles out of a search API key and a prayer.

That shift matters more than the individual feature. For years, giving an agent access to live web knowledge meant one of two unattractive choices: pay a third-party search API and accept that every user query now flows through another company's servers, or build and maintain your own scraping and retrieval layer. AWS is betting that enough teams would rather have this as a checkbox on infrastructure they already operate, and the pricing and packaging suggest they are probably right.

What Web Search on AgentCore actually does

Strip away the launch-post language and the mechanics are straightforward. Web Search is exposed as a built-in connector target on the Bedrock AgentCore Gateway, using the Model Context Protocol, which means any MCP-aware agent framework, whether that is AWS's own Strands SDK, LangGraph, or a custom orchestration loop, can call it as a tool without writing bespoke scraping or search-integration code.

The parts worth understanding before you wire it in

• One tool call, structured results back. The agent issues a query and gets back the most relevant snippets, source URLs, page titles, and publication dates, packaged for the model to reason over rather than raw HTML it has to parse itself.
• Grounded, citable output. Because every returned snippet carries its source, the model can attribute claims to a specific URL rather than presenting synthesized web knowledge as if it came from nowhere, which is the property most compliance and legal teams actually care about.
• Zero data egress from the account boundary. AWS's specific claim is that the query and the results stay inside the customer's secured AWS environment throughout the call, rather than being routed through a third-party search vendor's infrastructure outside that boundary.
• Simple, usage-based pricing. Web Search is billed at $7 per 1,000 queries with no upfront commitment, and new AWS customers get an initial credit allowance, which makes it easy to pilot on a narrow use case before committing to a rollout.

None of this is exotic engineering. What is new is that it ships as a managed capability with a published price and a compliance story, rather than as a pattern every team has to reinvent from a blog post.

The three problems it quietly solves

We have watched enough clients try to bolt live web access onto an agent to recognize the same three failure modes showing up almost every time, and this feature addresses each of them directly rather than by accident.

• Stale knowledge, even with a good internal corpus. A well-built retrieval system over your own documents solves the internal knowledge gap, but it does nothing for questions about the outside world. Pricing pages, competitor moves, breaking regulatory changes, and this morning's news are all outside the scope of even the best internal RAG pipeline, and a model answering from training data alone will confidently give you last year's facts.
• Scraping fragility as a maintenance tax. Teams that build their own web-access layer usually end up running a fleet of headless browsers that breaks every time a target site redesigns its markup or tightens its bot detection, or they burn through a third-party search API's rate limits at the worst possible moment, usually during a product launch or an incident when agent traffic spikes. Either way, someone on the team now owns a piece of infrastructure that was never the actual product.
• Data egress as a compliance blocker. For teams in finance, healthcare, or the public sector, routing every user query through an external search vendor is often a hard stop, not a minor concern. Legal review of a new data processor can take longer than building the feature itself, and we have seen agent grounding work shelved for months for exactly this reason. A managed tool that keeps the query inside an existing, already-approved cloud boundary removes that specific blocker, assuming the underlying claim holds up to scrutiny, which is worth verifying rather than assuming.

Where it fits in the wider agent stack

Web Search does not stand alone. It is one connector inside Bedrock AgentCore's broader family, which also includes Runtime for hosting agent code, Memory for session and long-term state, Identity for scoping what an agent is allowed to act as, and a code interpreter and browser tool for tasks that need more than a search snippet can provide. For a team already building on AgentCore, enabling web search is closer to flipping a configuration switch than starting a project, because the identity, logging, and governance layers around it already exist.

That it is delivered over MCP is itself worth noting. Model Context Protocol has been converging into the default interface for tool calling across vendors who otherwise compete hard with each other, and Web Search joining the AgentCore Gateway as an MCP connector target is another data point in that direction, alongside the growing footprint we have covered in how teams are securing MCP servers before production and the industry consolidation behind the A2A protocol's move into neutral governance. The practical upshot is that a tool built against AgentCore's MCP interface today is more portable than a tool built against a single vendor's proprietary API from a couple of years ago, even if the underlying implementation is still AWS-specific.

It is also worth being honest about what this is not. Google Cloud has offered grounding with Google Search on Vertex AI for a while, and Google's newly consolidated Gemini Enterprise Agent Platform leans on the same idea. AWS is matching a capability its competitors already had, packaged with its own pricing and its own data-boundary story, rather than inventing a new category. For teams not already on AWS, that is a reason to evaluate the pattern rather than the specific vendor.

The trade-offs worth knowing before you flip it on

Nothing here is a free lunch, and a few specifics deserve attention before a team builds a rollout plan around it.

• It is available in one region today. General availability currently covers US East (N. Virginia) only, which is a real constraint for teams with data residency requirements outside the US or for anyone chasing tight latency from other regions. Plan for that limitation rather than discovering it during an architecture review.
• Per-query pricing scales with agent behaviour, not just user volume. A single user turn can trigger multiple searches if your agent decomposes a question into sub-queries, which is common in research-style agents. At $7 per 1,000 queries, a modest number of users can generate a bill that looks nothing like your initial back-of-envelope estimate. Instrument query fan-out before you commit to a broad rollout, not after the first invoice.
• You do not choose or see the underlying index provider. Unlike picking a search API deliberately, whether that is Bing, Brave Search, or Tavily, and knowing its coverage and freshness characteristics, AWS has not published which index or ranking system sits behind this tool. You inherit whatever bias, coverage gaps, and freshness lag that provider has, with less transparency than a direct vendor relationship would give you.
• Citations are not the same as verification. A cited snippet reduces hallucination risk considerably, but it does not eliminate it, because a model can still misread or misattribute a source. Grounding is not a substitute for an evaluation pipeline that checks whether a cited claim actually matches what the source says, particularly for anything customer-facing or regulated.
• It deepens a specific dependency. Every managed tool you adopt from a single cloud vendor is another piece of your agent stack that is not portable without rework. That trade-off is not a reason to avoid it, but it is the same build-versus-buy calculus we have written about for model gateways, and it deserves the same deliberate evaluation rather than a default yes.

What we'd tell a client evaluating this today

If you are already building on Bedrock AgentCore, this is a low-risk, low-effort addition worth piloting on a narrow, well-scoped use case first, with query volume instrumented from day one so the pricing model does not surprise anyone once it reaches production traffic. If you are building agents on a different stack entirely, this specific feature is not a reason to migrate, but the pattern it represents, a managed, in-account, cited web-grounding tool exposed over MCP, is now table stakes, and evaluating an independent provider through the same interface shape is a reasonable substitute. And if you operate in a regulated industry, the zero-egress claim is the single detail worth pushing AWS on directly, including how the underlying search index provider fits into your existing data processing agreements, before you route real customer queries through it.

The broader lesson holds regardless of which vendor you choose: grounding an agent in live web knowledge is no longer a problem you need to solve from scratch, and treating it as commodity infrastructure rather than a custom build is usually the right call. If you are weighing whether to adopt a managed grounding tool like this one or build a retrieval layer suited to your own compliance and latency requirements, that is exactly the kind of architecture decision our AI consultancy work is built to help scope properly before you commit engineering time to either path.

Keep reading

• Why every production AI system needs a model gateway Stripe's $7B OpenRouter acquisition put AI model gateways on every CTO's radar, and the same build-versus-buy questions apply here.
• The real cost of RAG in production The six cost centres that drive a production RAG bill, and where a managed grounding tool changes the calculation.
• What context engineering actually means for production AI systems The discipline replacing prompt engineering in production LLM systems, and why getting it wrong costs real money.
• Securing MCP servers before production The specific risks MCP's rapid adoption introduces, and the controls that keep an MCP-connected agent stack safe.