AI

Ejecutar agentes Amazon Nova Act en producción con Bright Data

Combina Amazon Nova Act con la capa de acceso web de Bright Data, la Browser API y Web Unlocker, para agentes web de IA fiables y en cumplimiento en producción.
32 min de lectura
Amazon Nova with Bright Data

Amazon Nova Act puede razonar sobre una página web y actuar en ella. En 2026, la parte difícil de un agente web en producción no es el modelo. Es el acceso web: llegar a la web en vivo de forma fiable, con el geo-targeting correcto y manteniéndose en cumplimiento. Este artículo combina Nova Act con la capa de acceso web de Bright Data para agentes de IA, y las mediciones aquí provienen de ejecuciones en vivo.

TL;DR

El cuello de botella para un agente web de IA en producción es el acceso web, no el modelo. La solución es una división: Amazon Nova Act toma las decisiones del navegador en múltiples pasos, y la capa de acceso web de Bright Data gestiona el acceso, el cumplimiento y la escala. El informe Datos para IA 2026 de Bright Data encuentra que el 97% de las organizaciones de IA dependen de datos web en tiempo real, y el 90% afirma que las restricciones de acceso están limitando sus iniciativas de IA.

El script ejecutable completo, con cada importación, esquema y helper, está en el repositorio complementario. Clónalo si quieres ejecutarlo, no copies y pegues desde aquí.

Para seguir el tutorial necesitas Python 3.10+, pip install nova-act, y una clave API de Nova Act desde nova.amazon.com/act. También necesitas una cuenta de Bright Data con una zona de Browser API, más una clave API para las llamadas a la capa de datos. Node.js solo es necesario para la sección de Web MCP.

Por qué el enfoque predeterminado del agente de navegador se queda corto

El enfoque obvio con un agente de navegador es dejar que haga todo. Abrir una página, cerrar el banner de cookies, desplazarse, extraer. Se ve bien en una demo, pero para la mayoría del trabajo con datos es el enfoque predeterminado incorrecto.

  • Es pesado. Una sola página de consumidor real (una búsqueda en eBay) transfirió aproximadamente 3,4 MB a través del navegador. Multiplica eso por millones de páginas y pagas por mover toda la web renderizada, incluidas cada imagen, para extraer tres campos.
  • Es frágil al actuar. Apuntado a booking.com, Nova Act lanzó ActActuationError mientras luchaba contra popups y contenido de carga diferida, aunque la página cargó bien. Las lecturas simples suelen ser fiables. La actuación compleja de múltiples pasos falla ahí.
  • Es no determinista. La fiabilidad cae rápidamente. Diez pasos con fiabilidad del 90% resultan en cerca de 0,9¹⁰ ≈ 35% a menos que lo planifiques.

Nada de esto hace inútiles a los agentes de navegador. Úsalos para lo que solo ellos pueden hacer (las acciones y decisiones de múltiples pasos), y delega todo lo demás a la infraestructura.

Qué es Amazon Nova Act, y qué no es

Nova Act es un SDK de AWS, versión 3.4.x a mediados de 2026, en transición de vista previa de investigación hacia producción, para construir agentes de navegador en Python. Su idea de diseño es lo opuesto a un gran prompt único. Divides un flujo de trabajo en comandos pequeños, atómicos y fiables, y los conectas con Python ordinario. Los dos comandos son una acción y una lectura tipada:

from nova_act import NovaAct
from pydantic import BaseModel

class Product(BaseModel):
    title: str | None = None
    price: str | None = None
    availability: str | None = None

with NovaAct(starting_page="https://example.com/product/123") as nova:
    nova.act("search for wireless headphones")          # una acción
    data = nova.act_get(                                 # una lectura tipada
        "Return the product title, price, and availability.",
        schema=Product.model_json_schema(),
    )

Con un esquema Pydantic, act_get puede convertir una página en datos tipados sin selectores frágiles. Nova Act maneja un Chromium real a través de Playwright internamente, un detalle importante para la conexión. Nova Act te da razonamiento, navegación y extracción estructurada. No te da ninguna respuesta a la hostilidad de la web abierta. No tiene alcance geográfico, ni desbloqueo a escala, ni cumplimiento integrado. Ese no es su trabajo. Es el trabajo de la capa de infraestructura.

Bright Data, la capa de acceso web

La capa se construye alrededor de una idea: desbloquear la web para tu IA. Web MCP, un servidor de Model Context Protocol, da a un agente herramientas web estructuradas que llama directamente. Web Unlocker y la API SERP devuelven páginas limpias y resultados de búsqueda. Las APIs de Web Scraper y los Conjuntos de datos hacen recuperación estructurada masiva. La Browser API es un Chrome en la nube que manejas remotamente, para los casos en que un agente necesita actuar. Por debajo hay una red de más de 400M de IPs residenciales en 195 países, con desafíos CAPTCHA comunes, gestión de huellas digitales y geo-targeting gestionados.

