---
schema_version: "newruntime-agent-readable-v0.2"
type: "post"
stable_id: "post:browserbase-search-fetch-browser-routing"
slug: "browserbase-search-fetch-browser-routing"
title: "Agents Should Search, Fetch, And Browse As Separate Operations"
description: "Browserbase separates discovery, content retrieval, and browser interaction so research agents do not launch a full browser merely to obtain a list of URLs."
retrieval_nugget: "Browserbase separates discovery, content retrieval, and browser interaction so research agents do not launch a full browser merely to obtain a list of URLs. A browser agent can act on a page once it arrives, but many research tasks begin with a goal rather than a URL."
status: "published"
published_at: "2026-08-03"
updated_at: "2026-08-03"
record_date: "2026-08-03"
date_kind: "published_at"
topics: ["agents","web-research","browser-automation","agent-harnesses"]
source_urls: ["https://www.browserbase.com/blog/why-ai-agents-need-a-search-api"]
visuals: [{"id":"browserbase-search-fetch-browser-routing","kind":"editorial-diagram","role":"hero","src":"https://newruntime.com/images/posts/browserbase-search-fetch-browser-routing.webp","alt":"Hand-drawn branching decision path routing a research goal without a URL to search, a known URL needing content to fetch, and a page requiring login, clicking, or JavaScript to a browser session.","caption":"Discovery, extraction, and interaction have different costs and should remain separate tools in an agent runtime.","credit":"New Runtime synthesis from Browserbase","source_url":"https://www.browserbase.com/blog/why-ai-agents-need-a-search-api","generated_with":"gemini-3.1-flash-image","width":1600,"height":900,"legend":[{"label":"Search","description":"A goal without a URL becomes a ranked list of structured candidates."},{"label":"Fetch","description":"A known URL yields content without paying for an interactive browser session."},{"label":"Browser","description":"Login, clicking, and client-rendered state justify the full interaction runtime."},{"label":"Escalation","description":"Each candidate moves to a heavier tool only when the lighter operation is insufficient."}]}]
routes: {"html":"https://newruntime.com/posts/browserbase-search-fetch-browser-routing/","markdown":"https://newruntime.com/posts/browserbase-search-fetch-browser-routing.md","json":"https://newruntime.com/posts/browserbase-search-fetch-browser-routing.json"}
source_format: "markdown"
---

# Agents Should Search, Fetch, And Browse As Separate Operations

## Retrieval answer

Browserbase separates discovery, content retrieval, and browser interaction so research agents do not launch a full browser merely to obtain a list of URLs. A browser agent can act on a page once it arrives, but many research tasks begin with a goal rather than a URL.

A browser agent can act on a page once it arrives, but many research tasks begin with a goal rather than a URL. Browserbase argues that sending those tasks directly to a search-engine interface wastes a browser session on page rendering and DOM parsing when the desired output is only a list of links.

The scale of that mismatch is visible in Browserbase's own traffic. It reports 4.5 million requests to `google.com` through its proxies during one recent billing cycle. Each request represents a browser being used for discovery before the agent starts the work that needs interaction.

Browserbase Search instead returns structured URLs, titles, and optional publication metadata from a stateless API. Its SDK accepts a natural-language query and up to 25 results. A separate search interface also avoids binding retrieval to whichever model provider happens to supply a built-in search tool.

The useful architecture is a three-step escalation policy. Use Search when the agent has a goal but no URL. Use Fetch when a URL is known and only page content is needed. Start a browser when the page requires authentication, clicking, or client-side execution. A workflow can chain all three while quickly rejecting irrelevant pages before allocating browser concurrency.

The product details establish real operating limits: plans below Scale receive 1,000 search calls per month, a rate limit of two calls per second per project, and paid-plan overage listed at $7 per thousand calls at publication time. Production workflows still need retries, service-unavailable handling, and usage monitoring.

For New Runtime, this validates the scarcity rule already used in source monitoring. Cheap structured discovery should precede extraction, and extraction should precede browser automation. Tool choice becomes a deterministic cost and capability decision rather than a model habit.