From a Website Assistant to a Personal Knowledge Interface

The first version of the assistant on this site had a narrow job: let a visitor ask a question about my work and get an answer grounded in something I had actually published. That sounds like a chatbot feature. It eventually forced a more useful question: if an AI is going to work with my data, where should the intelligence around that data live?

My answer is now Kioku, the personal data system behind this site. The public assistant is still there, but it has become one client of a larger interface. My own AI clients use a separate MCP connection to search private knowledge, query structured records, capture new material, and start controlled workflows. Both paths meet the same source of truth. They do not share the same permissions.

That distinction matters more to me than any particular model or vector database. Models will change. The boundary around personal data should survive them.

It started as a website Q&A assistant

A language model knows a great deal about public subjects, but it does not automatically know what I built last month, why I made an architectural choice, or which details on my résumé are current. Asking it to answer from memory produces fluent guesses. Pasting every page into every prompt is expensive, slow, and soon becomes impossible as the site grows.

Retrieval-augmented generation, usually shortened to RAG, is a practical way around that problem. Before asking a model to answer, the system searches a collection I control and supplies a small set of relevant passages. The model is not being retrained on my site. It receives better context for this particular question.

Embeddings make that search less literal. They turn text into coordinates that roughly preserve meaning, so a question about “career changes” can find a passage that says “moved from one role to another” even when the wording differs. PostgreSQL remains the main database, while pgvector adds the similarity search needed to compare those coordinates. The model then writes an answer from the retrieved passages and attaches links back to the source pages.

The citation is part of the product, not decoration. A visitor should be able to move from an answer to the page that supports it. When the system cannot find enough public evidence, a restrained “I don’t know” is better than an impressive invention.

The visible interaction stays simple. A question goes to /ask; the answer appears progressively; relevant sources arrive with it. Server-Sent Events, or SSE, carry that stream to the browser so the user does not wait for a complete response before seeing anything. Complexity exists behind the screen, but the contract with the visitor is just a grounded conversation with inspectable sources.

Why RAG moved into Kioku

The earliest design treated retrieval as a feature of the website. That was reasonable while the website was the only place using it. It became awkward as soon as Kioku began holding more of the underlying material: articles, projects, saved knowledge, and structured parts of my personal history.

If the site owns the index, every new client has to depend on the site or reproduce its retrieval rules. Changes to visibility must be copied into more than one place. A background import can update Kioku while the website still searches yesterday’s view. The component presenting the data gradually becomes responsible for understanding all of it.

I moved the corpus, indexing, retrieval, and answer orchestration into Kioku instead. The site now owns what is specific to the site: checking that traffic came through the expected edge, limiting bursts from a visitor, and passing the response stream to the browser. Kioku validates the question, searches public material, runs the bounded agent loop, calls the model through a replaceable LLM gateway, and shapes the citations. The website is a client, not a second knowledge backend.

The recent backend refactor made that separation explicit. HTTP endpoints, MCP, and command-line jobs are sibling adapters. They handle their own authentication and response formats, then call the same protocol-neutral application use cases. MCP does not secretly call the REST API, and the REST API does not contain a private copy of the business logic. This is a conventional application boundary, but it has an important effect: the rules around the data can be reused without tying them to one transport.

One data source, two read boundaries

“The public assistant only asks for public results” is not a security model. Prompts can be misunderstood, application flags can be passed incorrectly, and future code can accidentally broaden a query. I wanted the public/private distinction to be enforced below the conversational layer.

Kioku therefore has two retrieval paths. Public /ask reads a database view and role that can see only public chunks. The owner-facing knowledge search reads a different private index through a separate database capability. The public function does not accept an include_private switch. There is no magic value that turns a visitor query into an owner query.

The two paths still share useful machinery: text is divided into stable passages, embeddings are generated consistently, and the same PostgreSQL installation stores the indexes. Sharing infrastructure is not the same as sharing authority. The database decides which material is reachable before the model sees any context.

This makes the architecture easier to reason about. The public model can be prompted to ignore private information, but it does not receive private information in the first place. If someone tries to induce it to reveal a private note, retrieval has nothing private to return. Kioku’s bilingual quality checks include these privacy-inducement cases alongside ordinary questions, citation checks, and no-answer behavior. Evaluation does not replace access control, but it catches regressions in the experience built on top of it.

The same principle applies to the outer layers. The site can reject abusive traffic before it spends embedding or generation quota. Kioku applies its own global admission and cost limits because it is the component that actually talks to those providers. Each layer owns the limit it can enforce accurately.

