AWS Bedrock AgentCore's Web Search Tool Changes What Agents Can Reach

Most AI agents built today hit the same wall: they can reason over private data just fine, but the moment you ask them to pull something from the live web, you're duct-taping a scraper, a search API, and a proxy together — then praying your API key doesn't leak.

AWS changed that in June 2026.

AgentCore Web Search, now generally available as part of the Bedrock AgentCore platform, gives any AI agent the ability to search the live web through a fully managed, MCP-compliant tool. No scrapers. No third-party API keys floating around in environment variables. No data leaving the AWS boundary.

This isn't a minor feature addition. It's a structural shift in how agents interact with the public internet, and it matters for every engineering team building agentic systems in 2026.

Let's break down exactly what changed, why it matters, and how to use it.

What AgentCore Web Search Actually Is

AgentCore Web Search is a fully managed tool that agents invoke the same way they invoke any other tool in the AgentCore runtime — through the MCP (Model Context Protocol) tools/list and tools/call interface.

When an agent needs current information — a stock price, a news article, a technical documentation page — it calls the Web Search tool with a query. Amazon's infrastructure handles the rest: query expansion, index lookup, snippet extraction, and result delivery.

The critical details:

• Backed by Amazon's own web index — tens of billions of documents, not a proxy to Google or Bing
• MCP-compliant — works with any MCP-compatible agent framework (Strands, LangChain, LangGraph, CrewAI, or custom stacks)
• Zero data egress — queries never leave the AWS network boundary
• Fully managed — no infrastructure to provision, scale, or maintain
• Pay-as-you-go — $7 per 1,000 queries

This is the same search infrastructure that powers Alexa+, Amazon Q Business, and Kiro. Amazon isn't reselling someone else's index. They built their own, and now they're exposing it as a tool for agent developers.

How It Differs From Bedrock Knowledge Bases

If you're already using Bedrock Knowledge Bases to ground your agents in private documents, you're probably wondering how this fits alongside that.

The distinction is clean:

• Knowledge Bases → private data you own (PDFs, wikis, databases, S3 objects)
• AgentCore Web Search → public web data you don't own (anything indexed on the internet)

They're complementary. An agent can use Knowledge Bases for internal policy documents and Web Search for current market data, competitor pricing, or technical documentation — all within the same turn.

The Architecture: How Web Search Works Under the Hood

Understanding the architecture helps you make better decisions about when and how to use this tool.

Query Processing Pipeline

When an agent invokes Web Search, the request flows through several stages:

1. Query Normalization

The raw query string is cleaned, encoded, and validated against the 200-character maximum. Amazon's infrastructure applies query expansion — adding synonyms, handling abbreviations, and disambiguating intent — before hitting the index.

2. Index Lookup

The query hits Amazon's web index, which contains tens of billions of documents. This isn't a crawl-and-cache model. It's a living index with continuous refresh cycles, meaning results reflect recently published or updated content.

3. Multi-Source Grounding

Results are enriched from two sources simultaneously:

• The web index (standard web pages, articles, documentation)
• The Amazon Knowledge Graph (structured entity data — company names, product information, factual relationships)

This dual-source approach means a query like "AWS Lambda pricing" gets both the official pricing page and structured pricing data from the Knowledge Graph, giving the agent richer context to reason over.

4. Semantic Snippet Extraction

This is a key differentiator. Instead of returning raw HTML or full page dumps, the system extracts semantically relevant snippets — the specific passages that answer or relate to the query.

For agents, this matters enormously. Raw HTML is noise. A 200-character snippet that directly addresses the query is signal. This reduces token consumption downstream and improves the quality of the agent's reasoning.

5. Result Delivery

Results return as structured JSON with title, URL, snippet, and relevance metadata. The agent receives clean, parseable data it can immediately use in its reasoning chain.

MCP Interface

The tool exposes a standard MCP interface:

• tools/list — discover the Web Search tool and its schema
• tools/call — invoke search with parameters (query, max results, domain filters, date filters)

This means the tool is framework-agnostic. If your agent stack speaks MCP, it can use Web Search without any adapter code.

