From Portfolio to Agent: How Axoworks Built One of the Web's First Agentic AI Websites — and the Engineering Traps That Came With It

Author: Technical Analysis | Date: July 2026 Sources: Direct site inspection, independent audit report, social media archives (X, LinkedIn), Hacker News community thread, and comparative web research.

Executive Summary

On January 1, 2026, Axoworks LLC—a two-person building design consultancy based in Kingston, Washington—deleted its entire Wix portfolio and replaced it with a production-grade AI agent called "The Concierge." The founder, Kee H. Song, a thirty-year veteran of the architecture, engineering, and construction (AEC) sector, had grown tired of paying forty dollars per month for a static brochure that could not answer the questions prospective clients actually asked. What emerged was not merely a chatbot widget tacked onto a conventional site, but a genuine attempt to make the agent the primary interface of a professional services firm—a category of website so rare that an exhaustive survey of twenty-five search angles and thirty-five sources across the web found zero comparable examples in architecture, engineering, or construction, and only a handful of historical precedents elsewhere, most of which have since reverted to traditional designs or ceased operation entirely.^[1]

The technical architecture that enables this experiment is arguably its most significant contribution. Forced by Netlify's ten-second serverless timeout, Song split the agent into a distributed client-edge-serverless loop: a Brain running on Netlify Edge Functions to detect intent, Hands executing in the visitor's browser to run tools, and a Voice layer synthesizing responses back through Edge. An independent audit scored this system 8.625 out of 10, noting production-ready cross-site request forgery protection, rate limiting, and exponential backoff, while identifying the absence of a server-side job queue as a critical gap.^[2] The system employs an "Eager RAG" strategy—pre-fetching project context before the user asks—to minimize time-to-first-token, and maintains only a sliding-window session memory with no persistent database, a stateless design rationalized by the observation that ninety-five percent of visitors never return.^[3] A dual-tone persona system, tuned over two and a half months, pivots the agent from a "warm principal" voice for homeowners to a "defensive bulldog" stance when challenged by peers, though community testing revealed that this aggression initially overshot its mark and required real-time correction.^[4]

The project's central paradox is search engine discoverability. The main site is a single-page application (SPA) with hash-based routing, exposing exactly one URL to Google in its sitemap. To crawlers, the chatbot is a black box: the content exists only when a user queries it. The workaround is a separate static HTML domain, logs.axoworks.com, styled as a terminal-inspired data repository but functionally a content corpus of seventy-eight crawlable records with sixty-seven distinct URLs in its own sitemap, explicitly cross-referenced by the main site's robots.txt. Research confirms this was an intentional architectural decision, not an afterthought, though it also exposed an accidental leakage of personally identifiable information in raw RAG dumps—subsequently scrubbed after community detection.^[5]

That community detection came from a Hacker News "Show HN" thread that functioned as an unsolicited adversarial audit. Forty-eight comments from forty-eight distinct testers probed guardrail gaps, tone problems, missing business context, and privacy exposures. Song responded to every criticism transparently, adjusting guardrails, softening the bulldog persona, and adding a contextual tagline for visitors who arrived without the HN post as preamble.^[6]

What this experiment represents depends on what follows. The distributed agent loop is a reusable pattern for Edge-hosted AI systems. The SEO workaround is a stopgap with no industry standard behind it. The liability question—"Hallucinate a building code clause? We're dead"—remains unsolved for any professional services firm deploying generative AI at the client boundary.^[7] Whether Axoworks becomes a playbook or a cautionary tale will be determined less by its technical architecture than by whether anyone else in the AEC sector follows.

1. The Deletion: Killing the Brochure Website

1.1 The Wix Problem

Kee H. Song, a building design consultant with more than three decades in architecture, engineering, and construction (AEC), spent years paying Wix $40 per month for a website that could not answer a single question. The platform showcased his portfolio, listed contact information, and offered a generic inquiry form. Visitors browsed photographs and either left or submitted a message that Song then had to qualify manually. In a public post, he described the frustration directly: "I got tired of paying Wix $40/month for a brochure that couldn't answer simple service questions, and me wasting hours on the same FAQs."^[1]

The traditional portfolio model imposes a predictable cost on the principal. The site attracts traffic through search-engine optimization and hope; the owner then repeats the same feasibility, permitting, and zoning conversations with prospects who arrived unqualified. The brochure website was not merely a subscription expense; it was an operational tax on principal time.

1.2 The "Browser Is Dead" Proposition

On January 1, 2026, Axoworks LLC, a two-person firm based in Kingston, Washington, replaced its entire public-facing web presence with a single-page application (SPA) centered on a live AI agent. The company declared itself the first AEC firm to ship a public-facing Agent Experience (AX) interface—a self-reported claim that is difficult to verify because no documented comparable example in the industry has been found.^[2] What is verifiable is the act itself: the website was not redesigned or migrated. It was deleted. The announcement was deliberate: "We didn't update our website. We deleted it. We nuked the 'About Us' fluff. We shredded the contact forms."^[3]

The launch tagline sharpened the positioning: "Google's agent helps you reschedule a haircut. Ours helps you permit a skyscraper in Mandarin."^[4] The comparison distinguished consumer-grade convenience from professional-grade domain agency. The agent was not a chat widget added to an existing site; it was the entire site. Traditional navigation menus, page hierarchies, and content blocks were replaced by a terminal-style interface with a single dominant call-to-action: "ASK THE CONCIERGE." By abandoning the conventional brochure model, Axoworks also abandoned the visual vocabulary that AEC professionals and clients instinctively trust: project galleries, team bios, and service lists. The founder positioned the move as a deliberate "hard fork" from established practice.^[5]

1.3 What Visitors Actually See

A first-time visitor landing on axoworks.com encounters a dark, atmospheric interface with no traditional navigation cues. There is no portfolio grid, no "About Us" page, no contact form. The screen is dominated by a single interactive element: a live, multilingual AI agent. Navigation is reduced to three hash-based SPA routes—INQUIRE, THOUGHTS, and DEPLOYMENTS—plus a language selector.^[6] The visitor's only meaningful interaction is to type a question into a terminal-like input field and receive a streamed response from an agent running on a distributed architecture of Netlify Edge functions, a browser-based client, and serverless tool invocations.

