Ethos: Connecting a Self-Hosted Knowledge Base to ChatGPT and Claude Over MCP

A language model has no memory between sessions. Each conversation begins with an empty context window, and anything the model knows about your situation has to be placed inside that window before it can reason about it. This is a well understood constraint, and the standard mitigation is retrieval: keep the durable knowledge outside the model, then pull the relevant fragments in at question time.

The market's answer has mostly been per-vendor memory. ChatGPT retains facts about you, Claude retains projects, and each store is proprietary and non-portable. That solves recall inside one product while fragmenting it across the tools people actually use.

Ethos is the system I built to test the other arrangement: keep the knowledge in an open format on infrastructure I control, and let any assistant read and write it through a standard protocol.

Since this article first ran, the system has grown a memory layer, artifact creation, and document handling, so this version describes the current architecture. The screenshots are the actual application running against a demonstration vault.

The substrate

The storage layer is deliberately unremarkable. A vault is a folder of Markdown files on a server. Notes reference each other with wiki-style links, tags and folders provide organization, and a graph view renders the resulting connections. Separate vaults isolate unrelated bodies of work.

Two properties of that choice matter more than any feature:

• Plain text outlives tools. Markdown in folders is readable by any editor, greppable by any script, versionable by any source control, and needs no export path if the application is ever retired.
• No database means no lock-in surface. There is no proprietary index to reverse engineer in order to get content back, because the content was never anywhere else.

The same argument keeps plain-text formats alive across engineering generally; it is applied deliberately here.

The protocol layer

The Model Context Protocol is an open standard for connecting AI assistants to external systems. A server declares a set of tools with typed inputs, a client discovers those tools, and the model decides during a conversation when calling one is warranted.

The practical consequence is the part worth understanding. Before a standard existed, connecting a data source to an assistant meant building against that assistant's proprietary plugin interface, then doing it again for the next one. MCP inverts the ratio: implement the server once and every MCP-capable client can use it. Ethos is attached to Claude and to ChatGPT at the same time, and neither required work specific to it.

One detail matters for security posture. The assistant never receives a copy of the vault. It issues scoped calls and receives only what those calls return. The files stay where they are.

What the server exposes

Fourteen operations now, in four groups: reading the notes, writing them, creating artifacts, and maintaining a memory.

The groups carry different risk, and the design treats them differently. Read operations are non-destructive, so a wrongly chosen call costs only tokens. Write operations change durable state, which is why every write snapshots the previous version to history first and why the connector has no tool for deleting a note at all; the worst an assistant can do to existing content is bury it under a recoverable edit. Creation operations add new files without touching old ones. Memory operations are the one surface the assistants fully own, including deletion, and that asymmetry is deliberate: an AI should be able to revise its own understanding freely and should not be able to destroy the user's record of anything.

What a session actually looks like

The retrieval sequence is ordinary information retrieval with the model acting as query planner. It searches, judges which returned paths look relevant, reads the promising ones in full, and answers from that material. What differs from a general chat is the provenance of the grounding. The answer is constrained by text I wrote, rather than reconstructed from training data plus whatever I remembered to paste in.

The write-back step is the less obvious half. When a session produces a conclusion, the assistant records it as a new note or appends it to an existing one, and the next session's search finds it. The knowledge base then grows as a byproduct of doing work instead of as a separate discipline, which addresses the failure mode that kills most personal knowledge systems: people stop maintaining them.

A memory the user can watch

Notes are the user's record. The newer layer is a semantic memory that belongs to the assistants themselves. As Claude or ChatGPT work with the vault, they store atomic entries, one idea each: a fact, a relationship, a conclusion, tagged and referenced back to the notes the idea came from. Recall works by meaning rather than keywords, because entries live in a shared vector space where similarity is computed rather than matched, so a question about deployment risk surfaces an entry about rollback testing even when the two share no words. Assistants can also link entries explicitly, with labeled and weighted connections, when the relationship is something similarity would not discover.

What makes this different from vendor memory features is visibility. The vault renders the whole memory as a slowly rotating three-dimensional map: each entry a point, explicit links drawn as solid threads, computed similarity as faint ones, and every point clickable through to its full text, tags, and the source notes it cites. It updates live while an assistant is thinking.

The visibility changes how the memory can be used. Vendor memory occasionally announces that it has remembered something and offers no way to audit what; here the memory is a data structure the user can inspect, trace back to its source notes, and watch evolve. When an assistant recalls something wrong, the entry can be found, read, and corrected.

From answers to artifacts

The original tool surface could only produce text in notes. The current one can produce things. Ask for a project map and the assistant calls the canvas tools: it supplies cards and the connections between them, the server computes the layout, and the result is a real whiteboard file in the vault that the user can then rearrange by hand. The same conversation can generate a Word document or a PDF into the vault, or place an arbitrary file there.

Documents flow the other direction too. PDFs and Word files imported into the vault get in-app viewers, deep links that jump to a page or a phrase, and extracted text that lands in a companion note the assistants can search and read. The practical effect is that the boundary of "what the AI can work with" expands from Markdown to most of what a knowledge worker actually accumulates.

The same path handles full web pages. An assistant can author a complete HTML document, with its own styles, inline charts, and scripts, and save it through the same file tool. Ethos treats .html files in the vault as first-class notes: the app renders them in a sandboxed frame where the page's own CSS and JavaScript run isolated from the application around them, and the file can be linked from other notes, placed on canvases, and edited as source. A thread that starts as a few Markdown notes about an evaluation program can end as a formatted report with metric cards, charts, and a gate table, ready to forward to someone who will never open the vault.

What this changes, and what it does not

Grounding reduces a specific class of error. Models are strong at general reasoning and unreliable about particular facts they were never given. Supplying the particulars converts an unreliable question into a reliable one. This is the same mechanism enterprise retrieval systems depend on, operating at the scale of one person's working knowledge.

Context becomes portable across vendors. Because the knowledge lives in the vault rather than inside an assistant, changing assistants costs nothing in accumulated context. Given how quickly relative model capability shifts, keeping that switching cost near zero has practical value.

Data residency becomes a decision I make rather than one a vendor makes. For work under confidentiality obligations, the question of where text physically lives has a definite answer. One caveat deserves emphasis: content returned by a tool call still enters the assistant's context and is therefore subject to that provider's terms. The protocol governs what gets sent, not what happens to it afterward. Genuinely restricted material belongs in a vault that is not attached to a commercial client at all.

The limitations are worth stating plainly.

• Retrieval quality is bounded by note quality. Search cannot surface a distinction that was never written down, and a vault of vague notes yields vague grounding.
• You operate the infrastructure. Self-hosting puts backups, availability, and updates on you.
• Write access requires trust calibration. An assistant that can create and append can also create clutter or record a wrong conclusion confidently. Version snapshots make every AI edit reversible, but reviewing them is still a human habit.
• Context windows still bound the volume. Retrieval decides what to load; it does not make the window infinite, so selection quality continues to matter.

Why the pattern seems worth generalizing

Most attention in AI goes to models, which are improving quickly and converging in capability. Comparatively little goes to the context layer, which is where the difference sits between an assistant that is generically capable and one that is useful for a specific body of work.

An open protocol over an open format is a small architectural commitment with a long shelf life. The models attached to it will be superseded repeatedly, and nothing about the vault or the protocol has to change when that happens.