The Privacy Model: Why Zero Data Egress Matters

This is where AgentCore Web Search creates a genuine moat for enterprise adoption.

The Problem With Third-Party Search APIs

When you use Google Custom Search, SerpAPI, Tavily, or any external search API, every query you send contains context about what your agent is looking for — which reveals what your agent is building, what problems it's solving, and what information your business needs.

For a customer service agent resolving billing disputes, every query is a signal about your customer base. For a financial analysis agent, every query reveals your investment thesis. For a healthcare agent, queries might contain patterns that map to patient conditions.

Third-party search APIs require your data to leave your infrastructure, transit the public internet, and arrive at someone else's servers. Even with TLS encryption, you're trusting that third party with your query patterns.

AgentCore's Zero Egress Model

AgentCore Web Search operates entirely within the AWS network boundary. Your queries never leave AWS infrastructure. There's no external API call, no third-party data processing, no external logging of your query patterns.

For Indian enterprises subject to RBI data localization guidelines or organizations with strict data residency requirements, this isn't a nice-to-have. It's a prerequisite.

The regional availability reflects this: us-east-1, eu-west-1, and ap-northeast-1 — all regions where AWS maintains the web index infrastructure natively.

Layered Governance

The governance model adds another layer of control:

Admin-level domain policies — Platform administrators set blanket rules about which domains agents can or cannot search. Block competitors' internal wikis. Whitelist only official documentation sites. Enforce organization-wide data access policies.

Runtime filters — Individual queries or agent sessions can apply additional domain and date filters on top of admin policies. An agent building a report on Q3 2026 earnings can filter to publishedDate after 2026-07-01 and exclude certain domains — without modifying the underlying admin policy.

This two-tier governance model (admin policies + runtime filters) means centralized control with operational flexibility.

Setting Up AgentCore Web Search: Step by Step

Let's walk through the actual setup. This is practical, copy-paste-ready guidance.

Prerequisites

• An AWS account with Bedrock access enabled in your target region
• Python 3.10+ with the strands-agents and strands-agents-tools SDKs installed (or your preferred MCP-compatible framework)
• Appropriate IAM permissions

Step 1: Install the SDK

pip install strands-agents strands-agents-tools

If you're using LangChain or another framework, install the appropriate MCP client library. The Web Search tool is MCP-compliant, so any MCP client works.

Step 2: Configure IAM Permissions

Your agent's execution role needs permission to invoke the Web Search tool through Bedrock:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeAgent",
        "bedrock:InvokeAgentCoreTool"
      ],
      "Resource": "arn:aws:bedrock:us-east-1:123456789012:agent/*"
    }
  ]
}

The bedrock:InvokeAgentCoreTool permission is what grants access to the managed Web Search tool specifically. Without it, the agent can call other tools but not Web Search.

For finer-grained control, you can scope the resource ARN to a specific agent:

{
  "Effect": "Allow",
  "Action": [
    "bedrock:InvokeAgentCoreTool"
  ],
  "Resource": "arn:aws:bedrock:us-east-1:123456789012:agent/my-research-agent"
}

Step 3: Agent Code (Strands SDK)

Here's a minimal working example using the Strands SDK:

from strands import Agent
from strands.tools.mcp import MCPClient

# Connect to the AgentCore runtime
mcp_client = MCPClient(
    url="https://bedrock-runtime.us-east-1.amazonaws.com/agentcore/mcp"
)

# Create an agent with Web Search enabled
agent = Agent(
    model="anthropic.claude-sonnet-4-20250514-v1:0",
    tools=[mcp_client],
    system_prompt="""You are a research assistant. Use Web Search
    to find current, accurate information. Always cite your sources
    by returning the URLs from search results."""
)

