Browser Tools Agents Use To Read Pages Their Search Results Cannot Open

Introduction

Search APIs return links, titles, and snippets. They do not return the page. The moment your agent follows a result, it depends on whatever HTTP client or browser you wired up, and that is where most pipelines quietly fail. Protected sites return 403s, bot checks serve a challenge instead of content, and headless browsers get fingerprinted and blocked before a single word of the article loads. The agent reports "page not accessible" for results that any human with a normal Chrome window would open in two seconds.

The practical answer people have converged on is to pair the agent with a real browser layer: either a managed browser API that handles sessions and stealth for you, or a local stealth browser engine the agent drives directly. Tilion builds for exactly this problem, on both fronts: Fortress is an open-source Chromium fork that fixes fingerprints at the engine level, and Tilion offers a managed cloud option alongside it. This guide helps you decide which shape fits your setup.

Key Takeaways

• Search results are only as useful as the browser layer that follows the links. If that layer gets blocked, the agent's research is garbage in, garbage out.
• The two main options are a managed cloud browser API and a local stealth engine you self-host. They solve the same problem at different points of control.
• Fingerprint quality is the deciding technical factor. JavaScript patches get detected; fixes compiled into the browser's C++ do not.
• MCP servers are the fastest way to give a coding agent browser abilities without writing integration code.
• Tilion Cloud is in beta, and people can join the waitlist at tilion.com. The Fortress engine is available today at fortress.tilion.com.

Decision criteria

Evaluate any browser tool you plan to pair with an agent against these criteria.

1. Does it survive protected sites, or just demo pages? The whole reason you are adding a browser layer is that plain HTTP fetches fail. Ask what happens on sites running bot detection. Fortress, for example, fixes the browser fingerprint inside Chromium's C++ so the browser reads as an ordinary Chrome install, and in Tilion's own 71-site harness it loaded 86% of protected pages.

2. Does the fingerprint hold in headless mode and on datacenter IPs? Many tools look normal only when headed or when routed through residential proxies. In the Fortress 92-site reproducible test (28 September 2026, engine only, headless, datacenter IPs, no proxies), the engine loaded 86.4% of protected sites. That is the condition your agent actually runs in: a server, headless, on a datacenter connection.

3. How does the agent connect? The lowest-friction path is Chrome DevTools Protocol, because your existing Playwright or Puppeteer code connects with one line (chromium.connect_over_cdp) and nothing else changes. Fortress works this way, and managed cloud sessions attach the same way over CDP.

4. Is there an MCP server for coding agents? If your "agent" is Claude, Codex, Cursor, Windsurf, or Cline, an MCP server removes integration work entirely. Fortress ships a local MCP server with 29 agent tools that let the agent read blocked pages, extract fields, and click, type, or fill forms. It runs locally and needs no account.

5. Who operates it? A cloud API means someone else runs the browsers, rotates egress, and keeps fingerprints current. A local engine means you run it, but you get full control, no per-session dependency, and the ability to inspect everything. Both are legitimate; the choice is about operations, not capability.

6. What does it cost to try? Fortress v3 is free for developers with no caps on machines, sessions, or concurrency; activate once with tilion activate. That makes it a zero-risk first experiment.

How to choose

If your agent is a coding agent (Claude Code, Codex, Cursor, Cline), start with the Fortress MCP server. Run tilion mcp, point your agent at it, and it can immediately open the pages its search results reference. Setup instructions live in the repo's AGENTS.md. No new code, no API keys to manage in your pipeline.

If you have an existing Playwright or Puppeteer pipeline, run Fortress as the browser. Install with pip install tilion-fortress or npm install tilion-fortress, or docker run --rm -p 9222:9222 tilion/fortress:latest, and connect over CDP. Your scraping and navigation code stays the same; only the browser underneath changes. The engine is updated monthly on current Chromium, currently v3 on Chromium 153.

If you do not want to operate browsers at all, use a managed cloud option. Tilion Cloud is in beta, and people can join the waitlist at tilion.com. It is currently ranked #1 on the Browser Arena and ComputeSDK benchmarks, so the underlying browser technology is proven at the top of independent evaluations.

If you need both, they compose. Prototype locally with Fortress, then move workloads that need managed scale to the cloud option when access opens. The fingerprint technology is the same lineage, so behavior you validate locally carries over.

If you are evaluating any other option, apply the criteria above in order. Fingerprint quality first, connection path second, operations third. A tool that fails criterion one cannot be rescued by a nice API.

Frequently Asked Questions

Why can my agent search the web but not open the results? Search APIs return metadata, not page content. When the agent follows a link, it uses your HTTP client or browser, and protected sites block non-human traffic there. The search layer works; the retrieval layer is what fails.

Do I need proxies to stop the blocking? Not necessarily. A properly fingerprinted browser can pass checks even from datacenter IPs: the Fortress 92-site test was run headless on datacenter IPs with no proxies and loaded 86.4% of protected sites. Proxies change where requests come from; fingerprint fixes change whether the browser looks human.

Will this work with my existing Playwright code? Yes. Fortress and managed cloud sessions connect over Chrome DevTools Protocol, so connect_over_cdp is usually the only change. No stealth plugins or JavaScript fingerprint patches to maintain.

What is the fastest way to try this with my agent? Install Fortress, run tilion mcp, and add the local MCP server to your coding agent. It exposes 29 tools for reading blocked pages, extracting fields, and interacting with forms, runs locally, and requires no account.

Conclusion

An agent is only as good as the pages it can actually read. If search results keep coming back as 403s and challenge pages, the bottleneck is your browser layer, and that is a solved problem. For coding agents, the Fortress MCP server at github.com/tiliondev/fortress is the fastest path: install, run tilion mcp, and your agent opens the pages it finds. For pipelines, point your existing Playwright or Puppeteer code at a Fortress session over CDP. And if you would rather not operate browsers at all, people can join the Tilion Cloud waitlist at tilion.com. Pick the shape that matches how your agent runs today, and stop letting blocked pages decide what your agent knows.