This separation also keeps future clients honest. A mobile app, another website, or a local tool could use Kioku later, but it would still need an explicit identity and capability. “Uses the same data” no longer implies “may see the same data.”

MCP lets AI do more than search

RAG is useful when the answer lives in prose. It is less suitable for questions that have an exact, structured answer. “What did I write about database ownership?” is a search problem. “How many flights did I record last year?” or “Which projects use Rust?” should be answered from records and relationships, not by asking a model to estimate from a handful of semantically similar passages.

That is where MCP changed the shape of the project. The Model Context Protocol gives an AI client a described set of tools rather than one large prompt containing my data. Through Kioku’s private MCP endpoint, my AI can search knowledge, read authoritative records, capture a new note, connect related entries, or start a workflow. The useful point is not the number of tools. It is that each operation has a specific contract and a specific permission.

Search itself combines two different strengths. Semantic search finds related meaning even when the words differ. Literal search remains better for an exact name, identifier, or phrase. Kioku fuses both rather than forcing the model to guess which search mode will work before it has seen the answer. For numerical or categorical questions, a structured tool can bypass embeddings entirely and query the relevant domain.

This creates a healthier role for the model. It chooses and combines capabilities, but it does not become the system of record. A database query establishes an exact fact. Retrieval supplies passages for explanation. The model turns those results into a useful response. Each part does the job it is suited to do.

MCP also makes Kioku useful during work, not only after publication. If I discover a useful article while discussing a problem with an AI, the conversation can capture it into the knowledge base instead of leaving it trapped in chat history. It can later suggest related entries, while creating the actual link remains a deliberate write. Similar patterns apply to personal records and longer-running jobs.

The private client is powerful, but it is not treated as an unrestricted owner session. It has its own revocable credential and database role. Tool definitions declare whether an operation reads, writes, starts work, or has an external effect. Calls are checked against capabilities, potentially dangerous actions can require approval, and writes are auditable. The model is an agent acting for me; it is not me.

Keeping the data fresh and private

A knowledge interface becomes unreliable if its search index is a forgotten snapshot. Rebuilding every embedding after every edit would keep it correct, but it would waste time and provider quota. Waiting for the next deployment would make newly captured material feel broken.

Kioku tracks a content hash for each indexed source. When text or visibility changes, only the affected passages are regenerated. New captures schedule follow-up indexing so they can become searchable without a full release. A complete rebuild still exists as a repair and verification path, not as the normal way every small change reaches search.

Visibility is part of the indexed identity. Changing a note from private to public is a meaningful content change even if not one word of the note changed. Renaming an addressable page also removes the old identity before the new one is promoted, preventing stale public results from lingering behind a former URL.

Freshness is only half of trust. Capture defaults to private. The MCP agent cannot publish content merely because it can create it. Public retrieval is served by the restricted path described above. Operations with effects can be gated by confirmation, and audit records make writes reviewable later. These are deliberately ordinary controls around an AI-shaped interface.

The model providers are kept outside the ownership boundary. Kioku sends the minimum context needed for an embedding or answer, through gateways that can be replaced as models and prices change. The durable copy, visibility rules, links, revisions, and structured records remain in my database. Switching a model should be an integration change, not a data migration.

There are still trade-offs. Semantic indexes can miss the right passage. Streaming generation can fail partway through. A useful personal system will always contain information that should never be public. The goal is not to make those risks disappear behind an “AI” label; it is to give each one a visible boundary, a fallback, and a place to test it.

What I built was not merely a chatbot

The /ask assistant is still the most visible part of this work, and it remains intentionally small: ask about my public work, receive a sourced answer, follow the links if you want the full context. But its backend is no longer designed around a chat box.

Kioku now exposes two views of the same personal source of truth. The public view is narrow, cited, and unable to reach private material. The owner view can search more broadly, use exact domain tools, capture knowledge, and coordinate controlled work. Their shared application layer prevents duplicated behavior; their separate database capabilities prevent shared authority.

That is the roadmap I care about. Not recording everything for its own sake, and not adding tools simply because a model can call them. The aim is a durable personal knowledge interface: data I can keep, rules I can inspect, and multiple AI clients that remain replaceable.

The implementation will continue to evolve in Kioku↗, while the public client lives in the misoto22-site repository↗. The lasting design decision is simpler than either codebase: put intelligence close to the data, and put permissions closer still.