Guide · Fetch, search or browser
Browser agent vs fetch: which tool each agent step needs
When an agent step needs a fetch tool, a search API, a browser agent or computer use, compared on what each can read, cost, failure modes and risk.
Guide
This article was drafted with AI assistance from the sources listed below and edited and published by Teneo Labs. Disclosure: this site is run by Teneo Labs, the company behind Live Web Data API, which this article mentions.
| Criterion | Fetch tool | Browser agent | Computer use |
|---|---|---|---|
| Input | One URL | A goal and a start page | A goal and a screen |
| Reads JavaScript pages | Only with a render option | Yes | Yes |
| Clicks, types, logs in | No | Yes | Yes, in any app |
| Speed and cost per page | Lowest | Higher | Highest |
| Risk if steered by a page | Reads the wrong thing | Can act on the site | Can act on the machine |
"Give the agent a browser" sounds like the most complete answer to web access. For most steps it is the most expensive one. An agent that needs to read a public documentation page does not need to drive Chrome; an agent that needs to change a setting behind a login cannot do it with a fetch. The useful question is not which tool the agent gets, but which tool each step needs.
The four options
Fetch tool. Takes a URL, returns the page's main content. Fast and cheap per page, read-only, and easy to cap and log. A static fetch does not run JavaScript, so pages that build their content in the browser come back empty or as an error.
Search API. Takes a query, returns ranked results with snippets. It answers "which page?", not "what does this page say?". Agents that guess URLs usually need search, not a better fetch.
Browser agent. A model drives a real browser: it loads pages, runs JavaScript, clicks and types. Open-source projects such as browser-use make this practical. It reads almost anything a person can see and can complete multi-step flows, at the cost of time, tokens and a larger attack surface.
Computer use. The model operates a whole desktop from screenshots, as in Claude's computer use tool. It works with any application, not just web pages, and is the slowest and most permission-heavy option. Provider docs recommend running it in an isolated environment.
A decision per step
Ask three questions in order:
- Does the step need to act (click, submit, log in, buy)? If yes, it needs a browser agent or computer use, plus a risk review and, usually, human approval. Check the site's terms first; many prohibit automated account actions. This is not legal advice.
- Does the agent know the URL? If not, start with search.
- Is the content in the HTML? If yes, fetch. If the fetch reports that the page needs JavaScript, fall back to a browser for that step only.
For research, support and documentation agents, search plus fetch can usually cover most steps; keep the browser for the steps that need it.
Fetch first, fall back on a signal
Design the fallback around an explicit signal, not a guess from empty text:
› step 4 call get_page(url="https://app.example.com/status")
result error CRAWL_NOT_RENDERED
"The page has no usable text: it needs JavaScript
rendering... Try another source..."
› step 5 plan status page is client-rendered; is there a static source?
› step 6 call get_page(url="https://example.com/status/history")
result success · markdown
Try a static alternative first (a docs page, an RSS feed, a public status history). Hand the step to a browser agent only if no static source exists and the task justifies the cost.
Built-in provider tools vs an external fetch API
Model providers now ship hosted web tools, such as Claude's web fetch tool with domain filters and a content limit. They are the fastest way to start. An external fetch API is worth it when you need the same tool across several models or frameworks, your own error tags and retry rules, per-URL statuses for multi-URL reads, or one place to meter usage across agents.
Live Web Data API, made by the publisher of this site, is an external fetch tool and only that. It reads public pages as Markdown, text or HTML; it does not search, click, log in or fill forms, which its Acceptable Use Policy also prohibits on third-party sites. Its MCP tool is a static fetch: pages that need JavaScript return CRAWL_NOT_RENDERED at 0 credits, which makes it a clean signal for the fallback above. Through the REST API and SDKs, render reads such a page in a browser, still read-only, so a fallback for reading does not have to be a browser agent. You can check whether a static fetch is enough for a given URL in the playground.
Where this breaks
- Mixed pages. Some pages ship partial content in HTML and the rest via JavaScript. A fetch succeeds but misses data. Add evals with known answers for the sites your agent depends on.
- Browser agents as a default. Giving every step a browser raises cost and risk for little gain. Keep it scoped to the steps that need it.
- Acting on untrusted pages. A browser agent that reads and acts in one context combines the risks described in the prompt injection guide. Separate the reading step where you can.
For wiring a fetch tool into a specific framework, see the framework recipes.
Frequently asked questions
When does an AI agent need a browser instead of a fetch tool?
When the content only appears after JavaScript runs, or when the step needs interaction: clicking through a flow, filling a form or logging in. If the page shows its content in the HTML and the step only reads, a fetch tool is faster, cheaper and easier to control.
Is a search API the same as a fetch tool?
No. A search API takes a query and returns results with snippets; a fetch tool takes a URL and returns the page. Use search to find candidate pages and fetch to read the one you need. Many agents need both, as two separate tools.
Should I use a provider's built-in web fetch or an external fetch API?
A built-in tool is the quickest start and runs on the provider's side. An external API gives you the same tool across models and frameworks, your own error handling and caps, and one place to log usage. Pick by portability and control, not by habit.
Can one agent use both a fetch tool and a browser?
Yes, and that is often the best design: fetch first, and fall back to the browser only for steps where the fetch reports that the page needs JavaScript or the task needs interaction. Keep the browser's extra permissions in mind when you review risk.
Sources
- browser-use (GitHub) (Documentation)
- Computer use tool (Claude Docs) (Documentation)
- Web fetch tool (Claude Docs) (Documentation)