Web Answer en Bedrock AgentCore: respuestas con fuentes para tus agentes en una sola llamada

El 5 de noviembre de 2026 AWS anunció Web Answer en Amazon Bedrock AgentCore: una herramienta administrada que recibe una pregunta en lenguaje natural y devuelve una respuesta ya redactada, con cada afirmación atada a la URL de su fuente. Se agrega como un target más de un AgentCore Gateway, tu agente la llama por MCP y AWS se encarga de buscar, leer, verificar y citar.

Es la segunda pieza de la búsqueda web dentro de AgentCore. En junio había llegado Web Search, que devuelve resultados rankeados para que tu modelo los procese. Web Answer da un paso más: el trabajo de investigación lo hace un agente de AWS y vos recibís el resultado final. En este artículo vemos qué es, en qué se diferencia de Web Search, cómo se configura con la AWS CLI, cómo llamarla desde un agente con Strands (y correrlo en EKS), cuánto cuesta y qué conviene mirar antes de usarla en serio.

TL;DR

• Web Answer es un conector administrado de AgentCore Gateway (connectorId: "web-answer") que devuelve una respuesta sintetizada con citas en una sola llamada de herramienta.
• Por dentro, un agente de AWS planifica búsquedas, corre varias en paralelo, lee páginas para verificar datos y vuelve a buscar si le falta evidencia.
• Busca en un índice web operado por Amazon y en su Knowledge Graph; las consultas no se mandan a buscadores de terceros.
• Tiene filtros de dominio a nivel admin (no se pueden saltear) y filtros por llamada: dominios, rango de fechas de publicación y país.
• Cuesta USD 10 cada 1.000 llamadas, más USD 0,005 cada 1.000 invocaciones del Gateway. Web Search cuesta USD 7 cada 1.000 consultas.
• Solo en us-east-1, con un límite de 10 llamadas por segundo por cuenta al lanzamiento.
• Las condiciones de uso te obligan a mostrar las citas junto con la respuesta y te prohíben almacenar resultados de forma masiva.

Por qué ahora

Darle acceso a la web a un agente parece fácil hasta que lo hacés en producción. El patrón típico era integrar una API de búsqueda de terceros, pasarle los resultados al modelo, dejar que decida qué páginas leer, descargarlas, recortarlas para que entren en el contexto, sintetizar y, si te acordabas, citar las fuentes. Cada paso suma tokens, latencia, una API key más que rotar y un proveedor más en tu análisis de riesgo.

AgentCore viene armando ese camino en partes. Primero fue el Gateway, que convierte APIs, Lambdas y servidores MCP en herramientas para agentes. En junio llegó Web Search como conector administrado, con índice propio de Amazon. Web Answer cierra el circuito para el caso más común: el agente tiene una pregunta concreta y necesita una respuesta actual y verificable, no una lista de links.

El momento también tiene que ver con cómo estamos construyendo agentes. Cada vez más equipos usan modelos chicos o rápidos para orquestar y prefieren no gastar su ventana de contexto en leer diez páginas web. Delegar la investigación a una herramienta que devuelve un párrafo con citas es una forma directa de bajar tokens y latencia en el agente principal.

Qué es y qué no es

Lo primero es no confundirlo con Web Search, porque viven en el mismo lugar del Gateway y se configuran casi igual:

Lo que no es:

• No es un buscador de propósito general para usuarios finales. Es una herramienta para agentes, expuesta por MCP detrás de un Gateway.
• No es una base de datos. Las condiciones de uso prohíben extraer o almacenar resultados de forma masiva o usarlos para armar un índice propio.
• No es asesoramiento profesional. La propia documentación aclara que en contextos regulados tenés que revisar las respuestas antes de usarlas.
• No reemplaza a Web Search. AWS sugiere usar las dos: Web Search para investigar a fondo y Web Answer para preguntas concretas.

Cómo funciona

El recorrido de una pregunta es así:

1. Tu agente llama a la herramienta WebAnswer en el Gateway con la pregunta y, opcionalmente, filtros.
2. El Gateway autentica al que llama (IAM con SigV4 o un JWT de tu proveedor de identidad).
3. El Gateway invoca Web Answer con su propio rol de servicio. No hay API key que guardar.
4. Web Answer pasa la pregunta por salvaguardas de IA responsable, planifica las búsquedas (el modelo conoce la fecha del día para buscar información actual), corre varias en paralelo sobre el índice de Amazon, lee las páginas clave, verifica datos y, si la evidencia no alcanza, vuelve a buscar.
5. Redacta una respuesta donde cada afirmación queda atada a una URL, y el Gateway la devuelve como resultado de herramienta MCP.