En la encuesta Datos para IA 2026 de Bright Data, el 87% de las organizaciones coincide en que está surgiendo una “internet de dos niveles”, una web agéntica de tráfico automatizado que funciona junto a la humana. Y el 65% ya depende de un proveedor dedicado de infraestructura de datos web en lugar de construir el acceso internamente.

Esto es una capa, no una herramienta. Tu stack de agentes cambia. La capa de acceso web que hay debajo no cambia. Así que la pregunta de ingeniería nunca es navegador versus API en abstracto. Divides el trabajo en dos: el agente maneja las decisiones, la infraestructura maneja el acceso.

La arquitectura, el cerebro arriba y la infraestructura debajo

Nova Act envía acciones hacia abajo, y los datos estructurados regresan.

Diagrama de arquitectura: Nova Act (el cerebro) envía acciones a la capa de acceso web de Bright Data y recibe datos estructurados de vuelta. La capa proporciona la Browser API, Web MCP, API SERP, Web Unlocker y APIs de Web Scraper, además de cumplimiento, geo-enrutamiento y más de 400M de IPs residenciales, y llega a la web en vivo.

Nova Act toma las decisiones y acciones. La capa de acceso web de Bright Data gestiona el acceso, el cumplimiento, la geografía y la escala, y luego llega a la web en vivo.

Para el modo de acción, Nova Act se conecta a la Browser API de Bright Data a través del Chrome DevTools Protocol (CDP), el mismo protocolo que Playwright (y por tanto Nova Act) ya utiliza. Intercambias el navegador y mantienes el agente.

Cómo conectarlo, y los errores de configuración que debes esperar

Crea una zona de Browser API (su solucionador de CAPTCHA está activado por defecto) y el panel te da una URL:

wss://brd-customer-<id>-zone-<name>:<password>@brd.superproxy.io:9222

Esa cadena proviene de la pestaña Overview de la zona, bajo Detalles de acceso.

Panel de detalles de acceso de la zona Browser API de Bright Data, mostrando la cadena de conexión wss:// y la lista de IPs permitidas

Los detalles de acceso de la zona Browser API. El panel te entrega la cadena wss:// con credenciales en línea, la forma auth+@host mostrada en la parte superior del panel. Playwright moderno rechaza esa forma en línea, por lo que split_cdp() mueve las credenciales a un encabezado Authorization: Basic. La lista de IPs permitidas a la izquierda es el otro problema. Si tu IP no está listada allí, la llamada devuelve un cuerpo vacío y la razón llega en los encabezados de respuesta en lugar del código de estado.

El error Invalid URL: Playwright rechaza credenciales wss:// en línea

Pégalo directamente en Nova Act y falla:

playwright._impl._errors.Error: BrowserType.connect_over_cdp:
    Invalid URL: wss://brd-customer-...:[email protected]:9222

Este es un fallo común en la primera ejecución. Playwright moderno, versión 1.56, incluido con Nova Act 3.4, rechaza credenciales integradas en una URL de WebSocket. El panel muestra la forma en línea porque funciona con clientes más antiguos, no con el Playwright dentro de Nova Act. La solución es extraer las credenciales y pasarlas como un encabezado Authorization: Basic a través de cdp_headers.

import os
import base64

def split_cdp(raw_url: str) -> tuple[str, dict | None]:
    """Bright Data gives an inline-credential wss URL; Playwright rejects that.
    Move credentials into a Basic auth header. (Parsed manually because
    Python 3.14's urlsplit also rejects the multi-colon netloc.)"""
    scheme, sep, rest = raw_url.partition("://")
    if not sep or "@" not in rest:
        return raw_url, None
    creds, _, hostport = rest.rpartition("@")
    user, _, pwd = creds.partition(":")
    token = base64.b64encode(f"{user}:{pwd}".encode()).decode()
    return f"{scheme}://{hostport}", {"Authorization": f"Basic {token}"}

endpoint, headers = split_cdp(os.environ["BRIGHTDATA_CDP_URL"])
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
             logs_directory="runs/demo") as nova:    # NOTE: el directorio de logs debe existir previamente
    ...

La trampa intermitente InvalidScreenResolution

El otro gran problema es la ventana gráfica. El navegador remoto de Bright Data da a Nova Act una ventana de alrededor de 1280×585, que es más pequeña que los aproximadamente 1600×900 que Nova Act espera. Nova Act no degrada con gracia. Lanza un InvalidScreenResolution ActError intermitente. Es intermitente porque cada sesión en la nube obtiene un tamaño ligeramente diferente. Eso lo hace difícil de diagnosticar, y fácil de malinterpretar como un agente inestable que necesita un reintento. Fuerza un tamaño compatible en la página conectada:

with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
             screen_width=1600, screen_height=900, logs_directory="runs/demo") as nova:
    nova.page.set_viewport_size({"width": 1600, "height": 900})   # fuerza un tamaño compatible para evitar InvalidScreenResolution
    ...

Dos trampas menores: StartFailed y un logs_directory faltante

