Búsqueda web en el agente: donde profundidad y motor importan más que el modelo

La discusión sobre la búsqueda web en agentes está atascada en la pregunta equivocada. Todo el mundo pregunta qué modelo de lenguaje usar. La pregunta que decide el resultado es otra: cuántas fuentes va a tocar ese agente, y con qué motor. En el benchmark del 2026-08-12, que comparó los motores Exa, Parallel y Perplexity en la tarea de buscar para un agente, el resultado cambió menos cuando el modelo de razonamiento cambió que cuando el presupuesto de exploración cambió. El modelo es la última capa que decide. La profundidad y el motor deciden antes, y ya lo decidieron todo.

¿Por qué el resultado de un agente que busca en la web sufre más con el presupuesto que con el modelo?

Porque el LLM solo interpreta el contexto que ha llegado hasta él, y es el presupuesto de búsqueda el que decide qué contexto llega, lo que coloca la recolección delante del razonamiento en la cadena de valor del resultado. Un modelo brillante sobre un conjunto de fuentes corto y mal elegido produce una respuesta segura y errónea. Un modelo mediano sobre un conjunto amplio y bien curado produce una respuesta modesta y correcta, que es lo que paga la cuenta en producción. El cuello de botella no está en la capa de razonamiento, está en la capa de recolección.

Un agente que consulta la web toma tres decisiones antes de que el modelo escriba una frase. Elige el motor, la profundidad y el tamaño del contexto que va a llevar al razonamiento. Ninguna de las tres las toma el modelo. Las toman la configuración de la herramienta, el despliegue de function calling y el techo de tokens que la aplicación impone.

Esto no debería sorprender a nadie que haya visto a un agente alucinar con seguridad sobre un hecho que una segunda fuente desmentiría en diez segundos. La segunda fuente simplemente no existía en la búsqueda hecha con profundidad mínima.

El costo también refuerza esta lectura. Cada consulta adicional cuesta en tokens de búsqueda, en latencia y, cuando el motor es de pago, en dinero por llamada. El presupuesto de búsqueda es, al final del mes, una partida contable. La herramienta que más gasta en el bucle del agente es la búsqueda web, y es la herramienta que casi nadie gobierna.

¿Qué mostró realmente el benchmark de motores de búsqueda para agentes?

Comparó tres motores, Exa, Parallel y Perplexity, en la tarea de alimentar a un agente con contexto para responder a una pregunta, y, manteniendo el mismo razonamiento, cambiar de motor desplazó la puntuación unos 10 puntos, mientras que la distancia entre un modelo de razonamiento de punta y uno eficiente en costo llegó a unos 15 puntos. El motor importa, pero importa menos que el modelo. Y los dos juntos mueven menos que la profundidad del presupuesto de búsqueda. Cada motor tiene un modo propio de cortar la web, de ordenar la relevancia y de devolver contexto, y ese modo es el que decide la materia prima del agente.

La forma en que se diseñó la prueba importa. No fue una prueba de "quién encontró el enlace correcto". Fue una prueba de "quién devolvió el contexto que el agente necesitaba". Un motor puede encontrar una fuente perfecta y devolverla enterrada en un paquete ruidoso; otro puede encontrar una fuente regular y devolverla limpia. Para el agente, la segunda es más útil, porque lo que llega al razonamiento es un texto truncado, no un ranking de enlaces para hacer clic.

Observación de lectura obligatoria antes de tomarse los números en serio: los resultados son reportados por el proveedor que ejecutó la prueba, no están verificados de forma independiente. Así que lo que vale extraer no es el ganador absoluto, es la dirección. Y la dirección reconciliada del benchmark con el título del propio proveedor, "aunque el motor importa, el modelo importa más", apunta a un hilo único: cambiar solo el motor, manteniendo el modelo, es tocar menos que cambiar el modelo, y cambiar el modelo puro, sin tocar el presupuesto de búsqueda, es dejar el mayor beneficio sobre la mesa. La calidad del resultado nace de la combinación, no de la elección de un único componente.

Es aquí donde la conversación técnica se vuelve conversación de arquitectura. Si el motor y la profundidad dominan, entonces la empresa no debería fijar un único motor en el código. Debería tener la capacidad de cambiar de motor por llamada, por costo, por fiabilidad y por exigencia de profundidad de la consulta en cuestión. Eso es enrutamiento. Solo que el enrutamiento, en este caso, no cubre el modelo, cubre la herramienta.