Un detalle interesante: el rol de servicio del Gateway no necesita bedrock:InvokeModel. El modelo que usa Web Answer corre del lado de AWS y su costo está incluido en el precio por llamada. Según la documentación, el procesamiento puede usar inferencia entre regiones, pero siempre dentro del mismo límite geográfico (US, EU o APAC).

El formato de respuesta

La respuesta llega en dos formas. En content viene el texto en markdown con marcadores de cita, listo para mostrar. En structuredContent viene lo mismo pero estructurado, para que tu aplicación pueda armar sus propias tarjetas de fuentes:

{
  "isError": false,
  "content": [
    {
      "type": "text",
      "text": "Under Basel III, banks must hold Common Equity Tier 1 capital of at least 4.5% of risk-weighted assets [[1](https://example.com/basel-iii)]..."
    }
  ],
  "structuredContent": {
    "answer": [
      {
        "text": "Under Basel III, banks must hold Common Equity Tier 1 capital of at least 4.5% of risk-weighted assets [[1](https://example.com/basel-iii)]...",
        "citations": [
          {"domain": "example.com", "url": "https://example.com/basel-iii"}
        ]
      }
    ]
  },
  "_meta": {
    "latencyMs": 5210
  }
}

Tres cosas para tener en cuenta al parsear: el marcador N apunta a citations[N-1] dentro del mismo bloque; puede haber varios bloques en answer, así que hay que recorrerlos todos; y si algo falla, isError viene en true con la explicación en content[0].text. El ejemplo de AWS muestra una latencia de servidor de unos 5 segundos, que es razonable para algo que corre varias búsquedas y lee páginas.

Filtros: quién controla qué

Acá está la parte que más le importa a un equipo de plataforma. Hay dos niveles de filtro y el diseño es claro: el administrador pone el límite y el agente solo puede achicarlo.

• Nivel target (admin): se define al crear el target con parameterValues.domainFilter, con listas include y exclude de hasta 50 dominios cada una.
• Nivel llamada (agente): en cada invocación el agente puede mandar filters.domainFilter, filters.publishedDateFilter (from y to, inclusivos, en UTC e ISO-8601) y userLocation.country (código ISO de dos letras, por ejemplo AR).

Las reglas de combinación:

• Un dominio queda excluido si aparece en cualquiera de las dos listas de exclusión (la lista combinada llega hasta 100).
• Si los dos niveles definen include, se usa la intersección. Si no comparten ningún dominio, la llamada falla con error de validación.
• Si from es posterior a to, también falla.
• Excluir un dominio raíz excluye sus subdominios: example.com bloquea blog.example.com.

Los filtros por llamada y userLocation necesitan la versión 1.1.0 o superior del conector; la 1.0.0 solo acepta query. La pregunta puede tener hasta 30.000 caracteres.

Manos a la obra

Vamos a agregar Web Answer a un Gateway existente en us-east-1 y llamarlo desde un agente con Strands. Si todavía no tenés un Gateway, el asistente de la consola lo crea en un par de pasos (las capturas son del lanzamiento de Web Search de junio, pero el flujo es el mismo: target MCP, tipo Connectors y elegís la herramienta).

1. Permiso para el rol de servicio del Gateway

