AWS now sells web research as one tool call. Your agent gets an answer and someone else's reading of sources
Web Answer on Bedrock AgentCore is GA: it searches an Amazon-operated index, reads pages and returns a cited answer for US$10 per 1,000 calls. When raw results are safer.
Listen to this article · 4 min
AI-generated narration of the full article.
When an agent needs something from the web, someone has to read the pages. Until now, that was usually the agent’s own model: a search tool returned links and snippets, and the model decided what they meant. AWS now offers to do the reading for it.
Web Answer, generally available on Amazon Bedrock AgentCore, takes a question in natural language and returns a synthesized answer with citations, through a single MCP tool call. Behind that call, it plans searches, runs several in parallel, reads pages to check facts and searches again if the evidence is thin.
The details that matter
Web Answer is a managed connector owned by AWS and attached to an AgentCore Gateway. The answer comes back as Markdown with inline citation markers, plus structured citations with URL and domain. Calls can be narrowed by domain, by publication date range and by country. Administrators set domain bounds on the gateway target, and an agent can narrow them per call but never widen them.
Two facts stand out for enterprises. First, it searches an Amazon-operated web index and knowledge graph, and AWS says it does not send queries to third-party search engines or external websites. Second, it supports IAM or JWT authentication at the gateway, private connectivity through PrivateLink, and CloudWatch metrics.
At launch it costs US$10 per 1,000 tool calls, runs only in US East (N. Virginia), and has a default limit of 10 transactions per second per account. In AWS’s example, one answer took a little over five seconds.
Answer or results?
AWS still offers Web Search, which returns ranked results and leaves synthesis to the caller. The choice between them is an architecture decision.
| Web Search | Web Answer | |
|---|---|---|
| What the agent receives | Ranked links, titles and snippets | A written answer with citations |
| Who interprets the sources | Your agent's model | AWS's service, then your model |
| Tokens your model spends | More: it reads the results | Fewer: it reads one answer |
| Where errors hide | In your model's reading | In a synthesis you did not see happen |
| Best for | Decisions that need the evidence itself | Quick facts, orientation, current events |
The central trade-off is that Web Answer adds a second model between your agent and the evidence. Its synthesis may be good, but your agent inherits its omissions and misreadings as facts, and the citations show where the answer came from without showing what was left out. For a customer service agent checking a carrier’s posted delivery times, that is fine. For a compliance agent reading a regulator’s new guidance, the agent should read the regulator’s page itself, as we argued in our piece on citing a versioned rule instead of reinterpreting it.
Custody of the questions
The privacy angle is easy to miss. The questions an agent asks the web reveal what the company is working on: a target in an acquisition, a supplier under review, a symptom in a product recall. A service that keeps those queries inside one provider’s index, without passing them to outside search engines, has a real custody advantage over tools that relay queries to third parties. It is the same question we raised about DeepSeek’s search API and who sees the queries.
A short policy
- Use Web Answer for orientation and low-stakes facts, with domain bounds set by administrators.
- Use raw search plus your own model, or direct retrieval from the source, when the answer will support a decision someone signs.
- Log the question, the answer and the citations together, because “the agent said so” is not a source.
- Treat the US East-only availability as a data residency question before it is a latency one, especially for teams outside the United States.