Aligning the jueewo ventures family for agent-mediated audiences — a case study from inside the studio.
Client. jueewo ventures and its family of sites — jueewo.ventures, aipokit.com, yawninghero.com. Brief. Address the shift toward AI-assistant-mediated discovery without disrupting human visitors or rebuilding three static sites. Outcome. A shared content layer that LLM-based assistants — Claude, Grok, browser AI sidebars, any future MCP client — can search, cite, and reason over directly. The same layer also powers an in-site chat on each site, giving human visitors a credible AI assistant grounded in the family’s published content. Timeline. Roughly two weeks of focused work for the agent surface, plus an additional few days for the chat — architecture to live deployment.
By early 2026 the family’s prospects had developed a new habit. The same people who used to read the journal articles, the training overviews, the product pages were increasingly asking an assistant instead — “what does jueewo ventures do?”, “is there serious work on AI agents in BPMN?”, “how does Aipokit’s Moto product handle planning?”
The assistant would read a few pages on the visitor’s behalf, paraphrase what it found, and reply. Sometimes the citation was clean. Often it was not. Sometimes the wrong site got the credit; sometimes the right site got a wrong paraphrase. The visitor never landed on the page; the studio rarely knew the question had even been asked.
The problem was not the content. The content was good. The problem was the surface. An assistant skimming HTML and inferring structure is doing work that a properly structured interface ought to do for it. The family needed a parallel surface — one humans never see, but that assistants can consume cleanly.
The discipline of building that surface is starting to have a name: AXO — Agent Experience Optimization. It is to agents what UX is to people, and what SEO was to the search engine. A separate audience, a separate set of affordances, the same content underneath.
Three layers, each cheap, each compounding.
A guide file at the root of every site. llms.txt is a small plain-text file an assistant fetches to orient itself: what is here, where the important pages are, what kind of content is published. A few hundred words, hand-written, kept current. We wrote one for each of the three sites.
Clean structure throughout. The sites were already statically published and well-organised. Most of the work here was not undoing that — keeping the pages readable rather than burying everything in client-side JavaScript an assistant cannot run. A pass through the schema.org markup, the heading hierarchies, the URL shapes; nothing exotic.
A shared content endpoint. This was the substantive piece. Rather than leave each assistant to scrape and guess, we built a small server — at mcp-sites.yawninghero.com — that any MCP-compatible assistant can query: “search across the family for X”, “return the full text of this page”. The server harvests content from all three sites at build time and exposes a uniform interface. An assistant that connects gets exact passages with exact URLs; no more scrape-and-paraphrase.
Visible deliverables:
llms.txt and llms-full.txt on each site root./.well-known/mcp/server-card.json on each site — the discovery file an assistant reads first to find the family’s endpoint.mcp-sites.yawninghero.com, indexing 80 documents across the three sites at the time of writing.search, list_sites, get_page, and get_related — enough for any content lookup or topical adjacency lookup an assistant would want.What did not change: the pages humans visit. Same speed, same design, same content. Both the agent surface and the chat are additive.
Once the MCP server existed, the cheapest way to give human visitors a substantive AI assistant on each site turned out to be the same content layer the external agents were already using. The chat widget that sits in the corner of every family page is a thin orchestrator wrapped around the same search, get_page, and get_related tools an external assistant calls. A real LLM looks up an answer in the family’s published content, quotes the relevant articles with their actual URLs, and refuses to invent material when the question is outside the corpus.
Three things this is deliberately not, and each one matters for a business considering the same step.
Not a generic chatbot. The substance is your content, not the model’s training data. A visitor asking about a service gets your service page in a sentence, with the link — not someone else’s marketing copy from two years ago. The chat speaks in the register of the site that hosts it.
Not a meaningful cost. A typical chat turn — system prompt, one or two tool calls, a short answer — runs roughly 1,250 tokens on a small modern model, which is fractions of a cent per conversation. A thousand visitor chats costs less than a sandwich. There is no plausible traffic shape that makes this a budget concern.
Not locked to one vendor. Any provider speaking the OpenAI chat-completions schema works — OpenAI, Anthropic, Google Gemini, Groq, Cerebras, OpenRouter, locally-hosted Llama via Ollama. Switching providers is a single configuration change; switching back is the same. The architecture survives the next shake-out in the model market.
The chat is, in effect, the human-facing twin of the agent-facing MCP surface. Same backend, same content, two front doors.
The clearest demonstration was a single non-trivial query, posed to multiple assistants in turn:
“Find the connection between BPMN and AI agents across these sites.”
Claude (via Desktop and Code), Grok (via xAI’s Build mode), and a browser AI sidebar via WebMCP all produced coherent, cited, multi-source answers. Each named the relevant journal articles, the underlying product implementations, and the through-line connecting them — using the studio’s content, attributing the studio’s URLs, building a synthesis the individual articles never made explicit on their own.
The companion piece on jueewo.ventures, From SEO to AXO, walks through the demonstrations in detail.
The instrumentation matters as much as the answer. Every query — whether from an external agent or from a visitor talking to the in-site chat — is logged at the MCP server, with the two audiences kept separate so they can be analysed independently. The studio can see which topics each audience reaches for, which assistants are most active, which pages get cited most often, and what the in-site chat is costing in tokens and dollars per period. SEO told us who clicked; AXO tells us what an assistant chose to synthesise from, and the chat tells us what visitors actually want to know in their own words. Both metrics are closer to brand equity than to traffic — and most categories have nobody measuring either yet.
This pattern is not unique to us. Any content-led business — agency, consultancy, publisher, training provider, technical-software vendor — faces the same audience shift, with most of the same building blocks already in place. If a company has written substantively about what it does, AXO is the discipline that lets that writing keep earning into the agent era.
Three observations from the work:
If you have started to wonder where your category sits on this curve — what your prospects ask their assistants, what those assistants find when they look — we’d be glad to take a look at your site.
An AXO assessment is typically a one- to two-week engagement: a concrete report on what is already agent-ready, what is missing, what to fix first, what to skip, and where an in-site chat would earn its place. No upsell. From there, we can either run the implementation — agent surface, chat widget, both — or hand the playbook to your engineering team and consult while they ship.
contact@jueewo.com reaches us directly.