1. A fetch-and-clean API
Give it a URL, get back readable text. Fast, cheap, and enough for a great deal of work. The limit is the one that bites later: it can only reach pages that would have answered a plain HTTP client anyway. Choose it if your sources are documentation, blogs and open APIs.
2. A rendering API
The same, plus a headless browser, so JavaScript-built pages work. This covers most modern sites. What it usually does not cover is a site that actively refuses automation, because a headless browser in a datacentre range is exactly what such a site is looking for.
3. A hosted browser you drive
A remote Chrome you connect to and control. Maximum power and maximum work: you write the automation, you handle the sessions, you decide what is safe. Choose it if you are building the automation layer yourself and want nothing in the way.
4. A permissioned agent surface
A browser your agent drives through a small set of tools, behind a permission model - what Unfenced is. The difference from (3) is not capability but authority: what stops the agent, what it may act on, where the secrets live, and what you can review afterwards.
The questions worth asking
- Can it reach a signed-in page? If yes, ask the follow-up that matters: does your password pass through the model? It should not.
- What stops the agent? An agent that can act on any site is one bad instruction away from acting on the wrong one.
- What does a failure tell you? A status code is not an instruction. An agent needs to know whether to retry, give up, or ask a human.
- Does the session survive? Signing in once is only useful if the next run is still signed in.
- Can you see what happened? For anything that acts rather than reads, "what did it do at 3am" needs a real answer.
We have deliberately not put competitors' names and feature ticks on this page. Those tables are out of date within a month and are usually written to be won. The questions above are the ones we would ask, and they are worth asking of us too.