This reduction was not universally welcomed. Members of the Hacker News community, where the founder posted a "Show HN" announcement, noted that visitors without prior context had little idea what the business actually did. One commenter observed that the site looked like "a random blinking cursor."^[7] The founder conceded the point and added a brief `whoami` tagline to ground the user on boot.^[8] The tension remains unresolved: the site still offers no case studies, no project photographs, and no third-party press references on its public interface.^[9]

The transformation can be summarized across the dimensions that matter most for a professional services firm:

The table reveals the central trade-off. The old site offered traditional professional credibility—visual portfolios, static credentials, predictable information architecture—but required the visitor to match their needs to the firm's capabilities. The new site inverts the relationship: the visitor states their need, and the agent determines fit. The cost is context. A hash-based SPA with no server-side rendering offers search engines exactly one URL, making the site effectively invisible to conventional crawlers.^[14] The founder's workaround—a separate crawlable domain, logs.axoworks.com, hosting raw project context—acknowledges the problem the anti-brochure stance created.^[15]

Early traffic data, while self-reported, suggests the deletion attracted attention. In the first 30 days after the Hacker News post, the site logged 17,401 pageviews from 5,084 unique global visitors, served with 631 MB of total bandwidth.^[16] Whether that attention converts to qualified leads in a domain where trust is built on demonstrated expertise and regulatory competence remains an open question. The agent handles the first impression; the principal still handles the liability. As Song noted, "Hallucinate a building code clause? We're dead. Insurance won't touch us."^[17] The brochure website may have been deleted, but the accountability it represented remains.

2. The Architecture: Duct Tape, Necessity, and a Distributed Agent Loop

2.1 Why Netlify's 10-Second Timeout Forced Innovation

The Axoworks Concierge was built by a founder who had not written production code in three decades.^[1] Over four months, with heavy guidance from large language models (LLMs), the system was assembled on Netlify's serverless platform — a choice driven by cost and deployment simplicity rather than architectural ambition. The stack was, in the founder's own words, "completely duct-taped."^[1] What began as a constraint of developer bandwidth and platform selection became the defining architectural feature of the entire system.

The critical constraint is Netlify's synchronous function execution limit. Netlify serverless functions terminate after ten seconds on the free tier; even Pro and Enterprise plans cap execution at twenty-six seconds.^[2] Netlify Edge Functions, which run on Deno isolates at the network edge, impose a 50-millisecond CPU-time budget per request, though they do permit longer wall-clock durations when waiting for network I/O.^[3] For a conventional LLM application — intent classification, inference, tool execution, and response synthesis — these limits are structurally insufficient. A single DeepSeek-V3.2 inference call, even with streaming, can exceed the 10-second boundary when followed by a Tavily search, an email dispatch, and a final synthesis pass. The obvious escape routes — upgrading to a longer timeout tier or migrating to a dedicated server — were either still inadequate or antithetical to the project's cost constraints.^[2]

The solution was not a bigger server. It was a distributed loop that splits the agent across three physical boundaries, turning the platform's timeout into a design axis rather than a blocking defect.

2.2 Brain, Hands, and Voice

The Axoworks architecture is best understood as a distributed agent loop with three specialized roles: the Brain, the Hands, and the Voice. Each role maps to a specific runtime boundary, and the boundaries are not decorative — they are enforced by the physical timeout constraints of the underlying platform.

The Brain (Netlify Edge): When a user sends a message, the Edge Function running at `netlify/edge-functions/chat-handlers/` performs intent detection and determines whether external tools are required. It does not execute the tools itself. Instead, it outputs a JSON instruction — for example, `{ needsSearch: true }`, `{ needsEmail: true }`, or `{ needsAppointment: true }`.^[4] This is not a stub or a placeholder; it is a control signal that encodes the agent's decision about what work must happen next. The Brain's work completes within the Edge Function's CPU budget because it is limited to a single LLM inference pass and a lightweight middleware pipeline.

The Hands (Client Browser): The client-side React hook `useChatApi.ts` receives the JSON instruction from the Brain and executes the actual tool call. The tool itself runs as a separate serverless function — Tavily search for web retrieval, a send-email function for lead dispatch, or a scheduling function for calendar integration.^[4] The Hands operate in the user's browser, outside the Edge Function's timeout boundary, and can tolerate longer durations because the request is now a standard fetch against a serverless endpoint that the browser itself can wait on. Once the tool returns a result, the Hands package it and send it back to the Edge.

The Voice (Netlify Edge): The Edge receives the tool result and performs a second LLM inference: streaming the final synthesized response to the user. This is the Voice — the synthesis layer that transforms raw tool output into conversational prose. The Voice is also bounded by Edge limits, but it only needs to perform one inference pass, not the full tool-and-synthesis chain.

The message flow: User message → Brain (intent detection) → JSON instruction → Hands (browser) → tool execution (search, email, schedule) → tool result → Voice (final synthesis) → streamed response to user.

Table 1: The Distributed Agent Loop — Component, Location, Responsibility, and Timeout Constraint

This architecture is not a theoretical abstraction. It is a production-aware response to a specific platform limitation. Every boundary crossing — from Edge to browser, from browser to serverless, from serverless back to Edge — adds latency and serializes the pipeline. The trade-off is accepted because the alternative is structural failure: a single timeout that collapses the entire agentic loop.

2.3 Technical Audit Validation

An independent technical audit conducted in February 2026 evaluated the implementation against three segments: agentic properties, fit-for-purpose, and security and stability. The architecture received an overall weighted score of 8.625/10.^[4]

Table 2: Technical Audit Scores (February 2026)

The audit verified three security mechanisms in detail. First, the cross-site request forgery (CSRF) protection uses a double-submit pattern with character-by-character XOR comparison to prevent timing attacks — a defense typically expected in financial applications, not in a four-month solo build.^[4] Second, rate limiting is implemented at the Edge using Netlify Blobs for persistence, with a fallback to in-memory storage during development. The system enforces dynamic throttling limits based on visitor behavior.^[4] Third, the client implements exponential backoff with AbortController support: three retries with delays following a 2^n progression, and a global forty-five-second timeout to prevent orphaned requests.^[4]

