The 2026 default for "AI + web" is agentic browsing: give the model a browser, let it look-click-wait-extract per task. Watching it work feels like the future. Putting it in production teaches you its actual economics: every run re-perceives the same pages, every run pays tokens per page-turn, every run is a fresh roll of the dice on whether it clicks the same button it clicked yesterday. For exploration, wonderful. For repeated extraction — the daily dashboard pull, the per-item lookup, the scheduled monitor — it's the wrong shape entirely.
The older engineering instinct says: repeated work belongs in a tool, not in a steering wheel. Scrapewright is that instinct, productized — an open-source platform where an LLM builds a scraping service once, and everything afterward is a deterministic HTTP call your agent can make.
Build time (LLM, once): you describe the extraction in natural language. The wizard's AI opens the target page in your real browser, researches its structure in rounds (candidate selectors confirmed against actual element HTML, not guessed), generates a step-graph program against a 19-primitive DSL, test-runs it, and self-repairs on failure. Result: a deployed service with declared input/output JSON Schemas.
Run time (no LLM, ever): your agent — or cron, or your app — calls:
POST /api/v1/services/{name}/execute {"input": {"query": "..."}}
GET /api/v1/jobs/{id}/wait?timeout=120
Structured JSON comes back, every record stamped with the page it came from. Fast (no model latency), free (no tokens), deterministic (same steps every run).
Repair time (LLM, on failure): when a site redesigns and the service errors, Auto-Fix feeds the failing step + DOM snapshot back to the model and rewrites it. The tool heals itself without a human or an agent re-learning the page.
Every Scrapewright service can export its own Markdown API documentation — endpoint, schemas, examples, generated from the service definition. The intended workflow is explicit in the README: hand that document to your agent (the docs name Hermes Agent, WorkBuddy, and Lobster as examples), and let the agent construct its own tool wrapper for calling the service. That's a cleaner pattern than most "agent + scraper" integrations, because it separates two jobs that keep getting conflated:
The agent doesn't need to see the target site's DOM, burn context on page perception, or hold a browser session open. It needs one tool call with a schema it was handed. Your context window — and your token bill — stay spent on the reasoning you actually hired the model for.
The service runs in a real Chrome via an extension — your logins, your sessions, your fingerprint. So the tool layer can cover sources that server-side scrapers structurally can't: the SaaS dashboard behind SSO, the paid archive, the internal portal. When your agent needs "yesterday's numbers from the ops dashboard," the honest options used to be (a) agentic browsing with stored credentials, or (b) an integration that doesn't exist. Now there's (c): a deterministic local endpoint that is your credentialed access, wrapped in a schema. Self-hosted, one API key on localhost, nothing in the runtime path phoning any cloud — LLM or otherwise.
Compile-time tooling assumes the task repeats. Genuinely exploratory, one-off, every-site-is-different work is still agentic-browsing territory, and the project's own docs say so. The interesting design space is the hybrid — an agent that builds Scrapewright services on demand for tasks it detects are recurring, then stops thinking about them. The pieces for that are all in the box: a wizard API, service export/import as JSON, and per-service Markdown docs an agent can consume.
Repo: github.com/singhand-labs/scrapewright — GPLv3, quick start in the README, whitepaper for the architecture. If you're building agents that touch the web, spend one evening making a service and pointing your agent at its API doc — the drop in latency, cost, and flakiness is the whole argument.