Build a web-grounded AI agent on Amazon Bedrock AgentCore: 2026 guide with code

Summary. On 17 June 2026, AWS made Web Search on Amazon Bedrock AgentCore generally available in US East (N. Virginia), priced at $7 per 1,000 queries with up to $200 in Free Tier credits for new accounts. It is a managed tool that lets an agent pull current, cited web results without any data leaving your AWS environment. AgentCore itself has been generally available since October 2025 and now ships 12 modular services. Early adopters report real numbers: Cox Automotive went from zero to 17 production agents in under a year, and Druva resolves 68 percent of support issues without a human. This guide shows how to wire up a grounded agent over the Model Context Protocol (MCP), what each part costs, and where teams get it wrong.

Most agent demos fail the same way in production. The model answers from training data that is months stale, invents a version number, and cites nothing you can check. A web-grounded agent fixes the first two problems and, done right, the third. The hard part was never the reasoning. It was the plumbing: a search connector, an auth layer, a tool contract the model can call, and a trace you can audit when it goes wrong. Amazon Bedrock AgentCore is AWS's answer to that plumbing, and the June 2026 Web Search launch removed the last piece most teams were building by hand.

This is a builder's guide for backend and machine learning engineers. It assumes you already have an agent framework you like and a foundation model you trust. What follows is how to ground that agent in live web knowledge on AWS, with code, a cost model you can defend to finance, and the governance controls an Indian or global enterprise will ask about before it ships.

What web grounding actually fixes

Grounding means the model answers from retrieved evidence, not memory. For an agent, that evidence comes from tools: a knowledge base for your own documents, an internal API for live records, and web search for everything outside your walls. The AWS blog announcing Web Search frames the value plainly: the agent looks at the user question, retrieves the latest facts, and then acts on current developments beyond the model's training cutoff.

Two properties separate the AgentCore version from bolting a public search API onto your own server. First, the query and the retrieval stay inside your AWS account, so user prompts never travel to an external search provider. Second, results arrive with source URLs, titles, and publication dates already attached, which is exactly the metadata you need to force real citations instead of confident guesses. AWS builds the tool on its own search infrastructure, the same lineage behind Alexa+, Amazon Quick, and Kiro, and combines a web index with structured knowledge graph facts for higher answer accuracy than raw web results alone.

Nicholas Larus-Stone, Head of AI Agents at Benchling, described the effect for scientific work: "Scientists using Benchling AI can now ask about a target they're actively working on and get answers grounded in both their institutional data in Benchling and published literature." Iskander Sanchez-Rola, Senior Director of AI and Innovation at Gen Digital, valued the boundary: "What we value most is that AWS uses its own search index and keep queries within our trusted AWS environment."

Amazon Bedrock AgentCore in one table

AgentCore is not a single product. It is a set of services you compose, described in the AgentCore developer guide. You can adopt one and ignore the rest. For a grounded agent you will usually touch Runtime, Gateway, Identity, Memory, and Observability, and add Policy once you need hard guardrails.

The service list matters for one reason: you are not locked into a framework or model to use it. Runtime works with CrewAI, LangGraph, LlamaIndex, Google ADK, OpenAI Agents SDK, and Strands Agents, and with models from OpenAI, Google Gemini, Anthropic Claude, Amazon Nova, Meta Llama, and Mistral. The product overview states the design goal directly: build with any framework, any model, with security built in from the start.

Web Search on AgentCore: what shipped on 17 June 2026

Web Search runs as a built-in connector target on AgentCore Gateway, exposed to your agent through MCP. Your agent sends a natural-language query; the tool returns the most relevant snippets, source URLs, titles, and publication dates for the model to reason over. Because it is a Gateway target, you do not manage servers, indexes, or rate limits. It went generally available on 17 June 2026 in the US East (N. Virginia) Region, per the AWS launch post.

The grounding is multi-source. Beyond standard web results, the tool gives the agent access to the Amazon Knowledge Graph with verified facts, which is how AWS positions it as more accurate than a plain web search. For an enterprise, the headline property is the data boundary: retrieval queries stay inside your AWS environment, so you can meet governance rules without shipping user prompts to a third-party search API.

Build it: a web-grounded agent, step by step

The whole pattern is three moves. Create a Gateway with a Web Search target, connect your agent to that Gateway over MCP, then add memory, identity, and a guardrail. You can do the first step in the console in a few minutes.

1. Create a Gateway with a Web Search target

In the Amazon Bedrock AgentCore console, create a Gateway. When you add a target, choose MCP target as the target protocol and Connectors as the target type, then select the Web Search tool as a preconfigured target. AWS creates a Gateway resource URL. You can add the same target to an existing Gateway later, so you rarely start from scratch twice. Before writing agent code, test the tool with the MCP Inspector: connect to the Gateway URL, enter a query, and run the tool to confirm it returns snippets with URLs and dates.

2. Connect an agent to the Gateway over MCP

The Gateway speaks MCP, so any MCP-capable client can call it. Here is the pattern with Strands Agents. The Gateway URL comes from the console, and the bearer token is minted by AgentCore Identity using your existing identity provider.

            from strands import Agent
from strands.tools.mcp import MCPClient
from mcp.client.streamable_http import streamablehttp_client

# From the AgentCore console; token minted by AgentCore Identity
GATEWAY_URL = "https://<gateway-id>.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp"
ACCESS_TOKEN = get_access_token()  # OAuth client-credentials via AgentCore Identity

def connect_gateway():
    return streamablehttp_client(
        GATEWAY_URL,
        headers={"Authorization": f"Bearer {ACCESS_TOKEN}"},
    )

mcp = MCPClient(connect_gateway)

