AWS announced on November 5, 2026 that Web Answer on Amazon Bedrock AgentCore is generally available. It is a managed tool that takes a natural-language question and returns a synthesized answer with source citations in a single tool call. In the AWS Machine Learning blog walkthrough, authors Adrianna Chudy, Gaurav Deshmukh, Kalyan Garimella, Kamrul Tarafder and Omar Abdelwahab say the point is to remove the search, retrieve, synthesize and cite pipeline that agent builders usually write themselves.
Web Answer is exposed through AgentCore Gateway as an MCP tool, so any agent that speaks MCP can call it. It launches in us-east-1 only, with a rate limit of 10 transactions per second per account. This guide covers how it works, the setup steps AWS lists, the limits, and how to choose between it and the older Web Search tool.
TL;DR #
| Question | Answer |
|---|---|
| What does it do? | Returns a cited, synthesized answer to a question in one tool call |
| How do agents call it? | Through AgentCore Gateway as an MCP tool |
| Auth | AWS IAM (SigV4) or JWT at the Gateway; no separate API key |
| Region | us-east-1 only at launch; more "coming soon" |
| Rate limit | 10 transactions per second per account (raise via AWS Support) |
| Private networking | VPC and AWS PrivateLink via an interface endpoint |
| Search index | Amazon-operated index, not third-party search engines (per AWS) |
| Price | Billable; details not visible in our fetch, check AWS pricing |
How Web Answer works #
The flow in the AWS post has five steps:
- Your agent sends a question to an AgentCore Gateway, which authenticates the call.
- The Gateway invokes Web Answer, an AWS-owned managed connector, using its own service role.
- Web Answer plans searches, runs several in parallel, reads pages to verify facts, and searches again if the evidence is thin.
- It writes an answer that links claims to source URLs.
- The Gateway returns the answer and citations to your agent as an MCP tool result.
Each run performs new searches, and the model is given the current date. That matters for questions about recent events, because the answer is not cached from an old index snapshot.
If you are new to the protocol, our MCP guide explains why one Gateway can serve many agents.
A globe with a magnifier and a result card, showing how Web Answer on Amazon Bedrock AgentCore retrieves pages
Web Answer vs Web Search: which one do you want? #
AWS launched Web Search on AgentCore in June 2026 as a built-in gateway connector. Web Answer is the next layer up.
| Web Search | Web Answer | |
|---|---|---|
| Returns | Ranked URLs, titles, snippets, metadata | A synthesized answer with inline citations |
| Who synthesizes? | Your model | The managed tool |
| Control over the prompt | Full | Limited to the question and filters |
| Best for | Custom ranking, multi-source pipelines, your own reasoning | Factual sub-tasks inside a larger agent |
AWS says many customers will use both: Web Search when you want raw sources to reason over, Web Answer when you just need a checked fact with a citation. The trade-off is control. With Web Answer you accept AWS's retrieval plan and its synthesis model.
Why a managed answer tool instead of building your own? #
Most teams that add web grounding to an agent end up writing the same four pieces: a search API client, a page fetcher and cleaner, a prompt that merges the evidence, and a citation formatter. Each piece needs tests, retries, rate-limit handling and a security review. When the search provider changes its terms or format, the pipeline breaks.
A managed tool moves that work to the cloud provider. You pay per invocation and give up some control, but you also get one audit surface: the Gateway logs the call, IAM decides who may make it, and CloudWatch shows the volume. For regulated teams, that single control point is often the real benefit, more than the answer quality itself.
The cost of that choice is lock-in. A tool name like web-answer-tool___WebAnswer and an AWS-only ARN tie your agent to AgentCore Gateway. Because the interface is MCP, swapping in another MCP search tool later is possible, but the IAM policies, filters and monitoring would need to be rebuilt.
Setup: three steps from the AWS walkthrough #
Prerequisites: an AgentCore Gateway in us-east-1 with AWS_IAM inbound auth, credentials with bedrock-agentcore:InvokeGateway, model access in Amazon Bedrock, and Python 3.10 or newer with boto3, strands-agents, mcp and mcp-proxy-for-aws.
Step 1: grant the Gateway role permission
Add an inline policy to the Gateway service role that allows bedrock-agentcore:InvokeWebAnswer on this resource:
arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-answer.v1
AWS says the role does not need bedrock:InvokeModel, because the model runs inside the managed connector.
Step 2: create the Gateway target
Call create_gateway_target with connectorId set to web-answer and GATEWAY_IAM_ROLE credentials. Wait until the target status reaches READY. An administrator can also set a domain include or exclude filter at this point.
Step 3: call it from an agent
Connect a Strands agent to the Gateway over MCP, list the tools and ask a question. The tool appears as web-answer-tool___WebAnswer. Agents can pass optional arguments: domain filters, a published-date range and a country. One rule is worth noting: an agent can narrow the target's domain filter but cannot widen it. That keeps an administrator's allow-list in force even if a prompt tries to bypass it.
When you finish testing, delete the target, then the Gateway if you created it only for the walkthrough, then the role policy and role.
For another agent pattern on the same stack, see our guide to agentic retrieval on Bedrock managed knowledge bases through AgentCore Gateway.
What the response looks like #
The tool result contains a markdown content block with inline citation markers. It also carries structuredContent.answer, which holds the same text plus a list of citations (domain and URL), along with isError and _meta.latencyMs.
That structure is useful for builders. You can render the citations in your UI, log latency per call, and check isError before you trust the text. Build one rule into your agent: if the citation list is empty, treat the answer as unverified and say so to the user.
Enterprise controls and limits #
AWS lists these controls in the post:
- Authentication at the Gateway with IAM SigV4 or JWT, so no separate API key to rotate.
- Network privacy through VPC and AWS PrivateLink with an interface endpoint.
- Data handling: queries and results stay within the AWS environment, and AWS says it uses an Amazon-operated index instead of third-party search engines.
- Observability: CloudWatch metrics from the first call.
- Domain bounds set by administrators.
- Rate limit: 10 transactions per second per account in us-east-1.
The limits matter more than the features for planning. One Region and 10 transactions per second suit internal copilots and research assistants. A consumer app with bursty traffic will need a quota increase first. Also check pricing: the post says Gateway and Web Answer invocations are billable, and the pricing section was not readable in our fetch, so we cannot quote a number.
Use cases AWS names, and where it is a poor fit #
AWS suggests regulatory Q&A in financial services, clinical support, customer service, legal and compliance research, and internal enterprise copilots. These are all cases where a source link matters as much as the answer.
It is a weaker fit when:
- You need to rank or filter sources with your own logic. Use Web Search.
- You need results from private documents. Use a knowledge base, such as in our Bedrock knowledge base guide .
- You must run outside us-east-1 today.
- You require auditable control of the model and prompt used for synthesis.
How to check the answers (what AWS does not promise) #
A cited answer is not a verified answer. The AWS post describes the retrieval process, but this launch post does not publish accuracy benchmarks, so we cannot say how often Web Answer is right. Treat these as your own tests:
- Ask 20 questions where you know the answer, including recent ones.
- Open the cited URLs and confirm each claim appears there.
- Test a question with no good answer and see whether the tool says so.
- Try a restricted domain filter and confirm results stay inside it.
- Measure
_meta.latencyMsacross calls and set a timeout in your agent.
Related research on how agents find tools and data is covered in our post on Apple's study of plan-or-retrieve tool discovery.
Where this fits in the AgentCore stack #
AgentCore keeps growing by adding managed pieces: Gateway for tools, evaluations for quality and now two web tools. If you already use it, see how teams test decisions in our post on AgentCore evaluations with decision models, and how one team built a multimodal embeddings agent with AgentCore and Strands.
Agents that read the open web also face prompt injection from the pages they read. A managed tool narrows your code surface, but it does not remove that risk. AgentBeam, from the explainx.ai team, is an agent security platform that stops AI agents before they take dangerous actions, which is a useful layer on top of any web-reading tool.
Bottom line #
Web Answer is a convenience tool: one call, one cited answer, IAM auth and PrivateLink, in one Region with a 10 TPS cap. If your agent needs facts from the web and you would rather not run a retrieval loop, it is a short path. If you need control, raw sources or other Regions, stay with Web Search or your own pipeline, and test the answers before you ship.
Related reading #
Details come from the AWS Machine Learning blog post of November 5, 2026 and may change; the pricing section was not readable when we fetched it.