# The agent can now search the web
response = agent("What are the latest changes to AWS Lambda
cold start times in 2026?")
print(response)

When the agent receives a task that requires current information, it will:

1. Call tools/list to discover the Web Search tool
2. Call tools/call with the appropriate query
3. Receive structured search results
4. Use those results to formulate its response

Step 4: Direct MCP Tool Call

If you want to invoke Web Search directly (outside of agent reasoning), here's the tools/call payload:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "WebSearch",
    "arguments": {
      "query": "AWS re:Invent 2026 keynotes summary",
      "maxResults": 10,
      "domainFilter": {
        "include": ["aws.amazon.com", "theverge.com", "techcrunch.com"]
      },
      "publishedDateFilter": {
        "after": "2026-01-01T00:00:00Z"
      }
    }
  },
  "id": "search-001"
}

The response comes back as structured JSON with results containing title, url, snippet, and publishedDate fields — clean data your agent can reason over immediately.

Step 5: Connect to LangChain (Alternative)

If your stack uses LangChain rather than Strands:

from langchain_community.tools import MCPTool
from langchain.agents import create_openai_tools_agent

# Configure MCP connection to AgentCore
mcp_tool = MCPTool(
    server_url="https://bedrock-runtime.us-east-1.amazonaws.com/agentcore/mcp",
    tool_name="WebSearch"
)

# Use as any LangChain tool
agent = create_openai_tools_agent(
    llm=your_llm,
    tools=[mcp_tool],
    prompt=your_prompt
)

The MCP abstraction means the tool works identically regardless of which framework wraps it.

Domain Filtering: Precision Control Over What Agents Access

The connector version 1.2.0 (released alongside GA) added domain filtering and published-date filtering — two features that transform Web Search from a blunt instrument into a precision tool.

Domain Include Lists

Restrict searches to specific domains. If your agent only needs official documentation:

{
  "domainFilter": {
    "include": [
      "docs.python.org",
      "docs.aws.amazon.com",
      "developer.mozilla.org"
    ]
  }
}

The agent won't waste queries on Stack Overflow answers from 2019 or Medium blog posts that may be outdated. It searches only the domains you've approved.

Domain Exclude Lists

Block specific domains from appearing in results. Common use cases:

• Exclude competitor sites from competitive research
• Block low-quality content farms
• Remove paywalled sites that would return useless snippets

{
  "domainFilter": {
    "exclude": [
      "example-competitor.com",
      "contentfarm-site.com"
    ]
  }
}

Both lists support up to 100 domains each, giving you substantial control without becoming unmanageable.

Published-Date Filtering

Use ISO-8601 UTC timestamps to bound results by publication date:

{
  "publishedDateFilter": {
    "after": "2026-01-01T00:00:00Z",
    "before": "2026-06-30T23:59:59Z"
  }
}

This is critical for time-sensitive research. An agent analyzing Q2 2026 market trends shouldn't surface results from 2023. Published-date filtering ensures temporal relevance without post-processing.

Combining Filters

Filters compose cleanly. An agent building a quarterly report can combine domain restrictions with date bounds:

{
  "query": "AI startup funding rounds",
  "maxResults": 15,
  "domainFilter": {
    "include": ["techcrunch.com", "crunchbase.com", "bloomberg.com"]
  },
  "publishedDateFilter": {
    "after": "2026-04-01T00:00:00Z",
    "before": "2026-06-30T23:59:59Z"
  }
}

Query parameters are straightforward:

Use Cases: Where AgentCore Web Search Creates Value

The tool's value depends on your agent architecture. Here are the use cases where we see the highest impact.

1. Real-Time Market Intelligence Agents

Financial analysis agents that need current market data, earnings reports, and analyst commentary. Instead of maintaining a custom scraper or paying for expensive financial data APIs, the agent queries the web directly with domain filters locked to trusted financial sources.

2. Technical Research Agents

Agents that help developers find current documentation, library versions, and best practices. A coding assistant agent can search official documentation sites with include-list filtering, avoiding outdated blog posts and unreliable third-party tutorials.

3. Compliance and Regulatory Monitoring

Agents that track regulatory changes across jurisdictions. Published-date filtering ensures agents only surface recent regulatory updates. Domain filtering restricts results to official government and regulatory body websites.

4. Customer-Facing Research Assistants