No pases headless=True con cdp_endpoint_url, porque el navegador remoto ya es headless y obtendrás StartFailed. Y logs_directory debe existir antes de empezar, porque Nova Act valida la ruta y no la creará.

Para qué sirve el agente

Con la conexión establecida, la pregunta es qué hacer que haga el agente. Una lectura simple es lo menos distintivo que ofrece, y las APIs de Web Scraper de Bright Data hacen eso mejor y más barato. Un agente vale más que un Scraper porque puede actuar.

Su acción más útil es llegar a datos detrás de un formulario. No hay una URL estática que conocer de antemano ni una API allí, así que un Scraper no tiene nada a qué apuntar. Un agente puede rellenar el formulario y leer el resultado. Así que apuntamos Nova Act a Drugs@FDA, la base de datos autorizada de aprobación de medicamentos de EE. UU., y le pedimos que recuperara un registro de medicamento:

nova.act("Search for the drug named ibuprofen")            # rellenar el formulario, enviar
drug = nova.act_get("Return the brand name, active ingredient, application number, "
                    "and marketing status of the first result.", schema=Drug.model_json_schema())

Su propio rastro muestra un flujo de cuatro pasos que ninguna URL captura. Escribió en el cuadro de búsqueda y presionó Enter, encontró el primer resultado contraído y hizo clic para expandirlo, navegó hasta la página de detalles, luego leyó los campos:

{'drug_name': 'ACETAMINOPHEN AND IBUPROFEN', 'active_ingredient': 'ACETAMINOPHEN; IBUPROFEN',
 'application_number': '214836', 'marketing_status': 'Over-the-counter'}    # todos los 4 basados en el DOM

Esos cuatro pasos, en el navegador:

Grabación de pantalla animada de Nova Act buscando en el sitio Drugs@FDA y leyendo un registro de medicamento

Una grabación real de la ejecución, fotograma a fotograma. Nova Act busca “ibuprofen” en Drugs@FDA, abre el primer resultado y lee ANDA #214836, el mismo número de solicitud que devolvió la ejecución.