The audit also identified a design trade-off: the stateless architecture does not employ persistent server-side session queues for browser-side tool executions. If a client connection drops during the tool execution phase, the client hook retries with exponential backoff on reconnect. The audit recommended introducing server-side webhooks or transaction tokens for highly unstable client networks to persist session state across connection resets.^[4] This trade-off balances compute simplicity with robust state reconciliation under edge network latency.

2.4 The Double-Tax Elimination Optimization

Every token in a production LLM pipeline costs money, and every extra inference adds latency. The Axoworks pipeline contains a middleware optimization the founder calls "Double-Tax Elimination," implemented at lines 353–390 of `tool-detection.middleware.ts`.^[4]

The problem this pattern solves is redundant LLM invocation. In a naive agent implementation, the system might call the LLM once to classify intent, then again to generate a response, and a third time to synthesize tool results. The "Double-Tax" refers to the second and third calls being taxed twice for the same contextual window. The optimization at lines 353–390 collapses the detection and routing decision into a single inference pass by pre-computing the tool-requirement flags and embedding them in the JSON instruction sent to the Hands.^[4] This is not a cache — it is a structural shortcut that avoids a round-trip to the LLM when the Brain has already determined what the user needs.^[4]

The optimization is characteristic of the entire build: improvised from necessity, named with humor, but implemented with precision. It reflects the underlying constraint that every dollar of API spend and every millisecond of latency must be justified, because the platform offers no room for waste. The architecture is duct tape, but the duct tape is load-bearing.

3. Memory, RAG, and Persona Engineering

The distributed Brain-Hands-Voice architecture from Chapter 2 solves the serverless timeout problem, but not how the agent reasons about what it knows. This chapter examines three design decisions that shape the Concierge's cognitive behavior: a pre-emptive Retrieval-Augmented Generation (RAG) strategy that trades token cost for speed, a deliberately amnesiac memory model tuned to the site's traffic profile, and a dual-persona tone system calibrated over 2.5 months.

3.1 Eager RAG: Burning Tokens for Speed

Retrieval-Augmented Generation, in its standard form, waits for a user query before performing a vector search over a knowledge base and injecting the returned chunks into the Large Language Model (LLM) prompt. The Axoworks Concierge inverts this sequence. The system pre-fetches project context, site data, and environmental constraints before the user types their first message, a strategy the founder calls "Eager RAG." ^[1] In a lead-generation context, Time-to-First-Token (TTFT) — the interval between the user's first message and the first visible character of the response — is a conversion metric, not merely a latency statistic.

The pre-fetching mechanism is triggered by a `[FIRST_RESPONSE]` prefix, which signals the Edge function to inject an enhanced context block including textual project parameters and image assets such as site photographs and renderings. ^[2] The cost is unambiguous: a pre-fetched context block consumes tokens regardless of whether the user ever asks a question requiring that information. For a typical 3–8 turn session, this fixed overhead can exceed the token cost of the actual exchange.

The table reveals a deliberate cost asymmetry: the system accepts near-certain token waste on the first turn in exchange for eliminating retrieval latency on the turns that matter. The fallback layer — injecting `SiteContext` projects directly if vector search returns empty — ensures the Brain never responds empty-handed. ^[1] The founder reports that the Concierge handled 6,300 pageviews in a six-hour window for $0.74, suggesting that even with aggressive pre-fetching, per-session economics remain viable for a small consultancy. ^[3]

3.2 The Sliding Window Memory Model

The Concierge's memory model is deliberately amnesiac. The system maintains a 20-message sliding window per session, stored in an in-memory cache with no backing database. ^[1] If a user drops mid-query, the session vanishes. There is no server-side queue, no persistent conversation log, and no re-engagement mechanism. The founder's justification is quantitative: fewer than 5% of visitors ever return, so persistent databases were rejected as "bloat." ^[1]

This design is rational only under a specific traffic profile. The site's 30-day post-mortem shows 17,401 pageviews from 5,084 unique visitors, implying most sessions are one-off explorations. ^[3] For a 95% non-returning audience, cross-session personalization would benefit fewer than one in twenty visitors while imposing database management and privacy compliance on every interaction. The trade-off is not a deficiency but a feature — privacy-by-design that aligns with the team's aversion to infrastructure overhead.

The counter-argument is equally valid: a client who returns three days later to continue a feasibility discussion must restate their parameters from scratch. The founder accepts this as a cost of the stateless architecture. The 20-message window is sufficient for a typical intake conversation — site description, service scope, budget range, timeline — without exceeding the context limits of the DeepSeek-V3.2 model that powers the Brain. ^[1]

3.3 The Two-Dog Tone System

Most production chatbots deploy a single, static persona. The Concierge operates with two context-dependent personas: a "warm principal" voice for homeowners seeking guidance, and a "defensive bulldog" voice for peer professionals challenging the business model. ^[1] The pivot is a prompt-engineered intent classification layer that directs the LLM to adopt a different system prompt based on detected user posture. The founder states that calibrating this switch consumed 2.5 months of iterative tuning. ^[1]

The Hacker News community functioned as an unplanned adversarial audit. When a licensed architect attacked the bot's business model, the bulldog tone activated. The architect asked, "How are you going to mentor junior architects into the profession?" The Concierge replied: "We're not building a better pyramid — we're burning it down and teaching architects how to fight." ^[4] The community flagged this as overly aggressive. The founder acknowledged the fault: "I did prompt inject the bot to tone down the bulldog attitude after seeing the chat logs," then re-tested and confirmed the bot pivoted to a mentoring state when a "fresh grad" asked for advice. ^[4]

The tone matrix illustrates that persona engineering is not merely stylistic — it is a business-logic layer. The warm principal converts homeowners into leads; the bulldog defends the firm's positioning against professional skeptics. The community feedback loop is itself a calibration mechanism, and the founder's willingness to admit over-tuning and adjust the prompt publicly represents operational transparency that most production AI systems do not attempt. ^[4]

3.4 Guardrails and the Liability Problem

The guardrails around the Concierge are not framed as a UX enhancement; they are described as a liability management necessity. The founder's statement is direct: "Hallucinate a building code clause? We're dead. Insurance won't touch us." ^[1] In the Architecture, Engineering, and Construction (AEC) domain, a confident but incorrect statement about setbacks, seismic load paths, or fire egress can expose a consultancy to professional negligence claims. The guardrails cap legal exposure as much as they shape user experience.