Chatbots and virtual assistants that need to answer questions requiring current public information — product availability, pricing, service status. The zero-egress model means customer query patterns never leave your AWS infrastructure.

5. Competitive Intelligence Automation

Agents that monitor competitor product pages, pricing changes, and press releases. Domain exclude lists prevent the agent from surfacing your own marketing materials, while include lists keep focus on specific competitors.

6. Indian Enterprise Use Cases

For Indian enterprises, several scenarios stand out:

• Banking agents tracking RBI circulars and regulatory updates (domain-filtered to rbi.org.in and official banking sources)
• IT services firms monitoring global technology trends for client proposals
• E-commerce platforms tracking competitor pricing across specific product categories
• Healthcare organizations searching for current clinical guidelines and drug interaction data from authoritative medical sources

The ap-northeast-1 regional availability, combined with zero data egress, makes this viable for Indian enterprises with data residency requirements.

AgentCore Web Search vs. Alternatives: A Comparison

How does AgentCore Web Search stack up against the tools most teams are currently using?

Key Takeaways From the Comparison

AgentCore Web Search wins on governance and data sovereignty. If your agents operate in regulated environments, the zero-egress model and layered governance (admin policies + runtime filters) are unmatched.

Google Custom Search is cheaper per query but requires external data transfer and lacks MCP compliance. For agents that don't need MCP integration and don't have strict data residency requirements, it remains viable.

SerpAPI offers the broadest feature set but at higher price points and with inherent scraping fragility. It's not a managed tool — it's a SaaS wrapper around search engine scraping.

Tavily is purpose-built for AI agents and offers good snippet quality, but it's an external dependency. Your query data leaves your infrastructure and arrives at Tavily's servers.

AgentCore Web Search is the only option that keeps everything inside AWS. For enterprise teams building agents on Bedrock, this eliminates an entire category of compliance and security concerns.

Cost Analysis: What AgentCore Web Search Actually Costs

Let's do the math for real-world usage patterns.

Pricing Structure

• $7 per 1,000 queries (pay-as-you-go)
• No minimum commitment
• No infrastructure costs (fully managed)
• No egress fees (queries stay within AWS)

Scenario Modeling

Small-scale agent (internal tool):

• 500 queries/day × 30 days = 15,000 queries/month
• Cost: $105/month
• Infrastructure overhead: $0 (no servers, no proxies)

Medium-scale agent (customer-facing chatbot):

• 5,000 queries/day × 30 days = 150,000 queries/month
• Cost: $1,050/month
• Compare to Tavily at similar volume: ~$750/month (but with external data egress)

Large-scale agent (automated research pipeline):

• 50,000 queries/day × 30 days = 1,500,000 queries/month
• Cost: $10,500/month
• Compare to SerpAPI Business plan: $500/month (but with rate limits, no governance, external dependency)

The Hidden Cost Equation

The sticker price doesn't tell the full story. Factor in what you're not paying for:

• No scraper maintenance — custom search scrapers break constantly as search engines change their HTML
• No proxy infrastructure — no rotating proxy costs, no IP management
• No API key management — no rotation, no leak detection, no third-party billing
• No compliance overhead — no data transfer agreements, no external vendor security reviews
• No infrastructure scaling — the tool scales automatically with demand

For teams currently maintaining their own search infrastructure, AgentCore Web Search often represents a net cost reduction when you account for engineering time and operational overhead.

Impact for Indian Enterprises

The Indian enterprise landscape has specific considerations that make AgentCore Web Search particularly relevant.

Data Residency Compliance

India's data protection framework, including the Digital Personal Data Protection Act 2023, increasingly emphasizes data localization. While web search queries might seem innocuous, the patterns of those queries can reveal sensitive business intelligence.

AgentCore Web Search's zero-egress model means query patterns remain within AWS infrastructure. For Indian banks, healthcare providers, and government contractors, this eliminates a compliance friction point that has historically required expensive custom solutions.

Cost Efficiency in INR