¿Por qué el presupuesto de búsqueda pesa más que la elección del modelo de lenguaje?

Porque todo el valor de un modelo de razonamiento se desperdicia cuando el contexto que recibe es poco profundo, ruidoso o sesgado. Un LLM excelente no resuelve la ausencia de información. Escribe una frase demasiado buena sobre información demasiado pobre, y ese es el peor resultado posible de producción, porque es indetectable en el flujo.

Piense en lo que hace la profundidad en tres niveles. En el nivel uno, el agente consulta una única página y responde; en el nivel dos, abre los enlaces de referencia de esa página. Es ahí, en el nivel dos, donde ya nace materia nueva. En el nivel tres, sigue encadenamientos entre dominios confiables y cruza versiones. Cada nivel cuesta más en latencia y en tokens de búsqueda, pero cada nivel elimina una clase de error que los niveles anteriores ni siquiera pueden nombrar.

La latencia es el adversario silencioso. Una búsqueda con profundidad alta puede tardar decenas de segundos, y el usuario de un agente B2B no tiene media hora de paciencia para una consulta de rutina. Así que la decisión no es "buscar más", es "buscar más cuando la pregunta lo merece". Una pregunta de facturación merece profundidad alta. Una pregunta de relleno de formulario no. Decidir cuándo escalar la profundidad es una política, y las políticas son exactamente lo que un gateway de IA sabe aplicar.

El costo por consulta cierra el argumento. Cada nivel de profundidad multiplica las llamadas al motor y los tokens de contexto. En una operación con miles de consultas al día, la diferencia entre la profundidad mínima y la alta es la diferencia entre una cuenta pequeña y una cuenta que exige firma de dos niveles, la misma dinámica de composición de costo del costo operativo del gateway en producción. Sin un techo de gasto en la búsqueda, el presupuesto de búsqueda es infinito hasta el día en que llega la factura.

¿Cómo se comporta la búsqueda web como herramienta dentro del bucle del agente?

Se comporta como cualquier otra herramienta expuesta por function calling o por un protocolo de conexión, un punto de entrada que el agente decide llamar en medio de su razonamiento. Para el gateway, la búsqueda web no es ontológicamente distinta de una llamada de API de cálculo, de base de datos o de cualquier conector. Es una herramienta con una firma, un costo y un perfil de comportamiento.

Y ese es el detalle que casi todo el mundo pierde. Cuando la búsqueda web está dentro del bucle, se llama bajo demanda, a veces decenas de veces en una única respuesta. Cada llamada es una decisión de enrutamiento esperando a suceder: qué motor atiende esta consulta, con qué profundidad, dentro de qué techo de gasto. Hoy esa decisión se toma por defecto, en el código del agente, fijada en el momento en que alguien eligió el motor y no volvió a mirarla.

El protocolo de conexión hizo ese diseño aún más maduro. Un agente conectado por un patrón de intercambio de mensajes entre sistemas, el mismo que acerca MCP y herramientas en el bucle de un agente, expone herramientas de forma estructurada, con descripción, parámetros y límites legibles por máquina, el modelo que el protocolo MCP generaliza para cualquier sistema. Eso significa que la capa que intercepta las llamadas del agente puede ver cada herramienta, cada parámetro y cada costo previsto antes de dejar pasar la llamada. La visibilidad existe. Lo que falta es aplicar política a esa visibilidad.

Es aquí donde el gateway deja de ser un enrutador de modelo y pasa a ser la capa que gobierna la llamada entera del agente. La regla no cambia porque el objetivo ahora sea una herramienta. Solo cambia el objeto.

¿Cómo se extiende la política de enrutamiento del modelo a la herramienta de búsqueda?

La misma política que el gateway aplica al LLM, enrutar por costo, por fiabilidad, por latencia y por profundidad, es aplicable a la herramienta de búsqueda, con los mismos criterios y con la misma matemática de fallback. El gateway registra el desempate por costo por consulta, el failover automático cuando un motor se degrada y el techo de gasto por clave, por proyecto o por agente, exactamente igual que hace por token. La extensión no pide un producto nuevo. Pide aplicar la política existente a un nuevo objetivo, del mismo modo que la evaluación del endpoint funciona como política de enrutamiento del modelo.

