![\"Personal](\"/images/core-personal/00002-parlor-automaton.png\")
The old core-personal site included a chat interface for asking questions about the website.
\nThe original framing called it a parlor automaton. The practical version is simpler: a visitor asks a question, the site retrieves relevant local content, and an LLM answers from that context.
\nThe product question was not “can I add a chat widget?” The better question was:
\nCan a personal site become queryable without creating an expensive runtime dependency?
\nThere is a profile question inside that product question. If someone is curious enough to ask the site a question, the site should help them reach the right evidence quickly. That might be a collaborator evaluating judgment, a potential customer looking for proof, or a reader trying to understand the arc of the work.
\nThe first version used a manual RAG approach:
\nThis was intentionally pragmatic. It worked well enough to publish, and it made the cost model visible.
\nThe early problems were predictable but useful.
\nSome answers were cut off when the context payload was too large or poorly shaped. Some chunks were technically relevant but awkward because they were split at bad boundaries. Index freshness was also too manual: publishing new content should automatically update the knowledge base.
\nThe important lesson is that “chat with your site” is not one feature. It is a small retrieval product with a pipeline, budgets, quality controls, and maintenance requirements.
\nIt is also a small trust surface. Bad retrieval creates confusion at the exact moment someone is showing intent. Good retrieval can make the next step obvious without turning the site into a funnel.
\nThe build pipeline should own indexing.
\nWhen the site builds, it should discover posts and pages, extract clean text, keep useful metadata, chunk by headings and paragraphs, rebuild the search index, and publish the updated knowledge base alongside the site.
\nRetrieval also needs source references, duplicate reduction, better chunk boundaries, and a context budget that prefers fewer high-quality passages over many weak ones.
\nThe cost dial should stay explicit:
\nreboot.md already ships raw Markdown, JSON post routes, feeds, llms.txt, and llms-full.txt.
That makes the site more useful to AI systems before adding a chat interface. The lesson from core-personal is that machine-readable publishing should come first. Chat can come later, if the underlying context is clean enough to deserve it.
\nThat structure also supports the work around the work without changing the writing into a pitch. The archive can answer: what I build, who I help, what I have learned, what I am testing, and where the proof lives. Humans can browse it. Machines can retrieve it. Both should land on a coherent profile.
\nThe durable part of the experiment is not the Victorian interface. It is the constraint:
\nKeep public context structured, cheap to retrieve, easy to cite, and economical enough to keep alive.
","headings":[{"id":"the-experiment","text":"The experiment","level":2},{"id":"the-architecture","text":"The architecture","level":2},{"id":"what-broke-first","text":"What broke first","level":2},{"id":"what-should-change","text":"What should change","level":2},{"id":"why-this-connects-to-reboot-md","text":"Why this connects to reboot.md","level":2}],"source":{"origin":"core-personal Victorian-style Parlor Automaton post","tools":["Codex"],"humanEdit":"Imported from core-personal and rewritten into reboot.md operating-log voice"}}