From Portfolio to Agent: How Axoworks Built One of the Web’s First Agentic AI Websites — and the Engineering Traps That Came With It
By Axoworks Technical Review | JULKY 1, 2026
---
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, codebase audit, founder’s public statements, social media archives, Hacker News community thread, and comparative web research.
Executive Summary
On January 1, 2026, Axoworks LLC—a small building design consultancy based in the Pacific Northwest—deleted its entire Wix portfolio and replaced it with a production-grade AI agent called “The Concierge.” The founder, 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 a systematic search across twenty-five query angles and thirty-five sources identified no comparable example 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, the founder 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. The founder conducted a self-initiated automated code review using DeepSeek, which scored the system on a progression from 6.5/10 (initial “hostile auditor” run, January 2026) to 8.0/10 (post-refactor, early February) to a weighted composite of 8.625/10 (February 19 audit using a three-segment weighted methodology).[^2] The review identified production-grade CSRF protection, rate limiting, and exponential backoff, while flagging 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 a sliding-window session memory backed by Supabase, with a lightweight in-memory cache for resilience.[^3] The founder has publicly claimed that fewer than five percent of visitors ever return, implying that persistent cross-session storage offers limited value for this traffic profile.[^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 client-side routing and no server-side rendering, 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 posted on March 19, 2026, that functioned as an unsolicited adversarial audit. Forty-three comments from community members probed guardrail gaps, tone problems, missing business context, and privacy exposures.[^6] The founder responded to every criticism transparently, adjusting guardrails, softening the 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
The founder, 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 a portfolio, listed contact information, and offered a generic inquiry form. Visitors browsed photographs and either left or submitted a message that the founder then had to qualify manually. In a public post, the founder 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 small firm based in the Pacific Northwest, 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 client-side 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:
DIMENSION BEFORE (WIX PORTFOLIO) AFTER (AI CONCIERGE INTERFACE)
Primary interface Static pages, scrollable gallery Terminal-style SPA with single input field
Navigation Multi-page menu hierarchy Three hash routes: INQUIRE, THOUGHTS, DEPLOYMENTS
Lead qualification Passive form; principal qualifies manually Active intent detection via LLM; #HOT_LEAD tag triggers Discord webhook
Content delivery Pre-written text, fixed photographs Dynamic RAG from project corpus
Language support English only Multilingual via DeepSeek models with manual language toggle
SEO strategy Conventional on-page optimization Client-side SPA with no SSR; separate logs domain as SEO bridge[^10]
Hosting cost $40/month (Wix) Netlify Edge serverless, self-reported as “pennies”[^11]
Information persistence Static pages stored indefinitely Sliding-window session memory backed by Supabase; lightweight in-memory cache fallback[^12]
Visitor experience Self-directed browsing; visitor infers capabilities Agent-directed dialogue; agent probes intent and responds to project specifics
Bandwidth efficiency Image-heavy portfolio; larger payload per visit 631 MB total bandwidth served to 5,000+ unique visitors in 30 days (self-reported)[^13]
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 client-side 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 the founder 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 has publicly claimed to have had little recent coding experience.[^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 inference call, even with streaming, can exceed the 10-second boundary when followed by a tool invocation 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 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 performs intent detection and determines whether external tools are required. It does not execute the tools itself. Instead, it outputs a JSON instruction encoding the agent’s decision about what work must happen next.[^4] This is not a stub or a placeholder; it is a control signal. 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 receives the JSON instruction from the Brain and executes the actual tool call. The tool itself runs as a separate serverless function — web retrieval for search, 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.
Copy block
flowchart LR
subgraph A["Client Browser"]
C["Client Hook"]
end
subgraph B["Netlify Edge"]
D["Brain:
Intent Detection
+ JSON Instruction"]
F["Voice:
Final Synthesis
+ Streaming"]
end
subgraph E["Serverless Functions"]
G["Web Search"]
H["Send Email"]
I["Schedule"]
end
C -->|"User message"| D
D -->|"JSON instruction"| C
C -->|"Execute"| G
C -->|"Execute"| H
C -->|"Execute"| I
G -->|"Results"| C
H -->|"Results"| C
I -->|"Results"| C
C -->|"Tool result"| F
F -->|"Streaming response"| C
Table 1: The Distributed Agent Loop — Component, Location, Responsibility, and Timeout Constraint
COMPONENT PHYSICAL LOCATION CORE RESPONSIBILITY TIMEOUT CONSTRAINT
Brain Netlify Edge Function Intent detection; JSON instruction output 50 ms CPU time per request; wall-clock I/O excluded[^3]
Hands Client browser (React hook) Tool execution via separate serverless functions Client-side timeout with retry and backoff[^4]
Voice Netlify Edge Function Final response synthesis; streaming to user Same Edge limits as Brain; single inference only
Search Tool Serverless function Web retrieval and grounding Netlify 10–26 second synchronous limit[^2]
Email Tool Serverless function Lead dispatch and notification Netlify 10–26 second synchronous limit[^2]
Rate Limit Netlify Edge + persistent storage Request throttling per IP per time window Edge-level; persistent storage for state[^4]
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 The Automated Code Review: A Score Progression, Not a Single Verdict
The article’s original draft presented the system’s technical evaluation as an “independent technical audit” scoring 8.625/10. This framing is inaccurate and requires correction.
The evaluation was a self-initiated automated code review conducted by DeepSeek at the founder’s request. The founder described the process on Reddit: prompted by community feedback, he ran a “Hostile Auditor” prompt against his own codebase to stress-test the implementation beyond the supportive bias LLMs typically exhibit when asked “is this good?”[^audit-history]
The review progressed through three distinct phases, each with a different score:
PHASE DATE PROMPT TYPE SCORE VERDICT SOURCE
1. Initial hostile audit ~Jan 28, 2026 “Hostile Auditor” 6.5/10 “Sophisticated Prototype” — flagged 800-line “God Components,” client-side API key exposure, high latency Reddit r/SideProject (u/Axotopia)
2. Post-refactor audit ~Feb 3, 2026 Same “Hostile Auditor” prompt 8.0/10 “Highly Innovative, Production-Ready” — after migration to Edge Functions, RLS enforcement, latency fixes Reddit r/SideProject (u/Axotopia)
3. Weighted composite audit Feb 19, 2026 Three-segment weighted scoring 8.625/10 “APPROVED” — weighted composite of Agentic Properties (9/10, 40%), Fit-for-Purpose (8.5/10, 35%), Security & Stability (8/10, 25%) logs.axoworks.com/audit-2026-02-19-v148.html
The 8.625 composite is mathematically derived: (9×0.40) + (8.5×0.35) + (8×0.25) = 8.575, which the audit rounds to 8.6/10 or presents as 8.625 depending on precision.[^4] The audit also scored Accessibility at 6/10 and Security at 7/10 (a separate sub-score from the 8/10 Security & Stability segment), neither of which was included in the composite.[^audit-history]
Why the framing matters. An LLM reviewing code at its creator’s request is fundamentally different from a third-party security firm conducting an independent audit. The LLM has no professional liability, no independence of interest, and no ability to test runtime behavior beyond static code analysis. Calling this “independent” lends an unearned veneer of third-party verification. The review has genuine analytical value — particularly the hostile-prompt methodology, which counteracts LLM sycophancy — but it must be accurately characterized for readers to assess its weight.
What the review verified. The automated review confirmed three security mechanisms: CSRF protection using a double-submit pattern with timing-safe comparison, Edge-level rate limiting with persistent storage and in-memory fallback for development, and client-side connection resilience with retry, timeout, and abort capabilities.[^4]
The critical gap. The review identified that the architecture lacks a server-side job queue. If a client disconnects during tool execution — for example, if the user closes the browser tab while a search tool is still running — the tool may complete on the server, but no synthesis call will be triggered, and the result is lost.[^4] The founder has acknowledged this gap publicly on Hacker News: “If a client drops mid-query, their session vanishes. No server-side queues.”[^1] This gap was classified as high severity by the automated review. The founder has stated that for anonymous short-duration sessions typical of the site’s traffic profile, the overhead of a job queue is unwarranted, and dropping results on closed tabs saves compute.[^4] This is a defensible architectural trade-off for a low-traffic consultancy site, but it would become a liability at scale or in environments where transaction integrity is required.
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 in the tool-detection middleware.[^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 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.
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 special 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.
PRE-FETCH TARGET TRIGGER WHEN INJECTED TOKEN COST BENEFIT PER SESSION COST-BENEFIT (3–8 TURNS)
Project context (zoning, setbacks) First-response trigger On first user message High (fixed) Near-zero TTFT Favorable if ≥2 project questions
Image assets (site photos, renderings) First-response trigger On first user message Very high (multimodal) Rich visual grounding Favorable if session converts to lead
Vector search results User query received Per turn Low per query Precision retrieval Neutral; standard RAG behavior
SiteContext fallback Vector search returns empty On failed retrieval Moderate Prevents empty response Always favorable; insurance against silence
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 uses a sliding-window approach. The system maintains a 20-message sliding window per session, stored primarily via Supabase RPC calls with an in-memory cache fallback. [^1] The founder has publicly claimed that fewer than 5% of visitors ever return, and that persistent databases were considered “bloat” for this traffic profile. [^1] However, the codebase reveals extensive Supabase usage: multiple tables for content nodes, library data, chat messages, email logs, appointments, user memory, and projects are all actively used, with dedicated RPC functions for context retrieval, message persistence, and memory updates. The design appears to be a pragmatic trade-off: lightweight session caching for responsiveness, with Supabase as the backing store for conversation history, lead data, and vector search.
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 if the cache has expired. The design accepts this as a cost of the 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 models that power 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. HN member sonofhans observed: “I see no attacks, only simple questions. Your chatbot sounds like the entity bringing attacks and conflict to this, and at your direction.”[^4] 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]
SCENARIO DETECTED INTENT PERSONA ACTIVATED EXAMPLE RESPONSE TONE
Homeowner asks about permitting timeline Service inquiry, low adversarial Warm principal Collaborative, explanatory
Licensed architect challenges business model Peer attack, high adversarial Defensive bulldog Assertive, counter-argumentative
Architecture student requests career advice Learning posture, non-threatening Warm principal Mentoring, encouraging
User posts low-effort troll Disruption intent Defensive bulldog Dismissive, redirects to inquiry
User asks non-AEC question (e.g., Python code) Out-of-domain Guardrail (neutral) Deflection to AEC scope
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. HN member spzb demonstrated that the bot answered a Python request for calculating π, produced a three-day itinerary for Vancouver, and responded 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 client-side routing with no server-side rendering. The site’s internal navigation routes — INQUIRE, THOUGHTS, and DEPLOYMENTS — exist only inside the browser’s JavaScript execution context. The server receives only the base URL https://axoworks.com/ regardless of which route is active. Search engines see the same. Googlebot, along with Bing and virtually every major crawler, indexes the base URL as a single page because it cannot execute client-side JavaScript to discover the routed content. [^1] A site with fifty conceptual routes inside a SPA therefore has, from the crawler’s perspective, exactly one page. [^2] Client-side routing without server-side rendering is a well-documented anti-pattern for SEO: crawlers that do not render JavaScript see only the empty shell, and even those that do may delay second-pass rendering by minutes to weeks. [^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.
CHALLENGE MECHANISM AXOWORKS STATUS
Crawler cannot discover chatbot content Content generated only on user query; no static pages No indexable topic pages or knowledge-base articles on main domain
Client-side routing without SSR Routes exist only in JavaScript; crawlers see only the shell INQUIRE, THOUGHTS, and DEPLOYMENTS are not independently crawlable
Single-page sitemap sitemap.xml lists only the root URL One URL submitted; no map to internal routes or content
No server-side rendering (SSR) Googlebot sees empty HTML shell on first crawl; content loads after JS execution Initial response contains only
; no pre-rendered text
AI crawlers bypass JavaScript GPTBot, ClaudeBot, and PerplexityBot read raw HTML without rendering Content invisible to AI-powered search and answer engines
No per-route metadata Meta tags and Open Graph data are static in the shell Same title and description for all routes; no distinct social previews
The table isolates each failure mode, but the modes are not independent. Client-side routing without SSR ensures that every route is invisible to crawlers, 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 execute JavaScript, the content would still be loaded dynamically and may not be indexed reliably. 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 client-side 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 site that relies on JavaScript to render its content without server-side pre-rendering is invisible to crawlers that do not execute scripts — a category that includes most AI platform crawlers as of mid-2026. [^8] The correct approach for SPAs is server-side rendering (SSR) or static generation, which produces crawlable HTML that search engines can index without executing JavaScript. 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. HN member daveguy noted that visitors had “very little idea of what you do or why I would want to hire you” based on just the website. [^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 client-side routing with no server-side rendering 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 execution context, invisible to bots that do not render 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 INQ_LOGS (~18), SYS_LOGS (~8), CHAT_LOGS (~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 its JavaScript data store 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.
PROPERTY AXOWORKS.COM (MAIN SPA) LOGS.AXOWORKS.COM (SEO BRIDGE)
Routing Hash-based, client-side Static HTML, server-addressable
Sitemap 1 URL[^4] 67 URLs[^5]
robots.txt Cross-references logs sitemap[^3] Blocks JS data, allows pages[^2]
Content discovery Dynamic — only on user interaction Static — always crawlable
Primary audience Human visitors Search engine and AI crawlers
Implementation cost Netlify Edge (serverless) Static HTML hosting (minimal)
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 carries a metadata block with ID, category, status, and verification flag[^11]. It contains a chat transcript or project analysis with navigation links making 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).
CATEGORY COUNT PURPOSE SEO VALUE RAG VALUE
ARTICLES ~16 Thought leadership in multiple languages High: long-form, keyword-rich High: concept-dense, quotable
PROJECT INQ_LOGS ~18 Feasibility studies, zoning analyses, case studies Very High: specific long-tail queries Very High: domain-specific factual grounding
SYS_LOGS ~8 Audit logs, status reports, migration notes Medium: technical authority Medium: operational transparency
CHAT_LOGS ~1 Conversation transcripts (architect vs. concierge) High: narrative, long-tail High: structured arguments
BROCHURES ~6 Service descriptions in 4 languages High: commercial intent Medium: product context
BIOS ~14 Team resumes, LinkedIn profiles, experience pages Medium: E-E-A-T signals Low: personal data, limited reuse
RESOURCES ~2 Photos, miscellaneous assets Low: thin content Low: image-dominant, minimal text
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 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.
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 a team member’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 after pavel_lishin identified the specific exposure: “I guess if Tina is fine having her email address & phone number publicly available, that’s her business.”[^6] The founder’s final response: “You caught me. Tina is my co-founder, so those are her business contacts, but you’re absolutely right, still a dumb move to leave them exposed instead of routing everything through single secure point of contact. I completely missed them when I dumped our raw resumes into the RAG context. My oversight for blindly claiming the logs were totally clean. 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 the JavaScript data store 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 this research, the finding is that 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.[^dim03]
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.[^landbot-blog]
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.[^builtin-satisfi]
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.[^zumbrunnen-dead] 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.[^zumbrunnen-challenges]
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.[^wired-firedrop]
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.[^chatgate-orchids][^blink-blog][^koder-investors]
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.
WEBSITE CHATBOT AS PRIMARY? TRADITIONAL NAVIGATION? INDUSTRY STATUS NOTES
Landbot.io Homepage only Yes (rest of site) SaaS / No-code Active Homepage is a chatbot; internal pages use standard nav
Satisfi Labs Prominent (hybrid) Yes (fixed left panel) Live experiences Active Two-column chat + nav design; deliberately hybrid
Adrian Zumbrunnen Was primary (2016) Now fully traditional Design / Portfolio Reverted Experiment abandoned; author wrote “My chatbot is dead”
Firedrop (Sacha) Yes (when active) No (when active) Website builder Defunct True chatbot-primary; limited to one-page sites
Orchids Product only Yes (marketing site) Developer tools Active Chat is the IDE interface; company site is traditional
Blink.new Product only Yes (marketing site) No-code builder Active Chat drives the builder; public site is conventional
Koder.ai Product only Yes (marketing site) No-code platform Active Chat is the product interface; marketing site is standard
Axoworks Aiming for yes No (planned) AEC / Real Estate Active No known AEC precedent found in research
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.” [^1] 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. [^1]
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.” [^1]
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. [^1]
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.” [^1] sonofhans observed that the thread contained “no attacks, only simple questions” and that the chatbot itself was “the entity bringing attacks and conflict.” [^1]
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.” [^1] 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.” [^1] To the PII exposure: “a dumb move,” followed by “updated the backend and permanently scrubbed the contacts.” [^1]
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.” [^1] He accepted that his AI-assisted prose had produced a hollow quality that undermined the project’s claimed authenticity. [^2]
The table below compiles the major findings, the founder’s response, and the documented status of each fix.
HN FINDING REPORTER FOUNDER’S RESPONSE STATUS OF FIX
Bot answered non-AEC questions (Python π, Vancouver) spzb “I’ll be tightening the system prompt” Acknowledged; tightened [^1]
Business identity invisible on direct visit daveguy “Need to add a quick whoami or initialization script” Acknowledged; proposed tagline [^1]
PII exposed in public RAG logs pavel_lishin “Permanently scrubbed the contacts” Fixed; backend updated [^1]
Tone overly aggressive / “defensive bulldog” sonofhans “Prompt injected to tone down the bulldog attitude” Adjusted; verified with re-test [^1]
AI-generated prose hard to read tetrisgm “Had to use an LLM to clean up my draft” Acknowledged; proposed bullet formatting [^1]
Log interface unreadable as public content stuaxo “Clean up views and hide slop behind a toggle” Acknowledged; planned UI cleanup [^1]
Site persona “outcompeting” shitposters dolebirchwood “I’ll dial it back on my next refinement” Acknowledged; planned tone refinement [^1]
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. [^2]
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. [^1]
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. [^2] 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.[^1] The automated code review confirmed production-grade CSRF protection, rate limiting, and connection resilience, while identifying the job queue gap as the primary architectural limitation.[^1] 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.[^2] 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.[^3] 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.”[^4] 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.[^5]
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.[^6] 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.[^7] 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.[^8]
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.[^9] 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.[^10] 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.
COMPARABLE EXPERIMENT INDUSTRY CHATBOT AS PRIMARY? OUTCOME STATUS
Firedrop (Sacha) Website builder Yes Defunct; limited to one-page sites Failed[^11]
Adrian Zumbrunnen Personal portfolio Yes (2016) Reverted to traditional design; author wrote “My chatbot is dead” Abandoned[^12]
Satisfi Labs Live experiences Hybrid (two-column) Active; deliberately preserves traditional navigation Active[^13]
Axoworks AEC / Real estate Yes (aspirational) Active; no comparable AEC precedent found in research Unresolved
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.[^13] 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/
[^audit-history]: Axoworks founder (u/Axotopia), Reddit r/SideProject posts. “I let a Redditor roast my AI Agency’s code. 72 hours later, here is the result.” https://www.reddit.com/r/SideProject/comments/1qvamdw/ ; “I replaced my design firm’s entire website with a ‘Hybrid Monolith’ Agent.” https://www.reddit.com/r/SideProject/comments/1qp3yyf/. The founder describes running a “Hostile Auditor” prompt suggested by user thrarxx, receiving a 6.5/10 score, refactoring the architecture, and re-running the same prompt for an 8.0/10 score. Accessibility was scored 6/10 and Security 7/10 in separate sub-scores.
[^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.”
[^dim03]: 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. The absence of published examples does not prove absence of implementation, particularly in an industry where firms rarely publicize internal tools.
[^landbot-blog]: 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
[^builtin-satisfi]: Built In. “How to Design for Conversation-First Web Experiences.” November 2025. https://builtin.com/articles/design-conversation-first-web-experiences
[^zumbrunnen-dead]: Zumbrunnen, Adrian. “My chatbot is dead · Why yours should probably be too.” October 2020. https://azumbrunnen.me/blog/my-chatbot-is-dead/
[^zumbrunnen-challenges]: Zumbrunnen, Adrian. “Technical and social challenges of conversational design.” June 2016. https://azumbrunnen.me/blog/technical-and-social-challenges-of-conversational-design/
[^wired-firedrop]: Wired. “When Websites Design Themselves.” September 2017. https://www.wired.com/story/when-websites-design-themselves/
[^chatgate-orchids]: ChatGate. “Orchids: Chat to Build Apps and Websites.” October 2025. https://chatgate.ai/post/orchids/
[^blink-blog]: Blink.new. “How to Build an AI Chatbot.” April 2026. https://blink.new/blog/how-to-build-ai-chatbot
[^koder-investors]: Koder.ai. “Investors.” 2026. https://koder.ai/investors
---
*This article was produced by Axoworks for architecture professionals, BIM managers, design technologists, and visualization specialists exploring generative AI in controlled design workflows. The pipeline described is a real proof-of-concept executed under an accelerated timeline. All technical specifications, hardware configurations, and workflow parameters are documented as implemented. Identities and specific geographic locations have been anonymized.*
[ JUMP TO ORIGINAL SUBSTACK POST ]