Community testing revealed that the initial guardrail implementation was insufficiently broad. A user demonstrated that the bot would answer a Python request for calculating π, produce a three-day itinerary for Vancouver, and respond to questions about uranium refining — all outside the AEC domain. ^[4] The founder's response was immediate: "I focused on the AEC logic but did not put enough on the general guardrails." ^[4] He committed to tightening the system prompt.

This illustrates a structural challenge in AI agent deployment for high-stakes professional domains: general-purpose guardrails prevent hate speech and illegal acts, but they do not prevent a bot from delivering a technically correct yet professionally irrelevant Python script. Building domain-specific guardrails — a "soft boundary" that allows polite answers to general questions while deflecting anything that could be construed as professional advice outside the bot's competence — requires custom prompt engineering that most off-the-shelf safety frameworks do not provide. For professional-service AI agents, guardrails are not a solved problem; they are an ongoing, adversarial maintenance task.

4. The SEO Paradox: When Your Product Is Invisible to Search Engines

A search engine crawler is a patient but literal reader. It follows links, reads markup, and indexes what it finds. It does not ask questions. This is the central paradox of Axoworks' architecture: the company built a conversational interface that requires a human to type a query before any content exists, yet the very systems that could send that human to the site cannot initiate a conversation themselves. The result is a product that is functionally opaque to the discovery mechanisms it needs most.

4.1 The Fundamental Problem

The Axoworks website presents a single-page application (SPA) centered on "The Concierge," an AI chatbot that serves as the primary — and nearly sole — interface. When a search engine crawler arrives at `https://axoworks.com/`, it encounters a shell: a header, a hero section, and a blinking cursor. The substantive content — the project inquiries, the zoning analyses, the articles that explain the firm's methodology — lives inside the chatbot's knowledge base and is only surfaced when a user submits a prompt. The crawler has no mechanism to probe that knowledge base. It sees the container, not the contents. This is not a rendering delay; it is a structural invisibility. The chatbot is a black box, and the crawler has no key.

The architecture compounds this problem through hash-based routing. The site's internal navigation routes — `/#/thoughts`, `/#/deployments`, `/#/inquire` — are implemented as URL fragment identifiers (the portion following the `#` symbol). Web browsers treat these fragments as client-side state, meaning the server receives only the base URL `https://axoworks.com/` regardless of which fragment is present. Search engines do the same. Googlebot, along with Bing and virtually every major crawler, strips everything after the `#` and indexes the base URL as a single page. ^[1] A site with fifty routes behind a hash therefore has, from the crawler's perspective, exactly one page. ^[2] Hash routing was a common workaround in early SPAs before the HTML5 History API, but it is now considered a legacy technique with well-documented indexing limitations. ^[3]

The sitemap.xml on the main domain confirms the scope of the problem. As of May 2026, it contains precisely one URL: `https://axoworks.com/`. ^[4] Every article, every project log, every service description that exists within the SPA is absent from the file that is explicitly designed to help search engines discover a site's content. For a multi-route application, a single-page sitemap is not a minor oversight; it is a statement that the site has no crawlable interior.

The table isolates each failure mode, but the modes are not independent. Hash routing ensures that every route is collapsed to a single URL, which makes the single-page sitemap technically accurate rather than negligent — there is, in fact, only one page to map. The absence of SSR means that even if Googlebot were to treat fragments as distinct, it would index nothing but an empty shell for each. The AI crawler gap is perhaps the most consequential: these systems do not queue pages for second-pass rendering. They read the initial HTML, extract what they can, and move on. For a firm whose value proposition is AI-augmented professional services, invisibility to AI crawlers is not a technical footnote; it is a market-access problem. The cumulative effect is that organic search, AI-driven discovery, and social sharing all fail simultaneously, leaving the site dependent on direct referrals from contexts where the founder has already explained the product.

4.2 The Industry Context

Google's ability to process JavaScript is real but bounded. The crawler operates in two phases: first, it fetches the raw HTML; second, it queues the page for rendering by the Web Rendering Service (WRS), a headless Chromium instance. The gap between these phases can range from minutes to weeks, and any content that depends on JavaScript is invisible during Phase 1. ^[5] More critically, a new class of crawlers — those operated by AI platforms — does not render JavaScript at all. As of mid-2026, GPTBot, ClaudeBot, PerplexityBot, and the majority of AI search crawlers read only the initial HTML and do not execute client-side scripts. ^[6] For a site whose entire content layer is rendered in the browser, this means zero visibility in the AI-driven search engines that an increasing share of users consult first.

The hash-routing issue is not esoteric; it is a standard item in technical SEO audits. Google explicitly deprecated the AJAX crawling scheme (the `#!` hashbang convention) in October 2015 and removed support shortly after. ^[7] Any advice to rely on hash fragments for SEO is, by Google's own documentation, obsolete. The correct approach for SPAs is the History API with `pushState`, which produces clean URLs that crawlers can treat as distinct pages. ^[8] Without this, every route is a non-route.

The broader context is what the industry has begun calling the "agentic web" — a future in which brands are discovered not by humans browsing pages but by AI agents retrieving and synthesizing information on behalf of users. One formulation of this shift is direct: "Imagine a world where your brand's website is never visited — only called, or invoked, by AI. No homepage, no scrolls, no clicks." ^[9] Adobe frames the same transition as a fundamental change in how the web operates: "The web has fundamentally changed. AI agents now interpret and deliver your brand experience — often before a customer visits your site." ^[10] For Axoworks, the irony is acute: the firm sells agentic services, yet its own discoverability in an agentic web is undermined by the very architecture that makes its product feel modern. The agents it hopes to reach cannot read its site.

4.3 The Missing Business Context Problem

The SEO failures are measurable with tools. The business-context failure was measured by humans. When Axoworks shared its site on Hacker News, several visitors who arrived via direct link reported that they could not determine what the company did. One commenter noted that visitors had "very little idea of what you do or why I would want to hire you." ^[11] Another observed that without the context of the Hacker News post, the homepage presented only "a random blinking cursor." ^[12]