Considere el enrutamiento por costo. Los motores de búsqueda para agentes cobran por consulta en escalas que pueden diferir varias veces. Para una consulta de bajo valor, el enrutador elige el motor barato. Para una consulta que firma un contrato, el enrutador elige el motor caro, porque el costo de la respuesta equivocada es mayor que el costo de la consulta correcta. Esa es la misma lógica de "qué modelo para cada request", solo que a nivel de la herramienta.

El enrutamiento por fiabilidad sigue el mismo diseño. Un motor se mantiene estable durante tres días y se degrada un miércoles. Con failover de herramienta, el tráfico de la búsqueda migra en milisegundos a un motor de reserva, y el usuario final no ve nada más que una respuesta que llegó a tiempo. Sin failover, el agente devuelve un error de motor que parece un error de producto.

El enrutamiento por profundidad es el más nuevo y el más descuidado. Desempata el conflicto entre calidad y latencia: pregunta simple, profundidad mínima; pregunta de consecuencia, profundidad alta. Para eso el gateway necesita leer la intención de la llamada, lo que ya hace en la capa de clasificación de intención que usa en la elección de modelo. La herramienta hereda la clasificación que el modelo ya tenía, y ese conjunto de criterios es el que debe estar sobre la mesa de quien todavía está evaluando cómo elegir un gateway.

¿Qué cambia en la práctica al enrutar solo el LLM en lugar de enrutar el modelo y la herramienta?

Cambia lo que el gateway ve, lo que gobierna y lo que puede auditar en cada llamada del agente. Enrutando solo el LLM, la empresa domina el costo por token y el failover del razonamiento, pero deja la búsqueda, que es la parte más cara del bucle, funcionando en un único motor, con profundidad fija y sin techo. Es gobernar la cuenta más pequeña e ignorar la más grande. La más grande decide el riesgo.

La columna de la derecha es la que aplica el Nexforce Router. El Router gobierna el costo y la fiabilidad de cada llamada del agente, incluida la herramienta de búsqueda, con techo de gasto por clave, por proyecto o por agente y con failover que migra el tráfico en milisegundos. No elige el motor por usted. Aplica la misma política de enrutamiento que ya aplica al LLM.

El argumento práctico se cierra en una frase: quien enruta solo el modelo está resolviendo el problema del 20 % del costo y el 20 % del riesgo, mientras que la factura ruidosa y el punto único de fallo del bucle están en la búsqueda. La extensión de la política a la herramienta es la diferencia entre gobernar la llamada y gobernar solo su apariencia.

¿Cómo empezar a aplicar enrutamiento de herramienta en la búsqueda web del agente?

Empezar no exige reescribir el agente. Exige cambiar un punto de integración e inspeccionar la herramienta. El camino es incremental y cabe en un sprint.

1. Listar las herramientas que el agente llama hoy y medir el costo de cada una, empezando por la búsqueda web, que suele ser la más cara.
2. Unificar la entrada de las llamadas en un único gateway, que pasa a ver el modelo y cada herramienta llamada dentro del bucle.
3. Definir la política de profundidad por tipo de pregunta, separando la consulta de rutina de la consulta de consecuencia.
4. Configurar el failover de motor para el caso de degradación, con un motor de reserva que absorba el cambio en milisegundos.
5. Fijar un techo de gasto por clave o por proyecto que cubra la búsqueda, y no solo el modelo.
6. Auditar las llamadas reales durante una semana y ajustar la clasificación de intención que decide la profundidad.

El paso seis es lo que separa un diseño de una política que funciona. La calidad del enrutamiento de herramienta viene de observar lo que el agente realmente llama, a qué costo, con qué fallos, y ajustar la regla. Sin la telemetría de las llamadas, el mismo tipo de trazabilidad que sostiene la observabilidad del LLM, el enrutamiento es una apuesta con buenos argumentos y ninguna evidencia.

Y hay un beneficio que no aparece en la tabla. Cuando la política cubre la herramienta, la misma decisión de enrutamiento que ahorra en la búsqueda barata e invierte en la búsqueda cara se convierte en la base de una auditoría completa de cada llamada. Cada llamada es rastreable, cada criterio de elección es explicable y cada failover deja un rastro. Para un comprador B2B que necesita explicar lo que hizo el agente, eso vale más que cualquier punto porcentual de calidad.

