The agent assembled an answer about POTATOTECH by relying almost entirely on a single structured data fetch (step 14: the WordPress API page object containing an llms.txt document) that gave a clear mission statement and product overview. The site was poorly navigable for agent discovery — most direct URL guesses returned truncated HTML, search results pointed to competitors, and pricing/product APIs were blocked or 404'd — forcing heavy reliance on prior knowledge and the one well-structured artifact the agent found.

• ›Step 14 (wp-json/wp/v2/pages) was the only content-bearing fetch; it returned a structured page titled 'llms.txt' containing the company mission ('South African product catalogue and repair knowledge website focused on electronic repair parts'), target audiences, and product categories. This was cited implicitly throughout the final response and carried most of the factual load.
• ›The agent made 27 fetches but encountered heavy friction: most HTML pages returned truncated boilerplate (steps 1, 3, 8, 17–19, 23–27), product APIs were blocked (step 21: 401 on wc/v3/products), pricing URL returned 404 (step 9), and web searches (steps 5, 11–12) returned competitor links, not POTATOTECH content. The agent had to acknowledge 'pre-launch status' and missing pricing largely from the llms.txt artifact and inference, not from live product pages.
• ›The site published structured data via WordPress REST but had not optimized HTML pages for agent parsing — all page fetches were cookie/script boilerplate. The llms.txt page was discoverable only via the API endpoint, not linked from the homepage. This forced the agent to rely on prior knowledge (27% of fetches) and pattern-guessing (/wp-json paths) to surface usable content. No sitemap, robots.txt hints, or clear navigation schema was present to guide discovery.