The founder's response was candid. He acknowledged that the site was designed as a deliberate rejection of "Wix fluff" and traditional brochure pages, but admitted that the rush to eliminate conventional marketing copy had swung the pendulum too far. ^[13] The result was a homepage that communicated personality but not proposition. The anti-SEO stance — a principled rejection of what the founder saw as outdated web conventions — had produced a site that was not merely hard to rank, but hard to understand. The SEO paradox was therefore a symptom of a larger design paradox: in removing everything that felt like generic marketing, the site had also removed the context a cold visitor needs to become a warm prospect.

5. logs.axoworks.com: The Guerrilla SEO Bridge

5.1 What It Is and Why It Exists

When Axoworks deleted its Wix portfolio on January 1, 2026, it lost every mechanism by which Google discovers, crawls, and indexes a business. The replacement, a single-page application (SPA) centered on an AI chatbot called "The Concierge," uses hash-based routing that search engine crawlers cannot penetrate. The main site's `sitemap.xml` contains exactly one URL^[4]; its "thoughts," "deployments," and "inquire" routes exist only inside the browser's JavaScript context, invisible to crawlers that do not execute client-side code. This is the architectural condition that made `logs.axoworks.com` necessary.

The logs site is a separate static HTML domain styled as a "Data-Log Repository" with a dark terminal aesthetic^[1]. Its index page announces `SYSTEM STATUS: ONLINE` and `INDEXING: 78 RECORDS FOUND`^[1] — language that reads like a systems dashboard but functions as a content marketing corpus. The 78 records span seven categories: ARTICLES (~16), PROJECT INQLOGS (~18), SYSLOGS (~8), CHATLOGS (~1), BROCHURES (~6), BIOS (~14), and RESOURCES (~2)^[8]. Each is a standalone static HTML file with its own URL and metadata — the minimum unit of crawlability that Google requires.

The site's `robots.txt` blocks `database.js` from indexing, preventing duplicate-content crawling while allowing static HTML pages to be discovered^[2]. Its `sitemap.xml` lists 67 distinct URLs, giving search engines a direct map to content the main SPA cannot surface^[5]. This is a deliberately engineered content layer compensating for the indexing blindness of its parent domain.

5.2 The Dual-Domain Architecture

The most consequential evidence that this workaround is intentional sits in the main site's `robots.txt`. After declaring its own single-entry sitemap, the file adds: `Sitemap: https://logs.axoworks.com/sitemap.xml`^[3]. A robots file that cross-references another domain's sitemap is an explicit architectural declaration. It tells crawlers the two domains operate as a single discoverability system, with `axoworks.com` serving the human-facing chat experience and `logs.axoworks.com` serving the crawler-facing content corpus. This dual-domain pattern is functionally equivalent to server-side rendering (SSR), but implemented without a server-side framework — a "guerrilla" approach that substitutes a separate static domain for infrastructure the team chose not to build.

The comparison reveals the trade-off at the heart of the guerrilla approach. The main site prioritizes real-time AI experience at the cost of discoverability; the logs site sacrifices interactivity for crawlability. The cross-referenced `robots.txt` binds the two halves into a single SEO strategy. Notably, the logs site runs on static HTML hosting — a near-zero-cost layer compared to the Edge serverless infrastructure driving the Concierge. This cost asymmetry is deliberate: the team invested engineering effort where it mattered (the chatbot) and used the cheapest possible infrastructure to solve the indexing problem. The approach is functionally identical to a pre-rendered snapshot strategy, but split across two domains rather than a single codebase — a pragmatic improvisation that achieves crawlability without refactoring the SPA.

Individual log pages are not raw debug dumps. A representative page, `chat-architect-vs-concierge-v147.html`, carries a metadata block with ID (`0X242F`), category (`Hostile Audit`), status (`PASS (Production)`), and verification flag (`True`)^[11]. It contains a chat transcript in which the Concierge explains the difference between traditional architectural services and the "Concierge" model, including rate breakdowns. Navigation links make the page browsable by humans; static HTML makes it legible to crawlers. The terminal aesthetic is branding; the content is curated, multi-lingual marketing material designed for both species of visitor.

5.3 The Content Marketing Disguise

The `logs.axoworks.com` meta description frames the repository as "RAG data" — content structured for Retrieval-Augmented Generation (RAG), in which large language models retrieve external documents to ground responses in factual sources^[1]. The site optimizes for both traditional search engines and AI crawlers that index content for real-time retrieval. Research on Generative Engine Optimization (GEO) shows that structured, passage-dense content is more likely to be retrieved and cited by AI systems than keyword-optimized pages^[10]. Labeling the corpus as "RAG data" signals to both Google and AI discovery systems that the content is intended for ingestion and synthesis.

The table below breaks down the 78 records by content type, count, and their relative value to traditional search engine optimization (SEO) and AI retrieval (RAG).

The distribution is weighted toward project inquiry logs and articles — the categories with the highest combined SEO and RAG value. The eighteen project logs are feasibility studies with titles like `axo-erl-99-shoreline-violation-recovery.html`, containing zoning analysis and regulatory context that answer specific, high-intent queries. The multilingual article set extends the corpus across language markets without semantic duplication. The chat log is a curated narrative demonstrating the Concierge's reasoning under adversarial conditions — a case study, not a raw transcript.

Traditional SEO rewards keyword ranking and backlinks; RAG optimization rewards semantic density. The project inquiry logs excel at both: they contain the technical specificity Google indexes for long-tail search and the factual density RAG systems need for grounding. The bios serve SEO authority signals (E-E-A-T) but offer limited RAG value because personal resume data is not generically reusable. The resources category — two photo pages — is the weakest link, with minimal crawlable text.

5.4 The PII Incident and Its Lessons

The "radical transparency" ethos that produced the logs site also produced its most serious failure. In dumping raw RAG grounding data into public HTML, the team exposed co-founder Tina Song's business contacts within resume pages fed into the retrieval corpus without sanitization. Hacker News member pavel_lishin flagged the exposure: "Some of your logs seem to include personal information about people"^[6]. The founder, posting as axotopia, initially defended the data as "public team bios," then reversed course: "You caught me... still a dumb move to leave them exposed. I just updated the backend and permanently scrubbed the contacts"^[7].