At $7 per 1,000 queries (approximately ₹588 at current exchange rates), AgentCore Web Search is competitively priced for the Indian market. For a mid-size Indian enterprise running a customer-facing agent with 5,000 queries/day, the monthly cost is approximately ₹51,800 — less than the salary of a single junior developer maintaining a custom search integration.

Regional Availability

The ap-northeast-1 region availability ensures low-latency access for Indian enterprises, particularly those with multi-region AWS deployments. While ap-south-1 (Mumbai) isn't listed yet for the web index, ap-northeast-1 (Tokyo) provides reasonable latency for most Indian use cases.

Integration With Indian Tech Stacks

Indian enterprises increasingly build on AWS. AgentCore Web Search integrates natively with the Bedrock agent ecosystem, meaning teams already using Bedrock for LLM inference can add web search capabilities without introducing new vendors or infrastructure.

This is particularly relevant for Indian IT services companies building AI solutions for global clients — the zero-egress model satisfies clients' data sovereignty requirements while keeping the solution architecturally clean.

Building Production Agents With Web Search: Best Practices

Based on real-world implementations, here are the patterns that work.

Pattern 1: Graduated Search Strategy

Don't search the web for everything. Implement a search hierarchy:

1. Check private knowledge first — Knowledge Bases, internal APIs, cached data
2. Search the web only when private sources are insufficient — use the agent's judgment or a confidence threshold
3. Apply maximum filtering — domain includes + date filters to minimize query waste

This reduces costs and ensures the agent doesn't search the web for information it already has.

Pattern 2: Domain Allowlisting by Agent Role

Different agents should search different parts of the web:

• Technical support agent → documentation sites only (docs.python.org, developer.mozilla.org, docs.aws.amazon.com)
• Market research agent → industry publications, analyst sites
• Customer service agent → official product pages, status pages, knowledge bases

Implement this through admin-level domain policies rather than per-query filters. Set it once, enforce it globally.

Pattern 3: Caching for Repeated Queries

If multiple agents or users ask the same question within a short window, cache the results. Web search results don't change by the second. A 5-minute cache TTL for most queries can reduce costs by 30-50% without meaningfully impacting freshness.

Pattern 4: Query Optimization

The 200-character query limit forces disciplined query writing. Train your agents to:

• Be specific, not verbose: "AWS Lambda cold start Java 17 2026" instead of "What are the current cold start times for Java 17 runtimes on AWS Lambda in 2026"
• Use domain filters to narrow scope rather than adding more query terms
• Leverage date filters to avoid retrieving outdated results that the agent then has to discard

Pattern 5: Monitoring and Cost Controls

Set up CloudWatch alarms on query volume. Unexpected spikes in web search usage might indicate:

• An agent stuck in a search loop (querying repeatedly without finding useful results)
• A new agent deployed without proper domain filtering (searching the entire web for queries that should hit private knowledge)
• A user-facing agent with unexpected traffic volume

The MCP Compliance Advantage

It's worth emphasizing why MCP compliance matters beyond technical convenience.

MCP (Model Context Protocol) is becoming the standard interface for tool integration in agent systems. By building Web Search as a native MCP tool, Amazon ensures it works with:

• Strands Agents — AWS's own agent framework
• LangChain / LangGraph — the most popular open-source agent frameworks
• CrewAI — multi-agent orchestration framework
• Any custom framework that implements the MCP client protocol

This means teams aren't locked into a specific framework to use Web Search. You can start with Strands, migrate to LangGraph, or build a custom framework — the tool interface stays the same.

For Indian enterprises evaluating agent frameworks, this flexibility is valuable. Your tool investments survive framework transitions.

Limitations and Considerations

No tool is perfect. Here are the honest limitations:

Query Length Constraint

The 200-character maximum is tight. Complex research queries may need to be broken into multiple simpler queries, which increases cost and latency. Teams should build query decomposition into their agent logic.

Result Volume

The 1-25 result range (default 10) is sufficient for most use cases but may be limiting for research agents that need broad survey coverage. You can work around this by running multiple queries with different angles on the same topic.

Regional Availability