Preguntas frecuentes sobre la búsqueda web y el enrutamiento en agentes

¿No es el modelo de lenguaje el que decide la calidad de la respuesta del agente?

El modelo interpreta el contexto, pero el presupuesto de búsqueda decide qué contexto llega hasta él. Un buen modelo sobre fuentes poco profundas y mal elegidas produce una respuesta segura y errónea. Cambiar el modelo sin tocar la profundidad es dejar el mayor beneficio sobre la mesa: el motor aislado mueve el resultado menos que el modelo, y la profundidad del presupuesto mueve más que los dos.

¿Qué es el presupuesto de búsqueda de un agente?

Es el conjunto de elecciones de cómo el agente recopila información: qué motor de búsqueda usa, cuántas páginas y niveles de enlace recorre y cuánto contexto lleva al razonamiento. Cada nivel cuesta latencia, tokens y, en los motores de pago, dinero por consulta.

¿La búsqueda web dentro del agente es una herramienta enrutable como el LLM?

Sí. Dentro del bucle, la búsqueda es una herramienta expuesta por function calling o por un protocolo de conexión, con firma y costo. El gateway le aplica la misma política de enrutamiento que aplica al modelo: costo, fiabilidad, failover y techo de gasto.

¿Por qué el Nexforce Router gobierna la búsqueda web si es un enrutador de LLM?

El Router gobierna el costo y la fiabilidad de cada llamada del agente, incluidas las herramientas que llama dentro del bucle, y la búsqueda web es la más cara de ellas. Extiende la misma política de enrutamiento del LLM a la herramienta, sin convertirse en un producto de agentes.

¿Necesito reescribir el agente para enrutar la herramienta de búsqueda?

No. El camino une la entrada de las llamadas en el gateway, define la profundidad por tipo de pregunta, configura el failover de motor y fija un techo que cubra la búsqueda. El cambio es incremental y cabe en un sprint.

Referencias y lectura complementaria

El punto sobre ampliar la política de enrutamiento a las herramientas del agente, tratando la evaluación de la llamada como decisión de política, conversa directamente con la evaluación del endpoint como política de enrutamiento. Para quien está en la fase de compra, el guía de cómo evaluar y elegir un gateway de IA es la lectura de apoyo. La base de costo sobre la que sustenta esta cuenta está en el levantamiento sobre el costo operativo del gateway en producción. Para entender cómo las herramientas de un agente entran en el bucle por un patrón de mensajes entre sistemas, el texto sobre MCP y herramientas sigue el encadenamiento. Y la telemetría que hace funcionar el paso seis, rastrear cada llamada, es el corazón del guía de observabilidad del LLM. Cada uno sigue un hilo del argumento.

Un buen modelo no arregla un contexto malo

Existe una jerarquía manida de optimización que casi todos los equipos de IA descubren a la fuerza. Cambiar de modelo es fácil, escribir una mejor prompt es fácil, y medir cuánta información dejó la búsqueda sobre la mesa es lo que nadie hace. El mismo equipo que pasa seis semanas evaluando proveedores de modelo deja el motor de la búsqueda web fijado en una línea de código que nadie revisita, y es justamente ahí donde vive el peor costo y el peor riesgo del bucle del agente.

El enrutamiento de búsqueda no es un capricho de ingeniería. Es la misma disciplina que el equipo ya aplica al LLM, costo, fiabilidad, failover, techo, solo que aplicada a la herramienta que el bucle más usa y más gasta. La empresa que entiende esto no necesita elegir entre un motor caro y uno barato, ni entre profundidad alta y baja. Necesita una política que elija por ella, por llamada, mirando la intención, el costo y la consecuencia de cada pregunta.

El Nexforce Router existe para eso: gobernar el costo y la fiabilidad de cada llamada del agente, incluida la herramienta de búsqueda, con la misma política que ya gobierna el modelo. Quien enruta solo el modelo resuelve la mitad del problema. Quien extiende la política a la herramienta pasa a gobernar la llamada entera, de la intención a la última fuente tocada. El siguiente paso es cambiar el punto de integración y empezar a medir. Los datos harán el resto.