El rol del Gateway necesita poder invocar Web Answer sobre el recurso administrado por AWS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeGateway",
      "Effect": "Allow",
      "Action": "bedrock-agentcore:InvokeGateway",
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/*"
    },
    {
      "Sid": "InvokeWebAnswer",
      "Effect": "Allow",
      "Action": "bedrock-agentcore:InvokeWebAnswer",
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-answer.v1"
    }
  ]
}

Fijate la cuenta aws en el ARN del recurso: la herramienta es de AWS, no tuya.

2. Crear el target con un filtro de dominios

aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier "<GATEWAY_ID>" \
  --name "web-answer-tool" \
  --target-configuration '{
    "mcp": {
      "connector": {
        "source": { "connectorId": "web-answer" },
        "configurations": [
          {
            "name": "WebAnswer",
            "parameterValues": {
              "domainFilter": {
                "include": ["docs.aws.amazon.com", "aws.amazon.com", "kubernetes.io"],
                "exclude": ["foros-dudosos.example.com"]
              }
            }
          }
        ]
      }
    }
  }' \
  --credential-provider-configurations '[{"credentialProviderType": "GATEWAY_IAM_ROLE"}]' \
  --region us-east-1

Con esto, aunque el agente pida otra cosa, Web Answer solo va a responder con fuentes de la documentación de AWS y de Kubernetes. Es una forma simple de armar un "asistente de documentación oficial" sin mantener un RAG propio. Después esperá a que el target quede en READY (con get-gateway-target o en la consola).

3. Probarlo antes de escribir código

El Gateway es un servidor MCP, así que podés probarlo con el MCP Inspector: conectás a la URL del Gateway, listás herramientas, elegís web-answer-tool___WebAnswer, cargás una pregunta y ejecutás. Ojo con un detalle: si el Gateway tiene búsqueda semántica activada, tools/list también devuelve x_amz_bedrock_agentcore_search, que puede aparecer primero. En tu código buscá la herramienta por el sufijo ___WebAnswer, no por posición.

4. Llamarlo desde un agente con Strands

pip install boto3 strands-agents mcp mcp-proxy-for-aws

from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client
from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient

GATEWAY_URL = "https://<gateway-id>.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp"

gateway = MCPClient(lambda: aws_iam_streamablehttp_client(
    endpoint=GATEWAY_URL,
    aws_region="us-east-1",
    aws_service="bedrock-agentcore",
))

with gateway:
    tools = gateway.list_tools_sync()
    agent = Agent(
        model=BedrockModel(model_id="us.anthropic.claude-sonnet-5", max_tokens=1024),
        tools=tools,
        system_prompt=(
            "Sos un asistente de plataforma. Para datos que cambian con el tiempo "
            "(versiones, precios, regiones) usá la herramienta WebAnswer y "
            "mostrá siempre las fuentes que devuelve."
        ),
    )
    resultado = agent("¿Qué versiones de Kubernetes soporta hoy Amazon EKS en soporte estándar?")
    print(resultado.message)

La autenticación hacia el Gateway es IAM con SigV4: el cliente firma con las credenciales del entorno. No hay tokens de búsqueda ni API keys en el código.

Si querés llamar la herramienta directamente, sin que el modelo decida, también podés, y es la mejor forma de probar los filtros por llamada:

with gateway:
    nombre = next(t.tool_name for t in gateway.list_tools_sync()
                  if t.tool_name.endswith("___WebAnswer"))
    respuesta = gateway.call_tool_sync(
        tool_use_id="prueba-1",
        name=nombre,
        arguments={
            "query": "¿Qué cambió en el soporte extendido de Amazon EKS este año?",
            "filters": {
                "publishedDateFilter": {"from": "2026-01-01"},
                "domainFilter": {"include": ["aws.amazon.com"]}
            },
            "userLocation": {"country": "AR"}
        },
    )
    print(respuesta)

5. Correr el agente en Amazon EKS

Si tu agente vive en un pod de EKS, lo único que necesita es un rol con permiso para invocar el Gateway, asociado a la ServiceAccount con EKS Pod Identity. El rol del pod no necesita permisos de Web Answer (eso lo hace el rol del Gateway), pero sí los de Bedrock para el modelo que orquesta:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock-agentcore:InvokeGateway",
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/<gateway-id>"
    },
    {
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "*"
    }
  ]
}

aws eks create-pod-identity-association \
  --cluster-name plataforma \
  --namespace agentes \
  --service-account asistente-plataforma \
  --role-arn arn:aws:iam::111122223333:role/asistente-plataforma

Restringí el Resource de Bedrock a los perfiles de inferencia que realmente uses; el * está solo para acortar el ejemplo. Si el clúster no tiene salida a internet, el Gateway soporta endpoints de interfaz de VPC con PrivateLink (com.amazonaws.us-east-1.bedrock-agentcore.gateway), así que el tráfico del agente al Gateway no tiene por qué pasar por un NAT.

Y si usás AgentCore Harness en vez de tu propio runtime, podés adjuntar el Gateway como herramienta agentcore_gateway y darle al rol de ejecución del harness bedrock-agentcore:InvokeGateway sobre el ARN del Gateway.

Trampas comunes

• Región. Solo us-east-1. Si tu Gateway está en otra región, no vas a ver el conector.
• Versión del conector. Si no ves los filtros por llamada, revisá que el target use la versión 1.1.0 o superior.
• Límite de tasa. 10 llamadas por segundo por cuenta en us-east-1. Un agente con un bucle mal controlado o varios equipos compartiendo cuenta lo alcanzan rápido. Las ampliaciones se piden a AWS Support.
• Intersección vacía. Si el admin define include y el agente manda otro include sin dominios en común, la llamada falla. Enseñale al agente (en el system prompt o en la descripción de la herramienta) qué dominios tiene permitidos.
• Mostrar las citas. No es opcional: las condiciones de uso exigen conservar y mostrar las citas y links con cualquier resultado que le muestres a un usuario.

Precios

Los precios son los publicados en la página de AgentCore; Web Answer hoy solo existe en us-east-1. El cobro es por llamada, no por tokens: el modelo que usa Web Answer por dentro ya está incluido.

Un ejemplo para dimensionar: un asistente interno que hace 2.000 consultas por día hábil (unas 44.000 por mes) cuesta alrededor de USD 440 por mes en Web Answer, más centavos de Gateway. A eso sumale lo que gaste tu modelo orquestador, que debería ser menos que con Web Search porque no tiene que leer los resultados crudos.

Cómo bajar el costo en la práctica:

• No lo uses para todo. Decile al agente, en el system prompt, que use Web Answer solo para información que cambia con el tiempo. Lo que ya sabe el modelo o está en tu base de conocimiento no necesita una llamada de 1 centavo.
• Cacheá respuestas con criterio. Las condiciones prohíben el almacenamiento masivo, pero un caché corto para la misma pregunta dentro de una sesión es razonable; revisalo con tu equipo legal si vas a guardarlo más tiempo.
• Combiná con Web Search. Para tareas de investigación largas, Web Search a USD 7 con tu modelo filtrando puede salir más barato que encadenar muchas llamadas a Web Answer.

Disponibilidad y lo que conviene mirar con lupa

• ¿Está en sa-east-1? No. Solo us-east-1, y AWS dice que vienen más regiones sin dar fechas. Si tu Gateway está en São Paulo, vas a necesitar un Gateway en us-east-1 para esta herramienta.
• Residencia de datos. AWS dice que las consultas y resultados quedan dentro de AWS, que no se mandan a buscadores de terceros ni a sitios externos, y el diagrama oficial agrega que no se usan para entrenar modelos. El procesamiento puede moverse entre regiones dentro del límite geográfico de EE.UU. Si tenés requisitos de que los datos no salgan del país, mandar preguntas a us-east-1 puede ser un problema, sobre todo si las preguntas incluyen datos de clientes.
• Qué se manda en la pregunta. El riesgo real no es la búsqueda sino lo que el agente pone en el query. Revisá que tu agente no copie datos personales o internos en la pregunta. Un Guardrail de Bedrock o una validación en un interceptor del Gateway ayudan.
• Transferencia entre regiones. Si tu agente corre en sa-east-1 y llama a un Gateway en us-east-1, pagás la transferencia entre regiones y sumás latencia de red a los ~5 segundos de la herramienta.
• Lo que la documentación no dice. No encontré detalle sobre cuánto tiempo se retienen las consultas ni cómo se tratan reglas como robots.txt en el índice. Si son requisitos para tu organización, conviene preguntarle a tu equipo de cuenta antes de pasar a producción.

¿Vale la pena?

Si estás construyendo agentes sobre AgentCore y necesitás datos actuales, sí, al menos para probarlo. Te ahorra integrar un proveedor de búsqueda externo, manejar otra API key y escribir la lógica de leer, recortar y citar páginas. Los filtros a nivel admin son un buen control de plataforma: podés dar acceso a la web a muchos agentes con una política central de qué fuentes son aceptables.

Donde lo pensaría: cargas con requisitos fuertes de residencia de datos fuera de EE.UU., agentes que necesitan razonar sobre muchos resultados (ahí Web Search encaja mejor) y casos de mucho volumen, donde USD 10 cada 1.000 llamadas se nota.

Mi lectura: Web Answer es una apuesta a que la investigación web se convierta en un servicio más, como hoy lo es una cola o una base de datos. Lo que más me gusta es la separación de responsabilidades: el agente decide cuándo necesita información externa, el Gateway decide quién puede usarla y con qué fuentes, y AWS se encarga de buscar y citar. Para equipos de plataforma, eso es gobernanza que antes había que construir. Lo que me deja con dudas es la caja negra: no elegís el modelo, no ves las búsquedas intermedias y dependés de la calidad del índice de Amazon frente a buscadores que llevan décadas en esto. Mi recomendación es empezar con un caso acotado y con include estricto, como un asistente que responde solo con documentación oficial, medir calidad y costo durante unas semanas y recién después abrirlo.

Recursos

• Anuncio en AWS What's New
• Getting started with Web Answer on Amazon Bedrock AgentCore (AWS AI Blog)
• Documentación de Web Answer
• Configuración de targets del Gateway (incluye Web Answer y Web Search)
• Lanzamiento de Web Search en AgentCore (AWS News Blog, junio 2026)
• Precios de Amazon Bedrock AgentCore
• Desplegando.cloud, noticias del 09/11/2026