Lo ejecutamos con diferentes medicamentos para confirmar la consistencia: aspirin dio 8-HOUR BAYER (#016030), y metformin dio ACTOPLUS MET (#021842). Con ibuprofen, eso es 3/3, cada campo basado en el DOM. Aquí es donde el agente justifica su costo. El agente rellena el formulario y navega a datos públicos autorizados, bloqueados por formularios, que un Scraper no puede alcanzar. Fundamentar la IA en datos públicos de la web profunda es un problema real. En un sitio cooperativo y bien estructurado, es fiable.

La larga cola

El mismo enfoque cubre la larga cola, los sitios de nicho sin un Scraper prediseñado. Las APIs de Web Scraper de Bright Data ya cubren más de 100 de los de mayor valor. Apuntado a BoardGameGeek, Nova Act devolvió un registro limpio de seis campos, Catan / 1995 / 3,4 jugadores / 60,120 min / puntuación 7,1 / precio más bajo. Lo verificas contra el DOM en vivo a través de nova.page, el identificador de Playwright, en la misma sesión:

assert game.parsed_response["bgg_rating"] in nova.page.inner_text("body")   # 7.1 -> presente

Surgieron dos lecciones de fundamentación. Normalizar antes de comparar, porque el guión largo de la página 3,4 frente al guión del agente 3-4 es una discrepancia falsa, no una alucinación. Y verificar en sesión, nunca después, porque un precio de mercado en vivo estaba fundamentado en el momento de la extracción y desaparecido al recargar, por lo que una verificación de segunda pasada de datos volátiles puede estar equivocada. Con eso, los seis campos estaban fundamentados. Se mantuvo bajo una ejecución concurrente de cinco vías también.

El límite tiene que ver con el terreno, no con la tarea. Nova Act tiene dificultades en sitios de consumidores hostiles como eBay y booking.com: eCommerce defendido por bots con muros de cookies, widgets de variación personalizados y contenido de carga diferida. En esos sitios, las acciones de múltiples pasos se ralentizan y se vuelven inestables, y las cadenas pesadas agotan el tiempo. Es fiable en sitios cooperativos y estructurados: bases de datos públicas, aplicaciones internas y formularios bien construidos. Es frágil en los hostiles de consumidores. Mantén pocas acciones, verifica cada campo con nova.page, reintenta, y deja que la capa de datos de Bright Data maneje los casos hostiles de alto volumen.

Qué cambia realmente el geo-enrutamiento

Ningún navegador local hace esto sin la misma infraestructura de enrutamiento debajo. Ejecutamos la misma búsqueda de hotel en un importante sitio de reservas, enrutado a través de tres países añadiendo -country-XX al nombre de usuario de Bright Data:

Enrutado a través de Moneda Tarifas de muestra por noche
Estados Unidos US$ US$30, US$128, US$171
Reino Unido £ £30, £167, £194
Alemania €40, €194, €225

La moneda cambia limpiamente y los precios reflejan diferencias reales de mercado, no conversión. Leímos estos tres con un navegador sin procesar, porque la geografía es el trabajo de la infraestructura, no del agente. El agente extrae cualquier mercado al que se le apunte, igual que la ejecución de eBay enrutada por EE. UU. Esto importa para el monitoreo de precios competitivo, la agregación de tarifas, o cualquier caso en el que necesites verlo como lo hace un cliente local.

Lo que importa para una ejecución es desde qué IP sales, así que verificamos cada sesión enrutada. Las IPs de salida resultaron ser ISPs de consumidores reales, no rangos de centros de datos: un importante proveedor de cable de EE. UU., un operador de banda ancha del Reino Unido, una red móvil alemana, un operador japonés y un ISP regional brasileño.

Esa es la diferencia entre parecer local y ser local. La solicitud llega como un usuario residencial real en ese país. Así que los precios, el inventario y el tratamiento anti-bot están mucho más cerca de lo que ve un cliente local que de lo que obtiene un rango de centros de datos marcado.

Cumplimiento, el problema del 90%

Aquí es donde las restricciones de acceso importan, el problema del 90% en sí mismo: la mayoría de las organizaciones de IA dicen que esas restricciones están limitando sus iniciativas de IA. Aquí Bright Data actúa como el guardián. Apuntado a un sitio de metabúsqueda de vuelos, el agente fue rechazado:

Page.navigate: Requested URL (kayak.com/flights/...) is restricted in accordance
with robots.txt. Ask your account manager to get full access (brob)

Un navegador local sin procesar raspó el mismo sitio sin problemas momentos antes. Bright Data rechazó. Rechazar es el comportamiento más capaz, no el más débil. Bright Data aplica robots.txt y bloquea objetivos sensibles detrás de verificaciones Verificación KYC por defecto, el enfoque que un equipo legal empresarial puede aprobar.

Para la mayoría de los objetivos empresariales estás bien. En nuestras comprobaciones, booking.com, Expedia, Hotels.com, Airbnb, eBay, Best Buy y Tripadvisor todos pasaron. Los restringidos son una conversación con el Gerente de cuenta, no una solución alternativa. La infraestructura maneja el cumplimiento del lado del acceso para que tu código no tenga que hacerlo.

El presupuesto de costo y fiabilidad

Un revisor de adquisiciones hace dos preguntas: qué tan fiable es, y cuánto cuesta.

Fiabilidad

La fiabilidad tiene una palanca principal y un techo duro. La palanca es la corrección de la ventana gráfica. Antes de establecerla, aproximadamente la mitad de todas las ejecuciones fallaban en InvalidScreenResolution, y ese único error era la mayor parte de lo que parecía un agente inestable.

Después de la corrección lo medimos en un sitio real, no en un sandbox. Una lectura concurrente de cinco vías en eBay devolvió 5/5, cada valor confirmado en el DOM en vivo a través de nova.page, en 47s frente a aproximadamente 198s secuencial, 4,2×. Cada sesión se ejecutó en una IP de Bright Data nueva, lo que evita concentrar solicitudes en una sola IP.

Eso no es escala lineal libre. Lo llevamos a 12 concurrentes y 8 de 12 regresaron limpios. Ese es el techo de concurrencia en los niveles gratuito y de pago por uso, no el agente fallando. El volumen empresarial real significa aumentar el límite de concurrencia de la zona y presupuestar reintentos, no asumir que cinco sesiones escalan a cinco mil sin costo.

Gráfico de barras. Leer las mismas cinco páginas de eBay tomó aproximadamente 198 segundos una a la vez frente a 47 segundos con cinco solicitudes concurrentes, cada una en una IP de Bright Data nueva, una aceleración de 4,2 veces. El escalado no es lineal: a 12 concurrentes, 8 de 12 regresaron limpios.

La ganancia de la concurrencia es real pero no lineal. Pasado el techo de concurrencia del plan, 8 de 12 lecturas concurrentes regresaron limpias.

Una sola acción ligera (ordenar, luego leer) necesitó el reintento ocasional, y los fallos que quedaron fueron StartFaileds transitorios al inicio de la sesión. Así que divide el trabajo en pequeños pasos idempotentes, envuélvelos en reintentos, presupuesta aproximadamente 1,2 a 1,5×, y verifica cada salida con nova.page.

El límite restante es el terreno. En el lado estructurado se mantiene fiable. Tres búsquedas en Drugs@FDA ejecutaron el mismo flujo: rellenar, enviar, hacer clic para expandir, navegar, extraer. Las tres regresaron 3/3, cada campo fundamentado, aunque lentas a aproximadamente 50 a 90 segundos cada una. En el lado del consumidor, las cadenas de múltiples pasos aún se ralentizan y agotan el tiempo.

Los números de fiabilidad en una vista:

Escenario Resultado Qué significa
Antes de la corrección de ventana gráfica ~la mitad de las ejecuciones fallaron InvalidScreenResolution, el fallo dominante
Lectura concurrente de 5 vías, post-corrección (eBay) 5/5 fundamentados 47s vs ~198s secuencial, 4,2×, IP nueva por sesión
Llevado a 12 concurrentes (sin procesar) 8/12 el techo de concurrencia de pago por uso, no el agente
Acción ligera única (ordenar, luego leer) reintento ocasional los fallos son StartFaileds reintentables
Formulario FDA de múltiples pasos, 3 medicamentos 3/3 fundamentados sitio cooperativo, pero lento a ~50,90s cada uno

Costo

El costo de Ancho de banda es medible, y el costo del modelo es la pregunta abierta. La Browser API factura por GB, aproximadamente $8/GB de pago por uso (todos los precios aquí son a mediados de 2026). Medimos el peso real de las páginas a través de ella:

Tipo de página Peso Browser API @ $8/GB
Página de consumidor pesada (búsqueda en eBay) ~3,4 MB ~$0,027/página → ~$27 / 1.000 páginas
Página ligera (producto en sandbox) ~0,2 MB ~$0,0016/página → ~$1,60 / 1.000 páginas

Añade el multiplicador de reintentos, luego añade el costo de inferencia de Nova Act, que hoy no tiene precio público. El nivel gratuito mide cuánto recopilas, y las ejecuciones de producción van a través de AWS sin un precio publicado. Así que el presupuesto se reduce a dos líneas. El Ancho de banda de la Browser API es una partida conocida y predecible. La inferencia del agente es el costo que debes confirmar con AWS antes de escalar.

Mover 3,4 MB para extraer tres campos es también por qué, para el trabajo masivo, no manejas un navegador en absoluto. La capa de datos factura por solicitud en lugar de por gigabyte. La API SERP y Web Unlocker rondan los $1,50 por 1.000, frente a ~$27 por 1.000 páginas pesadas a través del navegador.

Cuándo usar el agente, y cuándo usar la capa de datos

Bright Data ofrece Web MCP y APIs de Web Scraper para que no manejes un navegador para todo. La línea divisoria es la complejidad de la decisión:

  • Extracción fija de esquema conocido, como precio y stock para 100.000 SKUs. No uses un agente. Una API de Web Scraper devuelve solo el registro, sin 3,4 MB de página, sin costo de inferencia y con muchos menos fallos transitorios. Es más barato y más fiable.
  • Razonamiento que un Scraper no puede capturar: navegación de múltiples pasos, lógica condicional (por ejemplo, la tarifa reembolsable más barata que cumple tus restricciones), envío de formularios, control de calidad de aplicaciones web, o un portal desconocido sin Scraper prediseñado. Ahí es donde Nova Act y la Browser API justifican su costo.

La regla: si puedes expresarlo como un Scraper fijo o una llamada a la API, hazlo así. En sistemas reales los dos se componen. Nova Act maneja el flujo de decisiones y pasa la recuperación masiva a las APIs estructuradas de Bright Data.

La capa de datos en la práctica

“Usa la capa de datos para trabajo masivo” es el consejo habitual. Aquí está, ejecutado contra la misma cuenta de Bright Data, tres llamadas, sin navegador, sin agente.

Búsqueda estructurada en una llamada (API SERP), resultados de búsqueda frescos y parseados para fundamentar una IA, devueltos como JSON:

requests.post("https://api.brightdata.com/request",
    headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
    json={"zone": "serp_api2", "format": "raw",   # gl/hl fijan la configuración regional para que los resultados sean estables
          "url": "https://www.google.com/search?q=amazon+nova+act+sdk&brd_json=1&gl=us&hl=en"})
9 resultados orgánicos → 1. github.com/aws/nova-act · 2. nova.amazon.com/act · 3. docs.aws.amazon.com/nova-act …

Cualquier URL a markdown limpio listo para LLM (Web Unlocker), el mismo registro de medicamento de la FDA que nuestro agente alcanzó rellenando un formulario, obtenido directamente:

json={"zone": "web_unlocker", "format": "raw", "data_format": "markdown",
      "url": "https://www.accessdata.fda.gov/.../ApplNo=214836"}
→ 8,4 KB de markdown limpio, una llamada, sin navegador, sin manejo de CAPTCHA, sin Parseo.

Una fuente conocida al registro estructurado (API de Web Scraper), activa un colector prediseñado y obtén campos limpios, nunca la página. Ejecutamos el Scraper de Crunchbase para una empresa:

requests.post("https://api.brightdata.com/datasets/v3/trigger?dataset_id=gd_l1vijqt9jfj7olije",
    headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
    json=[{"url": "https://www.crunchbase.com/organization/anthropic"}])   # -> snapshot_id, luego sondear
→ 89 campos estructurados (empleados, sede, rango CB, estado, financiación …),
  listo en ~70s, sin navegador, sin agente, sin 3,4 MB de página, sin Parseo.

El contraste es la arquitectura. El agente era la herramienta correcta aquí porque tenías que actuar para llegar a los datos. No existía ninguna URL, así que buscó en el formulario y navegó hasta la solicitud 214836. Una vez que existe una URL, o necesitas resultados de búsqueda o registros masivos de esquema conocido, no manejas un navegador. Llamas a la capa de datos. Es más determinista, más rápido y más barato, con mucho menos del presupuesto de fiabilidad del agente. Nova Act descubre y actúa. La capa de datos de Bright Data recupera a escala.

El agente llama directamente a las herramientas de Bright Data

Las integraciones hasta ahora están orquestadas a mano. Llamamos a SERP y Web Unlocker, luego le dimos al agente un navegador. Hay una integración más estrecha. Le das a Nova Act el servidor Web MCP de Bright Data como herramientas, y el agente mismo decide cuándo buscar, raspar o descubrir. Nova Act se ejecuta en el framework Strands de AWS, así que acepta herramientas MCP directamente:

from strands.tools.mcp import MCPClient
from mcp import StdioServerParameters
from mcp.client.stdio import stdio_client

bd_mcp = MCPClient(lambda: stdio_client(StdioServerParameters(
    command="npx", args=["-y", "@brightdata/mcp"], env={"API_TOKEN": BRIGHTDATA_TOKEN})))

with bd_mcp:
    tools = bd_mcp.list_tools_sync()          # search_engine, scrape_as_markdown, discover, batch…
    with NovaAct(starting_page="https://example.com", tools=tools,
                 cdp_endpoint_url=endpoint, cdp_headers=headers) as nova:
        nova.act_get("Use the search_engine tool to find 'Amazon Nova Act SDK'; "
                     "return the top result's URL.", schema=Out.model_json_schema())

Lo ejecutamos, y el propio rastro del agente lo muestra. “La llamada a la herramienta fue exitosa y devolvió información de la búsqueda. El principal resultado orgánico es ‘https://github.com/aws/nova-act’…” y devolvió {'top_result_url': 'https://github.com/aws/nova-act'}. El agente eligió la herramienta search_engine de Bright Data él mismo, Bright Data ejecutó la búsqueda, y el agente usó el resultado. Tomó una llamada act, aproximadamente 32s, sin raspar una página de búsqueda en la que un agente de navegador probablemente sería bloqueado de todas formas.

Esa es la diferencia entre usar dos herramientas juntas y un agente que llama al otro él mismo. El agente obtiene cinco herramientas directamente en esta ejecución: search_engine, scrape_as_markdown, search_engine_batch, scrape_batch y discover. Eso es un camino limpio y en cumplimiento para los trabajos que un agente de navegador hace peor: búsqueda y recuperación masiva.

El pipeline combinado, amplitud y profundidad

Cada componente hasta ahora funciona solo. Combinados, construyen un registro de inteligencia estructurado y fundamentado sobre un tema. Extraes amplitud de la web abierta, y profundidad de una fuente autorizada bloqueada por formularios. Lo ejecutamos en medicamentos GLP-1, una categoría farmacéutica de alto perfil:

# 1. AMPLITUD  , La API SERP de Bright Data descubre fuentes autorizadas   (sin navegador)
sources = serp_api("Ozempic semaglutide")[:3]
# 2. OBTENCIÓN    , Web Unlocker de Bright Data extrae la fuente principal como markdown (sin navegador)
context = web_unlocker(sources[0])
# 3. PROFUNDIDAD    , Nova Act rellena el formulario de Drugs@FDA para el registro autorizado (agente)
fda     = nova_act_fda("semaglutide")        # verificado contra el DOM en vivo

Salida real de extremo a extremo:

{
  "web_sources": ["ozempic.com", "mayoclinic.org/…semaglutide…", "accessdata.fda.gov/…/209637lbl.pdf"],
  "web_context_chars": 59270,
  "fda_authoritative": {"drug_name": "OZEMPIC", "active_ingredient": "SEMAGLUTIDE",
                        "application_number": "209637", "marketing_status": "Discontinued"},
  "fda_grounded": true
}

Cada mitad hizo algo que la otra no podía. La capa de datos buscó en la web abierta en dos llamadas a la API y devolvió tres fuentes autorizadas y 59 KB de contexto limpio listo para LLM, sin navegador y sin agente. El agente fue donde la capa de datos no podía llegar por sí sola. Rellenó el formulario de búsqueda de la FDA y navegó hasta el registro regulatorio autorizado, solicitud 209637, estado Discontinued para esa fila de producto, datos detrás de un formulario sin URL.

Y los dos se confirman mutuamente. La capa de datos devolvió de forma independiente la etiqueta de la FDA 209637lbl.pdf para el mismo número de solicitud que el agente alcanzó actuando. La amplitud confirma la profundidad.

Esta ejecución también muestra un fallo que planificas. El paso de la FDA del agente falló con el nombre de marca “Ozempic”, con ActAgentFailed tres veces, y tuvo éxito con el ingrediente activo “semaglutide”. Ese es el costo de fiabilidad del terreno. Es por eso que verificas con fda_grounded: true y presupuestas reintentos.

El mismo pipeline, una industria diferente

Esto funciona más allá de los productos farmacéuticos, y lo verificamos. Ejecutamos el pipeline idéntico en una industria diferente, cumplimiento financiero. SERP encontró la presencia web de la empresa, su propio sitio y un perfil de datos financieros. El agente navegó por BrokerCheck de FINRA (una aplicación Angular más difícil que el formulario de la FDA) hasta el registro regulatorio autorizado de un corredor-distribuidor: nombre de la empresa, número CRD, regulador y recuento de divulgaciones. Se fundamentó en un reintento.

De farmacia a finanzas, el mismo pipeline funcionó sin cambios de código más allá de la consulta y el esquema. Debería extenderse de la misma manera a precios competitivos, Estudio de mercado y monitoreo de seguridad de productos. La capa de datos maneja la amplitud y la escala, el agente maneja la profundidad bloqueada, y los campos del agente están fundamentados contra la página en vivo.

De un registro a un mercado

También escala de un registro a un mercado. Ejecutamos el pipeline idéntico en el mercado de medicamentos GLP-1 y obtuvimos un conjunto de datos competitivo estructurado. La capa de datos manejó la amplitud mientras el agente proporcionó el registro autorizado de la FDA de cada medicamento:

Ingrediente activo Marca FDA Solicitud # Estado Fuente principal (SERP)
semaglutide OZEMPIC 209637 Prescription drugs.com
tirzepatide MOUNJARO 215866 Prescription ncbi.nlm.nih.gov
liraglutide LIRAGLUTIDE 212552 Prescription drugs.com

La ejecución del mercado incluso reveló una discrepancia en vivo. La solicitud 209637 leyó Discontinued en la ejecución de registro único anterior y Prescription en esta tabla. Una solicitud de la FDA puede contener varios registros de productos con diferentes estados, así que cada lectura del agente es una instantánea de una fila. Esa es exactamente la razón por la que verificas cada lectura.

El reCAPTCHA no planificado

Un momento que no habíamos planificado hizo el caso de la arquitectura por sí solo. En dos de las tres búsquedas, el sitio de la FDA presentó un reCAPTCHA al agente.

Captura de pantalla de un desafío reCAPTCHA presentado al agente en el sitio Drugs@FDA, a mitad de ejecución

El reCAPTCHA real que el agente encontró en Drugs@FDA, capturado a mitad de ejecución. El guardián de Nova Act se negó a resolverlo. La sesión aún llegó al registro, porque se ejecuta en la Browser API de Bright Data.

El guardián de Nova Act se negó a tratarlo como un rompecabezas a resolver. De su rastro, palabra por palabra, “No debo suplantar a un humano, ni desviarme siendo uno resolviendo captchas o cualquier otro desafío.” Ese es el comportamiento que quieres de un agente autónomo.

Aun así llegó, porque la sesión se ejecuta en la Browser API de Bright Data. Un navegador local sin procesar ni siquiera pudo cargar el sitio de la FDA. Ese navegador agotó el tiempo dos veces en 90 segundos, aunque llegó a example.com bien en la misma ejecución. No llegó ni al CAPTCHA ni a los datos. La sesión de Bright Data llegó al registro.

Así que la división del trabajo es real y verificada. El agente no resuelve CAPTCHAs. No lo hará, y no debería hacerlo. La capa de datos no puede navegar el formulario. Solo el agente en Bright Data termina el trabajo.

El CAPTCHA es intermitente, y una ejecución sin procesar posterior no tuvo ninguno. Esas dos búsquedas del agente con CAPTCHA tomaron aproximadamente 1m50s y 2m37s de fricción real. El conjunto de datos tiene tres filas, pero el patrón se mantiene para todo un mercado.

Eso es Nova Act y Bright Data combinados. Ninguna herramienta lo resuelve sola.

Limitaciones

  • Nova Act todavía es temprano. A mediados de 2026 es una vista previa de investigación, solo en inglés, con un nivel gratuito que limita tus interacciones. Imprime “Amazon recopila datos sobre las interacciones en esta versión” en cada ejecución. La producción está acoplada a AWS, con IAM, S3 y Bedrock AgentCore. Confirma los términos y precios del nivel de producción con AWS antes de construir algo crítico sobre él.
  • El agente es frágil en sitios de consumidores con muchos popups. En booking.com, el ActActuationError fue el agente luchando contra la página, no Bright Data fallando en servirla. Prefiere URLs de resultados directos, descarta popups explícitamente, confía en el presupuesto de reintentos, o descarga a la capa de datos.
  • El cumplimiento tiene dos lados. Es el guardián que quieres, pero los objetivos restringidos significan un paso de Gerente de cuenta o Verificación KYC, así que planifica el tiempo de espera. Y la legalidad del Scraping web para IA es disputada en 2026, con fallos de datos públicos emblemáticos, la Ley de IA de la UE y demandas de derechos de autor aún en curso. Los datos públicos no son permiso automático, así que mantén a tu equipo legal involucrado.
  • La detección es una carrera armamentística. Las huellas digitales de agentes y el pago por rastreo siguen escalando. Mantenerse al día es un trabajo continuo, que es exactamente por qué la capa es una dependencia gestionada en lugar de una solución única.
  • Un navegador autónomo es una superficie de ataque. Las páginas pueden contener inyección de prompts que dirige al agente, y los propios documentos de Nova Act lo señalan. Limítalo. Usa listas de URLs permitidas y bloqueadas, y mantenlo alejado de páginas que no necesita. Maneja entradas sensibles como credenciales y pagos a través de Playwright directo con nova.page, en lugar de dejar que el modelo las escriba.

Próximos pasos

Cambia Nova Act por el agente del próximo año y la división sigue aplicando: la capa de debajo es la parte duradera. Así que empieza clasificando el trabajo, no la herramienta. Si el objetivo tiene una URL estable o un colector prediseñado, envíalo a la capa de datos y omite el navegador. Reserva Nova Act para lo que necesita una acción: un formulario que rellenar, un camino de múltiples pasos, un portal sin Scraper detrás.

Para cualquier cosa que planees ejecutar más de una vez, establece esto desde la primera sesión:

  • Mueve las credenciales en línea de la zona a un encabezado Authorization: Basic, y añade tu IP a la lista de IPs permitidas de la zona. Omite cualquiera y obtienes Invalid URL o un cuerpo vacío con la razón en los encabezados de respuesta.
  • Fuerza una ventana gráfica de 1600×900 en la página conectada, y crea logs_directory antes de que comience la ejecución.
  • Fundamenta cada campo extraído contra nova.page en la misma sesión, y presupuesta 1,2 a 1,5× para reintentos.

Cuando una zona deja de seguir el ritmo, aumenta su límite de concurrencia antes de culpar al agente. Mueve la recuperación masiva a la API SERP, Web Unlocker, o una API de Web Scraper. La Browser API y Web MCP ambos se envían con un nivel gratuito, así que puedes probar la división antes de comprometerte. Los objetivos restringidos son una conversación con el Gerente de cuenta, no una solución alternativa.

El script ejecutable para cada demo aquí está en el repositorio complementario. Clónalo, apúntalo a tu propio objetivo, y observa qué mitad de la división necesita realmente tu trabajo.

Preguntas frecuentes

¿Qué es Amazon Nova Act?

Amazon Nova Act es un SDK de AWS para construir agentes de navegador en Python. Divides un flujo de trabajo en comandos pequeños y fiables: act() para acciones y act_get() para extracción tipada. Maneja un Chromium real a través de Playwright. A mediados de 2026 es una vista previa de investigación.

¿Funciona Nova Act con Bright Data?

Sí, a través del Chrome DevTools Protocol. Nova Act se conecta a la Browser API de Bright Data a través de cdp_endpoint_url y cdp_headers. El problema de configuración es que Playwright moderno rechaza la URL wss:// con credenciales en línea, así que mueve las credenciales a un encabezado Authorization: Basic y fuerza una ventana gráfica de 1600×900.

¿Puedo usar un Proxy con Nova Act?

No con el parámetro nativo proxy cuando te conectas a través de CDP. Nova Act lanza ValidationFailed con el mensaje Cannot specify a proxy when connecting over CDP. Conéctate a la Browser API de Bright Data a través de CDP en su lugar, donde el desbloqueo, el geo-enrutamiento y el manejo de CAPTCHA ocurren del lado de Bright Data.

¿Está Nova Act listo para producción?

A mediados de 2026 es una vista previa de investigación, solo en inglés, con un nivel gratuito medido. La producción se ejecuta en AWS con IAM, S3 y Bedrock AgentCore. En nuestras ejecuciones fue fiable en sitios cooperativos y estructurados y frágil en los hostiles de consumidores. Confirma los términos y precios de producción con AWS antes de construir sobre él.

¿Cuánto cuesta ejecutar un agente de navegador de esta manera?

La Browser API de Bright Data factura aproximadamente $8/GB de pago por uso (mediados de 2026). Una página pesada movió aproximadamente 3,4 MB: aproximadamente $27 por 1.000 páginas antes de reintentos. Presupuesta 1,2 a 1,5× encima. Una página ligera está más cerca de $1,60 por 1.000. La inferencia de Nova Act no tiene precio público, así que para trabajo masivo usa la capa de datos, no un navegador.

¿Por qué no usar mi propio navegador headless y proxies?

Los modos de fallo medidos son solo la mitad de la respuesta. Manejar un navegador es pesado, frágil en la actuación de múltiples pasos y no determinista. Pero la mitad que es más difícil de ejecutar tú mismo es la geografía, el cumplimiento y la escala: una carrera armamentística que nunca termina. Una capa de infraestructura la ejecuta para que tu ingeniería no tenga que hacerlo.

¿Cuándo debo usar el agente, no la capa de datos?

Si el trabajo es una extracción fija de esquema conocido, usa una API de Web Scraper, que devuelve el registro sin página y sin costo de inferencia. Si necesita razonamiento que un Scraper no puede capturar (navegación de múltiples pasos, envío de formularios, lógica condicional), usa el agente. En sistemas reales los dos se componen.