Getting started with Web Answer on Amazon Bedrock AgentCore

Today, we are announcing the general availability of Web Answer on Amazon Bedrock AgentCore. With Web Answer, agent builders get a synthesized, source-cited answer to a natural-language question with a single tool call. They no longer build a search, retrieve, synthesize, and citation pipeline themselves. If you have built agents that need to answer questions from current web sources, you know the pattern: call a search API, decide which results to trust, retrieve and clean page content, prompt a model to synthesize, and engineer citation extraction so the output traces back to a source. Every step is code you maintain, and every step is another place things can go wrong: hallucination when evidence is insufficient, stale content when the index moves, and broken attribution when a claim and its source drift apart. The Web Answer collapses that entire pipeline into one request. You send a question. You get back a cited answer in seconds. In this post, we explain what Web Answer does, compare it with Web Search on AgentCore, show how it works and what it returns, and walk through adding Web Answer to a gateway and calling it from an agent. What Web Answer does Figure 1: Request flow from an agent through the Gateway to Web Answer and back Your agent sends a question to your AgentCore Gateway, a capability of Amazon Bedrock AgentCore. The Gateway authenticates the call with AWS Identity and Access Management (AWS IAM) or a JSON Web Token (JWT). The Gateway calls Web Answer, a managed connector that AWS owns, using its own service role. Web Answer plans its searches, runs several in parallel, and reads key pages to check the facts. When the evidence is insufficient, it searches again. It then writes an answer that ties each claim to its source URL. The Gateway returns the answer and its citations to your agent as a Model Context Protocol (MCP) tool result. Web Answer is a managed AgentCore Gateway tool that takes a natural-language question and returns a synthesized answer in seconds grounded in current web sources. Here is what you get back: A grounded, cited answer, where each grounded claim maps to a citation, with a source URL where one is available. Current sources. Web Answer runs new searches for every question, and its model is given today’s date so it can search for up-to-date information. Agentic search: Web Answer plans its own searches, runs several in parallel, reads pages to verify facts, and decides when it has enough evidence to answer. Responsible AI safeguards: Web Answer is designed and tested with responsible AI safeguards. Figure 2: Demo video showing how to add Web Answer to an AgentCore Gateway, from setup to a finished, cited answer How it differs from Web Search Web Answer and the Web Search tools both support retrieval use cases, with different levels of integration complexity. The dividing line is who runs the model: Web Search: Returns ranked URLs, titles, snippets, and metadata. You keep your own model and control the synthesis. Use Web Search when you want full control over how results are processed. Web Answer: Runs the model, the agentic retrieval loop, synthesis, and attribution for you. You get a finished, cited answer. Use Web Answer when the question is a sub-task inside a larger agent and you do not want to own a retrieval pipeline for it. Many customers will use both. An agent might use Web Search for broad research tasks where it needs raw results, and Web Answer for specific factual questions where it needs a quick, cited answer. Set up and invoke Web Answer Web Answer is a connector that AWS owns. You reference it by ID, and the Gateway handles the tool schema, parameter governance, endpoint resolution, and authentication to the backend. In this walkthrough, you give your Gateway’s service role permission to call Web Answer, add a Web Answer target, and call it from a Strands agent. Getting started Getting started takes minutes. A Gateway administrator adds Web Answer as a target on an existing AgentCore Gateway, and the tool appears to any attached agent over MCP through tools/list and tools/call . Prerequisites An AWS account with AgentCore Gateway access. An AgentCore Gateway in us-east-1 that uses IAM ( AWS_IAM ) inbound authentication. To create one, see Create an Amazon Bedrock AgentCore Gateway in the Developer Guide. AWS credentials for an identity that has bedrock-agentcore:InvokeGateway on the Gateway, and Amazon Bedrock access to the model your agent uses. Python 3.10 or later, with the required packages: pip install boto3 strands-agents mcp mcp-proxy-for-aws Note: Following these steps creates AWS resources that incur charges. The Gateway and Web Answer invocations are billable. See the Pricing section that follows for details, and when you finish, delete the resources you created (see “Clean up resources”). Step 1: Grant the Gateway service role access to Web Answer The Gateway uses its service role to act on your behalf. The role’s trust policy allows bedrock-agentcore.amazonaws.com to assume it, scoped to your account. For Web Answer, the role needs: bedrock-agentcore:InvokeWebAnswer , to call Web Answer. The Gateway checks this permission on every request against the ARN that AWS owns, arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-answer.v1 . Attach the policy to the service role as an inline policy: import json import boto3 iam = boto3.client("iam") iam.put_role_policy( RoleName=" ", PolicyName="WebAnswerGuide", PolicyDocument=json.dumps({ "Version": "2012-10-17", "Statement": [ { "Sid": "InvokeWebAnswer", "Effect": "Allow", "Action": "bedrock-agentcore:InvokeWebAnswer", "Resource": "arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-answer.v1", } ], }), ) The role controls only the Gateway’s outbound calls. Who can call your Gateway is set by its inbound authorizer. The role also doesn’t need bedrock:InvokeModel : your agent’s model runs under your agent’s own identity. Step 2: Create the Web Answer target Add Web Answer as a connector target. The connectorId tells the Gateway which managed integration to provision: in this case, an agent that searches the web and writes a cited answer. import boto3 gateway_client = boto3.client("bedrock-agentcore-control", region_name="us-east-1") target_response = gateway_client.create_gateway_target( name="web-answer-tool", gatewayIdentifier=gateway_id, targetConfiguration={ "mcp": { "connector": { "source": {"connectorId": "web-answer"}, "configurations": [{"name": "WebAnswer", "parameterValues": {}}], } } }, credentialProviderConfigurations=[ {"credentialProviderType": "GATEWAY_IAM_ROLE"} ], ) target_id = target_response["targetId"] Outbound authentication is automatic for connectors. With GATEWAY_IAM_ROLE , the Gateway calls the Web Answer backend with the service role from Step 1, so you don’t create or store any credentials for the tool. Wait until get_gateway_target reports the target status as READY before you call it. As the Gateway administrator, you can also set a domain filter on the target. The filter applies to every call that goes through the target. To limit the target to a set of domains, set parameterValues to {"domainFilter": {"include": ["bis.org"], "exclude": ["unreliable-source.net"]}} . Step 3: Invoke Web Answer from a Strands agent Your agent discovers Web Answer through the Gateway’s tools/list and calls it with tools/call , like any other MCP tool. This works with Strands Agents, LangChain, LangGraph, CrewAI, or any other MCP-compatible client. from strands import Agent from strands.models.bedrock import BedrockModel from strands.tools.mcp import MCPClient from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client gateway_url = "https://gateway- .gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp" mcp_client = MCPClient(lambda: aws_iam_streamablehttp_client( endpoint=gateway_url, aws_region="us-east-1", aws_service="bedrock-agentcore", aws_profile=" ", # identity with bedrock-agentcore:InvokeGateway on the Gateway )) mode