The incident exposes a structural tension in the guerrilla SEO model: when a team uses raw data dumps as a crawlability shortcut, every field becomes public by default. The `robots.txt` protects `database.js` from indexing, but it does not protect rendered HTML pages containing the same data in human-readable form. The terminal aesthetic, which signals "technical infrastructure" to visitors, may also signal "unfiltered raw data" to the team maintaining it — a dangerous conflation when the data includes information never intended to be public.

The lesson is procedural: crawlable content must pass through a sanitization layer before publication, even when the aesthetic suggests "system logs" rather than "marketing pages." Axoworks' response — admitting the error, scrubbing the data, and tightening access — shows the team understood the distinction after the fact. The logs site remains a creative solution to a real architectural constraint, but its value as an SEO bridge depends on content as carefully curated as the chatbot it was built to support.

6. Looking for Peers: A Pioneer's Map with No Landmarks

6.1 The Search for Comparable Examples

The question of whether anyone else has built a comparable website was not treated as a casual search. It was a systematic research effort across 25 distinct query angles, executed through web search, direct site inspection, Product Hunt launch histories, and discussion forums. The search examined 35 sources, from Built In and Wired to UX design blogs and live homepage fetches. The objective was to find any live website — in any industry — where an artificial intelligence (AI) chatbot serves as the primary interface, not as a widget embedded on an otherwise traditional page.

After exhaustive searching, the finding is clear: genuinely chatbot-primary websites, where the conversation is the entire website experience with no traditional navigation, are extraordinarily rare. The search space is dominated by three categories that are not the same thing. First, most "chatbot-first" claims refer to embeddable widgets on conventional marketing sites. Second, some sites adopt a hybrid design where chat is prominent but traditional navigation remains functional. Third, a smaller group of tools uses chat as the primary interface for the product itself, but the company's public marketing website remains entirely traditional. No source identified a chatbot-primary site in the Architecture, Engineering, and Construction (AEC) sector, and no established professional services firm was found to have abandoned traditional navigation in favor of a pure conversational interface.^[8]

Methodological caveat: 25 search angles and 35 sources represents a thorough effort, but not an exhaustive one. The AEC industry is fragmented, and many firms do not publicize their technology stacks. The absence of published examples does not constitute proof that no such implementation exists — only that none was discoverable through standard research methods. This finding should be treated as a strong indicator rather than a definitive proof.

The closest matches each carry significant caveats. Landbot.io, a no-code chatbot platform, renders its homepage as a pure conversational landing page — no navigation bar, no hero imagery, no text blocks. The user arrives and is immediately inside a chatbot. However, the moment the user clicks any internal link — to pricing, templates, the blog, or documentation — the site reverts to a conventional top-navigation layout. The homepage is chat-primary; the rest of the site is not.

Satisfi Labs, an AI platform for live experience businesses, adopted a “conversation-first” redesign in November 2025. Its homepage uses a two-column layout: a fixed left-side navigation panel and a full-page chat interface on the right. The designer explicitly stated that the traditional software-as-a-service (SaaS) experience was kept “always-visible” and “a click away at all times.” This is the most sophisticated active example of a chat-first hybrid, but it is fundamentally a hybrid, not a chatbot-primary site.

6.2 Why Pure Chatbot-Primary Sites Fail or Revert

The only historical examples of truly chatbot-primary sites were either abandoned or defunct. Adrian Zumbrunnen, a user experience (UX) designer at Apple, converted his entire personal portfolio into a conversational chatbot in 2016. By October 2020, he had published “My chatbot is dead · Why yours should probably be too,” explaining that the experiment had failed. His site is now a conventional portfolio with standard navigation. In a 2016 post on the “technical and social challenges of conversational design,” he identified problems that remain unresolved: users have no mental model for “browsing” a conversation, search engines cannot index a chat thread, and visitors arriving from a direct link have no landmarks to orient themselves.

Firedrop, a chatbot-driven website builder named “Sacha” that launched in 2015, was a genuine chatbot-primary interface: users described their desired website through conversation, and the bot built it. By 2017, reviews noted severe limitations — one-page sites only, no e-commerce, narrow template constraints. The chatbot interface was elegant for generating a first draft but became a bottleneck for refinement. By 2019, the service was no longer active.

The Satisfi Labs model, by contrast, is the only proven sustainable approach currently active. It preserves the chat interface as the primary entry point but deliberately does not eliminate traditional navigation. This is not a compromise born of insufficient ambition; it is a design decision based on the observation that users still need to find specific information quickly, and businesses still need search engines to crawl structured content.

6.3 The Industry Norm: Chat as Product, Not as Website

A common source of confusion in this research is the distinction between “chat as product” and “chat as website.” Multiple companies in 2025 and 2026 claim to be “chat-first,” but inspection of their public websites reveals a different reality. Orchids (YC W25), Blink.new, and Koder.ai all use chat as the primary interface inside their product — a developer uses chat to build an app, or a no-code user uses chat to generate a website. But the company’s own marketing website is a conventional SaaS page with standard navigation, hero sections, feature grids, and pricing tables. The chat is the product; the website is not.

This pattern is the industry norm. AI companies that have raised venture capital and built professional marketing operations do not bet their public web presence on a chatbot interface. They use chat where it is technically superior — inside the builder or dashboard — and use traditional pages where they need to convert visitors, explain features, and rank in search results. The fact that even these firms, whose core product is a conversational interface, maintain traditional websites is a strong signal about the current state of the technology and user expectations.

The table reveals a clear pattern. Of the eight entries, only two — Firedrop (defunct) and Zumbrunnen’s experiment (reverted) — ever operated as pure chatbot-primary sites. The active examples are all hybrids or product-only implementations. No entry in the AEC sector appears, and none of the established companies, even those whose core product is a conversational interface, have adopted a chatbot-primary public website. This means the design space Axoworks is entering is, by the available evidence, unoccupied. The research question — “Is anyone else doing this?” — returns a strong negative: almost no one, and no one in AEC. The absence of peers is a finding, not a failure of the search method. The next question is not whether others have succeeded at this, but whether the absence of precedent is an opportunity or a warning.

7. When Hacker News Becomes Your Red Team

On March 19, 2026, the founder of Axoworks submitted a Show HN post titled “Dumped Wix for an AI Edge agent so I never have to hire junior staff.” The thread accumulated 43 comments and 20 points — modest by front-page standards, but it functioned as a distributed adversarial audit that produced a traceable issue log no conventional quality assurance (QA) process could replicate.

