The agent successfully assembled a comprehensive explanation of ClickHouse by working around a largely inaccessible marketing website. The clickhouse.com domain itself is heavily JavaScript-rendered and offered minimal machine-readable content; the agent obtained concrete details about ClickHouse's purpose, pricing tiers, and competitive positioning entirely from web search results and third-party sources (Improvado, DEV Community, DoubleCloud, Medium), not from the official site. The final answer is complete and well-sourced but reveals that ClickHouse.com itself is not agent-friendly for discovery tasks.

• ›Direct fetches of clickhouse.com/ (step [1]), /pricing (step [4]), /cloud (step [7]), /use-cases (step [8]), and /docs (step [9]) returned only HTML boilerplate and script tags; no actual pricing tables, product descriptions, or architectural details were present in the response bodies. The site is a Next.js SPA that requires client-side rendering.
• ›All substantive content came from web search results (steps [11], [12], [16], [17]): pricing details from Improvado and DEV Community, competitive comparisons from DoubleCloud and Medium, and architectural understanding from Medium and GitHub. The agent had to pivot to external sources because the official site did not expose machine-readable answers.
• ›The agent cited 11 external sources in its final response and zero answers directly from clickhouse.com itself, indicating the marketing site provides poor discoverability and indexability for agent-based research. Even the /docs domain (step [9]) returned HTML without renderable content in the fetch.
• ›The agent correctly identified and called out gaps in the official site: pricing page navigation difficulty, unclear open-source vs. Cloud feature parity, downplayed deployment complexity, and lack of competitive comparison matrices. These are the very details an agent would expect to find on the homepage or dedicated pages.