OpenAI movió una pieza pequeña pero importante para agentes que investigan la web: desde el 9 de junio de 2026, el Web Search de Responses API puede devolver resultados de imagen además de texto. No es una función para decorar respuestas. Es una forma de pedir evidencia visual actual cuando el agente necesita reconocer un producto, un lugar, un evento, una interfaz o una referencia editorial.

La diferencia práctica es clara: antes, si tu flujo necesitaba una imagen verificable, terminabas combinando búsqueda textual, scraping, screenshots o una segunda API. Ahora puedes tratar la búsqueda visual como parte del mismo loop de Responses, con el mismo contrato de herramientas y citas.

El caso de uso bueno no es "dame imágenes"

El uso fuerte es más específico: dame referencias visuales actuales y con fuente para tomar una decisión. Para un builder, eso puede significar:

comparar fotos oficiales de producto antes de generar una ficha;
encontrar imágenes actuales de un lugar para una app de viajes;
verificar si un evento, dispositivo o interfaz cambió;
alimentar un brief editorial sin inventar detalles visuales;
construir un agente de compras que necesita confirmar variantes, colores o empaque.

La documentación de Web Search sigue dejando claro que la herramienta busca información actual y devuelve respuestas con citas. El changelog agrega la capa visual, pero no elimina el trabajo editorial: una imagen encontrada por web search no se vuelve automáticamente reutilizable, correcta o suficiente.

Ese matiz importa para agentes. Una miniatura puede venir de un medio, un marketplace, una red social o una página oficial. El agente debe distinguir entre evidencia visual, referencia inspiracional y asset reutilizable. Si no haces esa separación, vas a terminar con imágenes sin derechos claros, UI copiada o decisiones basadas en thumbnails fuera de contexto.

Cómo lo pondría en producción

Yo no dejaría que el agente use imágenes de Web Search como acción final sin una capa de revisión. El patrón más sano sería:

Buscar con web_search cuando el prompt realmente necesite señales visuales actuales.
Pedir que la salida separe fuente, tipo de imagen, fecha visible si existe y razón por la que importa.
Pasar las URLs por una política: oficial, medio, tienda, comunidad, screenshot o fuente dudosa.
Usar imágenes externas directamente solo si el uso está permitido o es defendible.
Para contenido editorial, convertir fuentes no reutilizables en brief visual y generar una imagen nueva distinta.

El riesgo: más contexto visual también significa más ruido

La búsqueda visual puede mejorar un agente, pero también le abre más superficie para equivocarse. Un resultado puede estar desactualizado, optimizado para SEO, manipulado por marketing o desconectado del texto que lo rodea. En flujos sensibles, eso pide guardrails: dominio permitido, recencia mínima, comparación entre varias fuentes y una regla explícita de no usar una imagen si no puede explicar de dónde salió.

También hay costo y latencia. La guía de OpenAI permite ajustar search_context_size para controlar cuánto contexto de búsqueda entra antes de generar la respuesta. Para consultas visuales simples, low puede bastar. Para investigación editorial o comparación entre proveedores, conviene subir el contexto o correr el trabajo en background si el flujo va a inspeccionar varias páginas.

La oportunidad de tráfico está en queries como OpenAI web search image results, Responses API image search y web search visual references. No es una búsqueda masiva de curiosidad; es intención de implementación. Quien busca eso normalmente ya tiene un agente, una app o un pipeline de contenido que necesita evidencia visual sin armar otro sistema paralelo.

Si todavía estás ordenando la base de tools, permisos y validación antes de meter búsquedas web en un agente real, empieza por el curso gratis. La conclusión práctica es esta: Web Search con imágenes no reemplaza tu criterio editorial ni tu política de licencias; sí reduce el pegamento para conseguir referencias visuales actuales dentro del mismo loop de Responses API.