with mcp:
    tools = mcp.list_tools_sync()  # includes the Web Search tool target
    agent = Agent(
        model="anthropic.claude-sonnet",   # any model AgentCore Runtime supports
        tools=tools,
        system_prompt=(
            "Answer only from retrieved search results. "
            "Cite every claim with its source URL and publication date. "
            "If the results do not cover the question, say so."
        ),
    )
    answer = agent("What changed in AWS agent tooling in the last 30 days? Cite sources.")
    print(answer)
          

The system prompt does real work here. Grounding is not automatic; the model will still answer from memory unless you instruct it to refuse when the retrieved results are thin. The rule "cite every claim with its source URL and publication date" turns the metadata Web Search returns into an auditable answer, which is the difference between a demo and something you can put in front of a customer.

3. Add memory, identity, and a guardrail

Three additions take this from a script to a service. AgentCore Memory gives the agent short-term memory for the current conversation and long-term memory that persists across sessions, so a returning user does not re-explain context. AgentCore Identity issues the token in the code above and plugs into Cognito, Okta, Microsoft Entra ID, or Auth0, so the agent acts as a known principal rather than a shared key. AgentCore Policy sits in front of every tool call and enforces rules you write in natural language or Cedar, AWS's open-source policy language, so you can block a tool or an action deterministically instead of hoping the model behaves.

Deploy the finished agent to AgentCore Runtime and the same code that ran on your laptop runs serverless with session isolation. Every step emits an OpenTelemetry trace to CloudWatch through Observability, so when an answer looks wrong you can see the exact query the agent sent and the results it got back.

What it costs

AgentCore is consumption-based with no upfront fees, per the AgentCore pricing page. The prices that matter for a grounded agent, as listed in June 2026:

Put real traffic through it. Say the agent answers 10,000 questions a month and runs two web searches per question. That is 20,000 queries, or $140 a month for Web Search. Suppose each request uses a quarter vCPU and half a gigabyte for 20 seconds. Runtime then costs roughly $0.00015 per request, about $1.50 a month for all 10,000. Compute is a rounding error next to search and model tokens. The lesson from the numbers: control how often the agent searches, because search is the largest AgentCore line on the bill. A well-written system prompt that searches once when needed, not on every turn, is a direct cost lever.

Model tokens are billed separately by whichever model you pick and usually dwarf the AgentCore fees, so budget those alongside. If token spend is the surprise on your bill, our note on how token pricing quietly drives agent cost covers the pattern.

Web Search on AgentCore vs the alternatives

Grounding has three common shapes. A managed web tool, a public search API you wire yourself, and a static retrieval store over your own documents. They are not mutually exclusive; most production agents use the managed web tool for open questions and a knowledge base for internal ones.

The honest read: if your questions are about your own data, a knowledge base is the right primary tool and web search is a supplement. If your questions are about the world, the managed web tool removes a connector, a rate limiter, and a data-egress review from your plate. The real cost of the self-wired route is rarely the API bill. It is the security review of sending user prompts to an outside vendor.

Governance: data egress, DPDP, and enterprise controls

The zero-egress property is not a marketing line; it is what lets a regulated team say yes. Because retrieval queries stay within AWS, a bank or hospital can ground an agent on live information without a user's prompt reaching a third-party search endpoint. That maps cleanly onto India's Digital Personal Data Protection Act 2023, where the flow of personal data to external processors is exactly what compliance teams scrutinise. Designing the retrieval path so prompts never leave your account is a defensible architecture choice, not a checkbox.

Policy and Identity carry the rest. Write Cedar rules so the agent can call the web tool but never a payments tool, or so it can read a record but never write one. Issue per-agent identities through your existing provider so every action is attributable in an audit. For Indian enterprises weighing this against a broader move to agents, our guide to enterprise generative AI strategy and our view on AI-powered customer experience put the build in business context.

Where teams get it wrong

Three failure modes show up repeatedly. The first is skipping the citation instruction and being surprised when a grounded agent still hallucinates; the model needs an explicit rule to prefer retrieved evidence and refuse when it is missing. The second is searching on every turn, which multiplies the $7-per-1,000 line without improving answers; gate the search behind a check that the question actually needs current facts. The third is treating web search as a replacement for a knowledge base; for questions about your own data, a managed retrieval pipeline over your documents will beat any web tool, and the two belong together.

One more, specific to cost discipline: agents left running without Observability turn a bad prompt into a silent bill. Trace every run from day one, and tie the search count per session to a dashboard. Teams that treat agent spend like any other cloud line item, the way disciplined cloud cost optimisation treats compute, avoid the end-of-quarter surprise.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based technology consultancy, founded in 2021, with CMMI Level 5 certification and senior-led engineering teams that build production AI agents on AWS. We design agent architectures aligned with DPDP Act requirements, wire AgentCore Gateway, Identity, Memory, and Policy into your existing stack, and put Observability and cost controls in place before launch, not after. If you are moving from an agent demo to something a regulated business can ship, talk to our team about a grounded, governed build.

References

1. Amazon Bedrock AgentCore overview — AWS

1. Announcing Web Search on Amazon Bedrock AgentCore — AWS News Blog, 17 June 2026

1. What is Amazon Bedrock AgentCore? (developer guide) — AWS

1. Amazon Bedrock AgentCore pricing — AWS

1. AgentCore Gateway documentation — AWS

1. AgentCore Runtime documentation — AWS

1. AgentCore Memory documentation — AWS

1. AgentCore Identity documentation — AWS

1. AgentCore Policy documentation — AWS

1. Top announcements of the AWS Summit in New York, 2026 — AWS News Blog

1. Model Context Protocol — MCP documentation

1. Cedar policy language — open-source policy language

1. Amazon Bedrock AgentCore is now generally available — AWS, October 2025

_Last updated: 18 July 2026._