Scrunch is most useful to me as a way to turn observations about AI answers into a content and technical backlog. A visibility chart is a starting point; the valuable work is deciding what to verify and fix.
October series entry. First published: 8 October 2026. This newly written article completes the July–October series. Sources and product information were reviewed on 8 October 2026.
Scrunch’s public website describes prompt monitoring, citation analysis, competitor comparisons and visibility into AI bot traffic. It also describes its Agent Experience Platform, or AXP, as a way to deliver a lighter representation of website content to AI agents while retaining the human site experience.
These are vendor descriptions, not results from my own benchmark. I am not claiming that this website runs Scrunch or AXP, or that I have measured a visibility uplift here. Features, coverage and commercial terms should be checked with the vendor for a particular deployment.
My proposed pilot starts with a small set of consequential questions. For a fictional booking product, these might cover suitability for multi-location teams, supported payment workflows and cancellation rules. Each question needs an owner who can verify the answer.
After collecting a baseline, review a sample manually. Does the answer name the product? Does it link to an appropriate source? Does it claim a feature that does not exist? Is an outdated third-party page shaping the answer?
These findings lead to different actions. Missing documentation calls for content work. A blocked public page calls for technical investigation. A misleading third-party statement may need an evidence-backed correction request. Publishing another general article would not solve all three.
Suppose an assistant says StudioLedger supports refunds across every payment provider. Our fictional documentation only confirms one integration. Before calling this a brand visibility success, the team should check the response and its sources, update any ambiguous first-party copy and document the supported scope.
Then repeat the relevant observations under comparable conditions. If the error disappears once, record that result but keep monitoring. One changed answer is insufficient evidence that the underlying issue has been resolved for every user.
AXP introduces another question: does the agent-facing representation preserve the same factual meaning and limitations as the human-facing page? I would evaluate that through an explicitly scoped pilot rather than assume that lighter pages automatically produce more citations.
Check critical facts, links, exclusions and update behaviour in both representations. Assign ownership for changes and establish a way to roll back. Keep restricted content restricted. A delivery layer should not become a route for exposing private information or for presenting materially misleading claims to crawlers.
Before purchasing or deploying anything, define what evidence would justify continuing. My suggested criteria include actionable issues found, time taken to verify and resolve them, repeatable factual accuracy checks and the quality of reporting for the team making decisions.
Commercial outcomes need separate evidence. A product’s public testimonials may be relevant to an evaluation, but they are not forecasts for another organisation.
The workshop’s emphasis on prompt selection, measurement limitations and accountable action provides a useful framework for this workflow. Scrunch can be evaluated within that framework rather than treated as a substitute for it.
Illustrative cover image: existing site photograph by Pankaj Patel, reused from the Flutter VSCode extensions article. It is not workshop or product imagery.
Quick Links
Legal Stuff
