Reading pages and extracting what is on them

The lightest thing an agent can do with a browser: go and read. No form, no authentication, nothing mutated — find a page, extract what is on it, report back.

It is also the case where Diwall costs the least. --mode fast returns the accessibility tree without a screenshot, and for text-driven work that is all you need. A real exercise: four pages, three requests, keyword found with its context, no vision model called at any point.

Comparing an item across several sources

Price and availability of the same component across several shops. The agent composes two things: a URL-discovery step to find candidate pages — a local search instance, for example — then Diwall in probe mode on each result, with evaluer actions pulling out price, stock and specifications.

{"type": "evaluer",
 "script": "document.querySelector('.price')?.textContent.trim()"}

The comparison itself happens in the agent, not in Diwall. Diwall returns structured facts; deciding what they mean is not its job.

One thing to know before building this. Whatever discovery tool you pair with Diwall is not a Diwall component — it is a separate piece the agent composes on top. And expect dead ends: on a real panel of 23 commercial sites, 39 % returned an immediate block. What that panel measured →

Mapping a documentation site

Documentation built as a single-page app does not respond well to naive fetching — the content arrives after client-side routing settles.

{"type": "attendre_reseau_calme"},
{"type": "evaluer",
 "script": "Array.from(document.querySelectorAll('pre code')).map(e => e.textContent)"}

Wait for routing to settle, take the accessibility tree in fast mode to map the structure, then walk the code blocks with evaluer to pull their exact content. The agent then has real material to synthesise from, rather than a paraphrase of what it thinks the page said.

Checking a calendar or a listing

“Is there anything on this weekend?” — without knowing in advance which page holds the answer. Fast mode plus the accessibility tree lets an agent scan a few pages and report back.

One such session produced a clean example of a documented false positive: the page loaded normally — rich content, no captcha, no interstitial — while respect.waf_bloquants still fired, because an unrelated third-party resource on the page matched a detection keyword. Resolved in about a minute by reading the accessibility tree already present in the same response.

That is the signal-not-verdict rule doing exactly what it is meant to do: the detection was wrong, it did not stop anything, and the answer was already in hand.

Why none of these ships as a scenario

Naming a real commercial site in a public, versioned scenario is a decision that belongs to you.

There is also a practical reason. A public scenario pinned to a named site fails months later when that site changes its anti-bot posture — and a broken example discredits the tool more than it demonstrated it. A dated table of which shops block and which do not goes stale faster than it informs.

The pattern is documented at panel scale in the project’s field notes. The targets are yours to choose.

In short

• Read-only work needs no screenshot and no vision model.
• evaluer returns structured data the agent can compare programmatically.
• Discovery tools are composed on top; they are not part of Diwall.
• Expect blocks on large commercial platforms, and route around them.