This article presents a cleaner pattern for agent web access by splitting it into three separate lanes—search, fetch, and browser—and using a reader subagent to keep raw pages out of the main context, significantly reducing token usage and context pollution.
Most agent web-access setups I see collapse three different jobs into one vague “web tool.” That usually turns into: Search for something Fetch a page Dump the page into the main agent context Hope the agent extracts the useful part That works, but it is wasteful. The problem is not only token cost. It is context pollution. Raw pages contain nav bars, cookie banners, scripts, headers, footers, analytics, duplicated layout, and a lot of text the agent does not need to carry forward. A cleaner pattern is to split web access into three lanes: 1. Search Search should only find candidate URLs. It should not be responsible for reading full pages. Good behavior: return URLs return titles/snippets cache repeated queries avoid expensive fan-out unless needed Search answers: “Where should I look?” It should not dump five full pages into the main context. 2. Fetch Fetch should read a known URL and convert it into clean markdown before the model sees it. This is where the biggest context savings happen. In one test, the same page was: raw HTML: 9,541 tokens clean markdown: 1,678 tokens That is an 82% reduction before changing the prompt or model. The rule: Do not hand raw HTML to the main agent unless you have a specific reason. Fetch answers: “What does this page say?” 3. Browser Browser automation should be reserved for stateful interaction. Use it when the task actually requires: clicking scrolling logging in filling forms handling dynamic UI interacting with a live app Do not use a browser just to read a normal documentation page. Browser answers: “What happens when I interact with this site?” The main boundary The most important part is not the tool choice. It is where the reading happens. Instead of letting the main agent ingest the fetched page directly, run page-reading inside a contained reader/subagent. The reader/subagent gets the noisy content. The main agent only gets the distilled result: answer relevant excerpt citations/source URL no full-page dump So the flow becomes: ```text Main agent → search for URLs → fetch URL as markdown → reader subagent extracts the relevant slice → main agent receives only the clean result
This paper proposes a principled redesign of the World Wide Web to accommodate AI agents as primary intermediaries, addressing access rights, rate limiting, and standardized agent identification, moving beyond human-centric assumptions.
This article explains the key difference between computer-use agents that operate on full desktop interfaces using pixel screenshots and browser-use agents that can leverage the DOM's hidden structure, making the former a harder technical problem.
barebrowse is a tool that generates pruned ARIA snapshots from web pages, reducing token consumption for local AI models by stripping boilerplate and ads, and reusing existing browser cookies.
Browser Use describes two patterns for isolating AI agents that execute code: isolating the tool vs isolating the agent. They implemented the agent isolation pattern using Unikraft micro-VMs on AWS, achieving secure, scalable, and disposable sandboxes.