Three regions (us-east-1, eu-west-1, ap-northeast-1) cover major markets, but teams in ap-south-1 (Mumbai) or other regions will experience slightly higher latency. Not a dealbreaker, but worth noting for latency-sensitive applications.

No Custom Indexing

Unlike Knowledge Bases, you can't add your own documents to the web search index. If you need agents to search both public web data and private documents, you need to use Web Search and Knowledge Bases as complementary tools in the same agent.

Pricing at Scale

At very high volumes (millions of queries per month), the $7/1K pricing may be higher than what you'd pay for a self-hosted search solution. However, when you factor in infrastructure costs and engineering time, the break-even point is typically well above what most teams actually need.

What This Means for Agent Architecture in 2026

AgentCore Web Search is a signal about where the industry is heading.

The era of agents that only reason over static, private datasets is ending. Agents need live web access to be useful in most real-world scenarios. The question isn't whether your agents will search the web — it's how they'll do it while maintaining governance, privacy, and cost control.

AWS's approach — native MCP integration, zero data egress, managed infrastructure — sets a template that other cloud providers will likely follow. Building your agent architecture on MCP-compliant tool interfaces from the start positions you to adapt as this space evolves.

For teams currently duct-taping search APIs into their agent stacks, AgentCore Web Search is an opportunity to eliminate a category of technical debt. For teams building new agent systems, it's a reason to consider the Bedrock ecosystem more seriously.

MojoStudio's Take

We build AI agents for enterprises that need them to work in production — not just demo well. The search problem has been one of the most persistent pain points in every agent we've deployed.

AgentCore Web Search solves the infrastructure side cleanly. The remaining challenge is the intelligence side: teaching agents when to search, what to search for, how to filter results, and when to trust their existing knowledge instead of querying the web.

That's where thoughtful agent design matters. The tool is only as good as the strategy behind it.

If you're building agents that need live web access — whether for customer-facing applications, internal research automation, or compliance monitoring — and you need to do it within an enterprise-grade governance framework, AgentCore Web Search is worth evaluating.

For teams looking for guidance on integrating this into production agent architectures, our engineering team has hands-on experience building on the Bedrock platform and can help you design the right search strategy for your use case.

If you're evaluating agent frameworks and need a broader perspective on the landscape, our Flutter vs React Native 2026 comparison might seem unrelated — but the framework selection principles we outline there (platform maturity, ecosystem lock-in, long-term maintainability) apply equally to agent framework choices.

The bottom line: agents that can search the web are more useful than agents that can't. AgentCore Web Search makes that capability available without compromising on the governance and privacy requirements that enterprise deployments demand.

Frequently Asked Questions

What is AWS AgentCore Web Search?

AWS AgentCore Web Search is a fully managed tool within the Bedrock AgentCore platform that gives AI agents the ability to search the live web. It's backed by Amazon's own web index containing tens of billions of documents and is fully compliant with the Model Context Protocol (MCP). Agents invoke it through the standard MCP tools/list and tools/call interface, making it framework-agnostic. The service costs $7 per 1,000 queries on a pay-as-you-go basis, requires zero infrastructure management, and ensures all queries remain within the AWS network boundary — no data leaves AWS infrastructure. It's designed as a complement to Bedrock Knowledge Bases, which handles private data, while Web Search handles public web data.

How does AgentCore Web Search differ from Google Custom Search API?

The primary differences are data sovereignty, MCP compliance, and governance. AgentCore Web Search keeps all queries within the AWS network — your query data never reaches Google's servers. Google Custom Search requires external data transfer. AgentCore is natively MCP-compliant, meaning it integrates directly with agent frameworks like Strands, LangChain, and CrewAI. Google Custom Search is a REST API that requires custom integration code. AgentCore also provides layered governance with admin-level domain policies and runtime filters, while Google Custom Search offers limited site restriction (10 sites maximum). Pricing is comparable ($7/1K vs $5/1K), but AgentCore eliminates the infrastructure overhead of managing external API integrations and compliance requirements.

Is AgentCore Web Search available in India?