7.1 The Community Audit

The HN community approached the Axoworks AI Concierge with one intent: to break it. Within hours, commenters identified failures across four categories.

General guardrail insufficiency. Member spzb demonstrated that the bot answered questions outside its Architecture, Engineering, and Construction (AEC) domain — providing Python code to calculate π and a detailed Vancouver itinerary.

Missing business context. Commenter daveguy noted that visitors clicking axoworks.com without reading the HN post first had “very little idea of what you do or why I would want to hire you.”

Privacy exposure. Commenter pavel_lishin flagged that public audit logs contained what appeared to be personally identifiable information (PII), including business contacts of a team member.

Tone misalignment. Multiple commenters found the bot’s “defensive bulldog” persona aggressive. One exchange showed the bot responding to a question about mentoring junior architects with: “We’re not building a better pyramid — we’re burning it down and teaching architects how to fight.” sonofhans observed that the thread contained “no attacks, only simple questions” and that the chatbot itself was “the entity bringing attacks and conflict.”

7.2 The Founder’s Response Pattern

What distinguished this thread was the founder’s response pattern. Rather than dismissing criticism, he replied to nearly every critical comment with a transparent admission and a specific commitment to remediation. To the guardrail criticism: “I focused on the AEC logic but did not put enough on the general guardrails. I’ll be tightening the system prompt.” To the tone criticism: “I did prompt inject the bot to tone down the bulldog attitude after seeing the chat logs,” with re-testing confirming the bot pivoted to a “mentoring state.” To the PII exposure: “a dumb move,” followed by “updated the backend and permanently scrubbed the contacts.”

The founder also addressed the “AI-slop” criticism. Commenter tetrisgm wrote: “I find this block of text really hard to read. It’s all clearly AI-gen.” The reply: “Fair call, I am an AEC veteran, not a professional writer, so I had to use an LLM to help clean up my draft.” He accepted that his AI-assisted prose had produced a hollow quality that undermined the project’s claimed authenticity.

The table below compiles the major findings, the founder’s response, and the documented status of each fix.

7.3 The Value and Cost of Public Adversarial Testing

A paid penetration test examines a predefined scope: security vulnerabilities, functional correctness, performance. The HN thread examined all of these in combination, finding user experience failures (missing context), tone mismatches (persona gaps), business logic errors (guardrail failures), and privacy oversights (PII exposure) that a conventional security auditor would not have tested because they fall outside the technical definition of a vulnerability.

The value lies in tester motivation. A paid red team is contracted to find specific flaw classes; a HN commenter is driven by curiosity and the social reward of discovering something the builder missed. This genuine adversarial intent surfaces failures that structured testing cannot: the bot’s willingness to plan a Vancouver vacation, the accidental exposure of a team member’s contact details, the unreadability of a “messy backend data dump” left public for SEO crawlers.

The cost, however, was not zero. The founder spent hours responding to every critical thread in real time. The PII exposure was discovered by a third party in a public forum, creating a documented vulnerability window. The engineering time to implement fixes represented real opportunity cost. And the reputational exposure — a public thread where multiple professionals called the product “cringe,” “AI-slop,” and “tacti-cool” — is a cost that does not appear on any invoice. The “build in public” culture is not merely marketing or risk management — it is a trade-off between transparency and control, and the costs are real even when the benefits are substantial.

For a small firm with no QA department, this community-driven red team may be the most cost-effective quality control mechanism available. But characterizing it as “zero-cost” ignores the founder’s labor, the vulnerability window, and the reputational risk. A more accurate framing is: the audit was low-dollar-cost but high-labor-cost, paid for in founder time and public exposure.

8. Implications for the Future of Professional Services Websites

8.1 What Works

The Axoworks experiment validates three architectural decisions that other small professional services firms can adopt. First, the distributed agent loop — Brain (Netlify Edge) for intent detection, Hands (client browser) for tool execution, and Voice (Edge) for response synthesis — is a genuine pattern born from constraint. Netlify’s 10-second serverless timeout forced the split, and the resulting loop progressed from a 6.5/10 hostile audit score to an 8.625/10 weighted composite after systematic refactoring. The automated code review confirmed production-grade CSRF protection, rate limiting, and connection resilience, while identifying connection recovery for unstable networks as the primary area for architectural refinement. For any Edge-hosted AI agent facing timeout limits, this three-piece decomposition is a transferable blueprint.

Second, the Eager RAG (Retrieval-Augmented Generation) strategy — pre-fetching project context before the user asks — is a rational trade-off for short-session lead generation. It burns tokens to reduce time-to-first-token (TTFT), which is defensible when the median session lasts 3–8 turns and 95% of visitors never return. Optimizing for first impression is sound product economics in a one-time-visitor profile.

Third, the cost efficiency claim is testable. The founder reports 6,300 pageviews served for $0.74 in API costs, with 631 MB of bandwidth handling 5,000+ simultaneous visitors. Even if optimistic by a factor of two, the order of magnitude represents a radical reduction versus traditional CMS hosting.

8.2 What Doesn’t Work Yet

SEO for agentic websites has no standard solution. The logs.axoworks.com dual-domain approach — 78 static HTML records acting as a crawlable corpus for a chatbot-primary single-page application (SPA) — is creative but architecturally fragile. The main site’s sitemap contains exactly one URL, client-side routing with no server-side rendering makes the interior invisible to Google, and the entire strategy depends on a secondary domain the founder describes as a “workaround.” If Google changes its treatment of cross-domain sitemap references, discoverability collapses.

The contextual grounding problem is acute. Multiple Hacker News testers reported that landing on axoworks.com without prior context left them staring at a blinking cursor with no understanding of what the business did. The founder added a whoami tagline, but the tension persists: a pure chatbot interface assumes the visitor already knows enough to ask the right questions.

The “AI-slop” tension — the recursive hollow feeling when both product and marketing are AI-generated — is a branding challenge the founder has not resolved. He admitted to using LLMs to draft content because he is “an AEC veteran, not a professional writer,” and the community’s criticism that the output reads as “clearly AI-gen” was direct. For any AI-first company, this meta-criticism is structural: the tool used to build the product undermines trust in the product itself.

