--- type: "post" id: "introducing-the-web-search-api-on-amazon-bedrock-c1b723" slug: "introducing-the-web-search-api-on-amazon-bedrock-c1b723" title: "Introducing the Web Search API on Amazon Bedrock AgentCore" description: "AWS has introduced a direct Web Search API for Amazon Bedrock AgentCore, allowing applications and agent loops to query Amazon’s web index without first creating an AgentCore Gateway." retrieval_nugget: "AWS has introduced a direct Web Search API for Amazon Bedrock AgentCore, allowing applications and agent loops to query Amazon’s web index without first creating an AgentCore Gateway. The change gives builders a lower-level integration option with domain and date filters, IAM authorization, and private-network access." published_at: "2026-11-12" updated_at: "2026-11-12" record_date: "2026-11-12" date_kind: "published_at" topics: ["agent-loops"] entities: ["Amazon Web Search API","Amazon Bedrock AgentCore","Amazon Web Services","AgentCore Gateway","LangChain"] related_patterns: ["agent-protocols-become-interoperability-layer"] novelty_label: "new_fact" what_changed: "AWS introduced a Web Search API for Amazon Bedrock AgentCore, distinct from the previously covered Web Answer capability and integration examples." prior_refs: ["https://newruntime.com/posts/getting-started-with-web-answer-on-amazon-bedrock-7b64a7/"] source_url: "https://aws.amazon.com/blogs/machine-learning/introducing-the-web-search-api-on-amazon-bedrock-agentcore" source_urls: ["https://aws.amazon.com/blogs/machine-learning/introducing-the-web-search-api-on-amazon-bedrock-agentcore"] schema_version: "newruntime-agent-readable-v0.2" stable_id: "post:introducing-the-web-search-api-on-amazon-bedrock-c1b723" status: "published" visuals: [] editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]} routes: {"html":"https://newruntime.com/posts/introducing-the-web-search-api-on-amazon-bedrock-c1b723/","markdown":"https://newruntime.com/posts/introducing-the-web-search-api-on-amazon-bedrock-c1b723.md","json":"https://newruntime.com/posts/introducing-the-web-search-api-on-amazon-bedrock-c1b723.json"} markdown_url: "https://newruntime.com/posts/introducing-the-web-search-api-on-amazon-bedrock-c1b723.md" --- # Introducing the Web Search API on Amazon Bedrock AgentCore ## Retrieval answer AWS has introduced a direct Web Search API for Amazon Bedrock AgentCore, allowing applications and agent loops to query Amazon’s web index without first creating an AgentCore Gateway. The change gives builders a lower-level integration option with domain and date filters, IAM authorization, and private-network access. ## Summary AWS has introduced a direct Web Search API for Amazon Bedrock AgentCore, allowing applications and agent loops to query Amazon’s web index without first creating an AgentCore Gateway. The change gives builders a lower-level integration option with domain and date filters, IAM authorization, and private-network access. ## What happened AWS’s announcement says the new API exposes `InvokeWebSearch` on the AgentCore data plane. Applications can call it through AWS SDKs or the AWS Command Line Interface, signing requests with standard AWS credentials using Signature Version 4. There is no API key to manage and no search resource to create. The caller needs the IAM permission `bedrock-agentcore:InvokeWebSearch` on the AWS-managed web search tool. AWS says the API can be used in a conventional application, a developer’s own agent loop, or a data pipeline. A request includes a search query and can specify a result count from 1 to 25; without an explicit count, the API returns up to 25. Queries can be up to 200 characters. Filters can include or exclude as many as 100 domains in each list, with a root domain matching its subdomains, and can restrict results to an inclusive publication-date range. AWS says each result includes a text extract and, when available, a title, URL, and publication time. Queries are served from an Amazon-operated web index inside AWS and are not sent to a third-party search engine. The API complements rather than replaces AgentCore Gateway. AWS describes Gateway as the recommended route for most agentic workloads, providing a shared MCP endpoint for web search and other tools, authentication, semantic tool selection, and optional MCP sessions. The standalone API is intended for cases where teams want to manage orchestration, retries, caching, and error handling themselves, or where search is part of a non-agent workflow such as a dashboard or fact-checking pipeline. The announcement also describes integration paths through LangChain’s AgentCore web-search toolkit, available in `langchain-aws` 1.9.3 and later, and the AgentCore Python SDK 1.26.0 and later. AWS says the API supports IAM policies, service control policies, CloudTrail data-event logging, and interface VPC endpoints through AWS PrivateLink. CloudTrail data events are not logged by default; teams must configure an event selector. AWS lists a default quota of 10 requests per second per account in each Region, with increases available on request. PrivateLink endpoints are billed at standard AWS PrivateLink rates. The announcement’s examples identify Boto3 1.43.127 or later for local Python setup. ## What the archive adds New Runtime’s earlier coverage described adding secure web search to Claude Desktop through Amazon Bedrock AgentCore ([October 2, 2026](https://newruntime.com/posts/add-secure-web-search-to-claude-desktop-with-d272d0/)) and getting started with Web Answer in AgentCore ([November 6, 2026](https://newruntime.com/posts/getting-started-with-web-answer-on-amazon-bedrock-7b64a7/)). This is a new API access path within a related AgentCore search thread, not a restatement of those guides. ## Trend signal This supports the shift toward protocol-mediated tool access, while adding a useful counterpoint: not every search integration needs a shared MCP gateway. The API offers a direct operation when teams want to own orchestration and request handling; Gateway remains AWS’s recommended path for most agentic workloads. This is relevant to [agent protocols become the interoperability layer](https://newruntime.com/patterns/agent-protocols-become-interoperability-layer/), though the announcement alone does not establish a broader market direction. ## Why now AWS frames the API around applications that need current information—such as recent events, product releases, prices, or regulations—that may postdate model training data. It also says developers need a lower-level route for custom orchestration and non-agent systems, alongside Gateway’s shared-tool approach. ## Why it matters Teams building on AWS now have a choice between a managed MCP gateway and a direct search call. The direct API can reduce integration overhead when a product already has its own orchestration layer or needs web grounding in a scheduled pipeline, dashboard, or enrichment job. Standard IAM credentials and optional PrivateLink also give platform teams familiar controls for authorizing and routing requests. The trade-off is operational ownership. A direct call leaves retries, caching, error handling, and the surrounding agent’s use of search results to the application team. Search results are inputs, not verified answers; builders still need to preserve URLs and check claims against sources. The 10-request-per-second default may also shape concurrency planning, although AWS says teams can request quota increases. Choosing the direct API is most compelling when that control is worth more than Gateway’s shared MCP endpoint and built-in tool-management features. ## Limits and uncertainty AWS describes result fields as conditional: titles, URLs, and publication times are returned when available, so builders should not assume every result carries complete metadata. The announcement gives the default throughput quota but does not establish typical latency, search coverage, ranking quality, or result freshness across topics. Those properties are not independently evaluated here. AWS says quota increases can be requested, but the announcement does not specify approval times or resulting limits. Teams should test representative queries and validate the returned source material before relying on it in user-facing answers. ## Skill to build now Take one workflow that currently uses a search endpoint or manual browsing and prototype it with `InvokeWebSearch`. Add a domain allowlist and publication-date range, then test whether the returned extracts and URLs are sufficient for the workflow’s verification step. If the application already handles tool routing, compare the direct call with Gateway on integration effort and control requirements before committing to either route. ## Reader takeaway AgentCore Web Search is now available as a direct AWS API as well as through Gateway. Use the API when you want to own the search call inside an existing application or pipeline; use Gateway when a shared MCP tool endpoint and its management features are the better fit. ## Open question How will the API’s coverage, freshness, and ranking quality compare with the search providers teams already use? Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json ## Continue in the graph Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`. - topic hub: [Agent Loops](https://newruntime.com/topics/agent-loops.md): Explore the agent-loops topic hub. - collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis. - collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites. - whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)