AgentCore Web Search is available in three AWS regions: us-east-1 (N. Virginia), eu-west-1 (Ireland), and ap-northeast-1 (Tokyo). While ap-south-1 (Mumbai) is not currently listed, ap-northeast-1 provides reasonable latency for Indian enterprises. The zero-data-egress model is particularly relevant for Indian organizations subject to data localization requirements under India's Digital Personal Data Protection Act 2023 and RBI guidelines for financial institutions. All queries remain within AWS infrastructure regardless of which region you use, satisfying most data residency requirements without needing custom compliance solutions.

Can I use AgentCore Web Search with LangChain or only with Strands?

You can use AgentCore Web Search with any MCP-compatible framework, including LangChain, LangGraph, CrewAI, and custom agent stacks. The tool exposes a standard MCP interface (tools/list for discovery, tools/call for invocation), so any framework that implements the MCP client protocol can connect to it. The Strands SDK provides the most direct integration since both are AWS-native, but LangChain and other frameworks work through their respective MCP client libraries. The tool behaves identically regardless of which framework wraps the MCP calls — the protocol abstraction ensures consistent behavior across all supported frameworks.

What are the domain filtering capabilities?

Domain filtering, introduced in connector version 1.2.0, supports both include and exclude lists with up to 100 domains each. Include lists restrict searches to only the specified domains — useful for ensuring agents only search trusted sources like official documentation. Exclude lists prevent specific domains from appearing in results — useful for blocking competitors, content farms, or paywalled sites. Filters can be applied at the admin level (organization-wide policy) or at runtime (per-query or per-session), creating a two-tier governance model. Admin policies set the boundaries; runtime filters provide operational flexibility within those boundaries. Both filter types can be combined with published-date filtering for precise result control.

How does the published-date filter work?

The published-date filter accepts ISO-8601 UTC timestamps as lower (after) and upper (before) bounds. Results are limited to pages published within the specified time window. For example, setting after to 2026-01-01T00:00:00Z and before to 2026-06-30T23:59:59Z returns only results from the first half of 2026. This is critical for time-sensitive research — financial analysis, regulatory monitoring, trend analysis — where outdated information is worse than no information. The filter operates at the index level, not as post-processing, so it reduces query cost by avoiding the retrieval of irrelevant results. You can use date filtering independently or combine it with domain filtering for maximum precision.

What is the maximum query length and result count?

Queries are limited to 200 characters maximum. Results can be configured from 1 to 25, with a default of 10. The 200-character limit encourages concise, specific queries — which actually improves result quality. Teams building agents should implement query decomposition logic for complex research topics, breaking them into multiple focused queries rather than trying to cram everything into a single search. The 1-25 result range covers most use cases; for research agents needing broader coverage, running multiple queries with different angles on the same topic effectively extends the result set beyond the per-query limit.

How does pricing compare to building custom search infrastructure?

At $7 per 1,000 queries, AgentCore Web Search appears competitive on sticker price alone. The real cost advantage comes from eliminating supporting infrastructure: custom scraper maintenance, rotating proxies, IP management, API key rotation, third-party security reviews, and compliance documentation. For teams currently maintaining custom search scrapers, the engineering time savings often exceed the direct tool cost. For teams using third-party APIs like SerpAPI ($50-500/month) or Tavily, AgentCore provides comparable functionality with the added benefit of zero data egress. At scale (1M+ queries/month), self-hosted solutions may become cheaper on raw compute, but when factoring in engineering overhead and reliability, the break-even point is typically well above what most teams actually need.

Does AgentCore Web Search support multi-source grounding?

Yes. Results are enriched from two sources simultaneously: Amazon's web index (containing billions of web pages, articles, and documentation) and the Amazon Knowledge Graph (providing structured entity data for factual queries). This dual-source approach means queries like product pricing or company information return both web page results and structured data, giving agents richer context for reasoning. Additionally, results are delivered as semantic snippets — extracted passages that directly address the query — rather than raw HTML or full page dumps. This reduces token consumption in downstream LLM processing and improves the quality of agent reasoning by eliminating noise from irrelevant page sections.