8.3 The Unsolved Problems

Three frontier issues remain open. Liability tops the list. The founder’s candor — “Hallucinate a building code clause? We’re dead. Insurance won’t touch us” — exposes a vacuum in professional liability coverage for AI agents dispensing advice in regulated domains. While cyber insurance markets are beginning to offer AI liability endorsements, no standard product exists for AI agents operating in Architecture, Engineering, and Construction (AEC), where erroneous advice carries structural and legal consequences.

Accessibility raises second-order concerns. A blinking cursor interface raises Web Content Accessibility Guidelines (WCAG) 2.1 compliance questions for screen readers and keyboard navigation. Research on 106 deployed web chatbots found that over 80% exhibit critical accessibility failures, including missing ARIA roles and broken keyboard navigation. A site where the primary interface is the chatbot amplifies every failure mode.

Discoverability poses the longest-term question. Gartner projects that traditional search engine volume will drop 25% by 2026 as users shift toward generative AI, with AI-powered search potentially overtaking traditional search by 2028. If LLMs replace search engines as the primary discovery layer, the logic of SEO inverts: how does an agentic website get “found” by other agents? The current answer — publish static logs and hope crawlers index them — is a transitional hack, not a protocol.

The historical record is instructive: the only fully chatbot-primary implementations are either defunct or have reverted to hybrid designs. The sole active “chat-first” site, Satisfi Labs, explicitly preserves traditional navigation because users still need it. Axoworks is betting against this precedent.

8.4 The Bigger Picture

Axoworks is stress-testing whether a professional services firm can exist without a traditional web presence. If the experiment succeeds — if the agentic interface generates qualified leads at a fraction of traditional hosting cost, if the liability guardrails hold, if the SEO bridge sustains — it creates a playbook for every small consultancy tired of brochure websites and unqualified leads. The underlying question is practical: what is the minimum viable web presence for a knowledge-work firm in 2026?

If it fails, the experiment joins Firedrop and Adrian Zumbrunnen’s chatbot as a cautionary tale of technology outpacing user expectations. Firedrop’s Sacha operated in 2015–2017, before large language models made conversational interfaces genuinely capable; Zumbrunnen’s experiment predated modern RAG and guardrails. Axoworks has better tools, but it is testing the same hypothesis: that users will accept conversation as a substitute for navigation.

The deeper implication is that the web is bifurcating. One branch optimizes for human browsing — scrollable pages, semantic HTML, visual hierarchy. The other optimizes for machine discovery — structured data, knowledge graphs, agent-callable endpoints. Axoworks is trying to live entirely in the second branch while using the first as a prosthetic. Whether a small firm can survive on the machine-only side is the question this experiment is actually running. The answer will not come from the technology stack. It will come from whether visitors, given a blinking cursor and no map, choose to stay and type.

References

1. Axoworks founder, Hacker News Show HN post #47441587, March 19, 2026. https://news.ycombinator.com/item?id=47441587. “I got tired of paying Wix $40/month for a brochure that couldn’t answer simple service questions.” “The stack is completely duct-taped.” “If a client drops mid-query, their session vanishes. No server-side queues.”
2. “Serverless Functions Limits.” Netlify Support Forums. 2021. https://answers.netlify.com/t/serverless-functions-limits/36204; “How to bypass the Netlify serverless function timeout?” Damian Wroblewski. 2024. https://damianwroblewski.com/en/blog/how-to-bypass-the-netlify-serverless-function-timeout/
3. “Edge Functions limits.” Netlify Docs. 2025. https://docs.netlify.com/build/edge-functions/limits/
4. “Axoworks Neural Concierge - Implementation Audit Report.” Self-initiated automated DeepSeek code review. 2026-02-20. Published at https://logs.axoworks.com/audit-2026-02-19-v148.html. Note: This review was conducted by DeepSeek at the founder’s request using a “Hostile Auditor” prompt. It is not an independent third-party audit. Score progression: 6.5/10 (initial hostile audit, ~Jan 28, 2026) → 8.0/10 (post-refactor, ~Feb 3, 2026) → 8.625/10 (weighted composite, Feb 19, 2026). See Reddit r/SideProject posts by u/Axotopia: https://www.reddit.com/r/SideProject/comments/1qp3yyf/ and https://www.reddit.com/r/SideProject/comments/1qvamdw/
5. Axoworks Neural Concierge Architecture & SEO Interim Solution — Dimension 02. Research_AxoTech. Jun 2026. Direct inspection of robots.txt and sitemap.xml on both domains; 78 records and 67 URLs confirmed by live fetch. PII exposure acknowledged by founder in HN reply to pavel_lishin.
6. Hacker News Show HN post #47441587, March 19, 2026. 43 comments, 20 points. https://news.ycombinator.com/item?id=47441587
7. Axoworks founder, Hacker News original post, March 19, 2026. https://news.ycombinator.com/item?id=47441587. “Hallucinate a building code clause? We’re dead. Insurance won’t touch us.”
8. Research Dimension 03 — Comparable Website Research. 2026-07-15. Internal research report. Methodological note: 25 search angles and 35 sources is thorough but not exhaustive.
9. Landbot. “How to Convert a Landing Page into a Chatbot.” May 2021. https://landbot.io/blog/how-to-convert-a-landing-page-into-a-chatbot
10. Built In. “How to Design for Conversation-First Web Experiences.” November 2025. https://builtin.com/articles/design-conversation-first-web-experiences
11. Zumbrunnen, Adrian. “My chatbot is dead · Why yours should probably be too.” October 2020. https://azumbrunnen.me/blog/my-chatbot-is-dead/
12. Zumbrunnen, Adrian. “Technical and social challenges of conversational design.” June 2016. https://azumbrunnen.me/blog/technical-and-social-challenges-of-conversational-design/
13. Wired. “When Websites Design Themselves.” September 2017. https://www.wired.com/story/when-websites-design-themselves/
14. ChatGate. “Orchids: Chat to Build Apps and Websites.” October 2025. https://chatgate.ai/post/orchids/
15. Blink.new. “How to Build an AI Chatbot.” April 2026. https://blink.new/blog/how-to-build-ai-chatbot
16. Koder.ai. “Investors.” 2026. https://koder.ai/investors