LogMark: your vault as an operating system

Most people who work in software already have somewhere to put a thought. The trouble is that they have eleven somewheres. A decision lands in a Slack thread, its rationale in a commit message, the thing that prompted it in a note app, and the follow-up in a task tracker nobody opens. Each tool is fine. Collectively they guarantee that no single place knows what you are doing.

That was already annoying. It became expensive when AI agents arrived in the daily loop. An agent that cannot see your notes has to be told everything, every session, from scratch. So you paste context, it works for twenty minutes, the window closes, and the next session starts from nothing again.

The fix I wanted was unglamorous: one vault, in a format nothing can lock away, that agents can read and write as a first-class client rather than through an export. That is the whole premise.

Once the vault is a filesystem, the rest of the system starts to resemble something familiar. I did not set out to build an operating system for knowledge work. I noticed, roughly a year in, that I had been building one without admitting it, and therefore building it badly in places.

The realisation that changed how I build it sits in two rows of that table. An agent running inside Claude Code and a program running inside the vault are the same kind of thing: processes over one kernel, reading and writing one filesystem. One happens to execute elsewhere and one in-app. Once that is visible, the question of whether something should be a feature or an integration mostly dissolves, and the answer is usually that it should be a process with the right permissions.

I am showing the unfinished rows deliberately. The italicised statuses are the honest state of a system built by one person, and a partial scheduler is genuinely partial. The frame is useful precisely because it makes the gaps legible instead of letting a feature list hide them.

There is an axiom under all of this that I only wrote down long after it had started deciding things: knowledge work capability is bounded by capture fidelity and capture friction, and everything else is a transformation of already-captured material. If the thought decays before it reaches the disk, nothing downstream can recover it.

Which produces the constraint that shaped more of this codebase than any other: capture has a latency budget of 100ms, and intelligence is not allowed to spend it. If the tool ever makes you wait to write something down, you stop writing things down, and every clever feature downstream is worth nothing.

The resolution is a tiered architecture with one organising rule: the fast path never waits for the smart path. Four tiers, each adding capability at the cost of latency, each with a defined failure mode that falls through to the next rather than surfacing an error.

Tier 0 is the one that matters most and gets the least credit. Compiled regex and a date recogniser, no model and no dependencies, resolving notation and phrases like "next tuesday" in under a millisecond with perfect precision on the cases it covers. It ships with the core and it is why a base install is useful before you have configured anything at all.

Tier 1 is where it gets interesting, and it is entirely on-device. A 23MB embedding model, cosine similarity, and k-NN search over a local vector index. That buys typo tolerance, route inference from meaning rather than exact spelling, and connections to past entries you had forgotten writing. Semantic search with no server, no API key, and no data leaving the machine.

Tiers 2 and 3 are the language models, and both are optional by design. Tier 2 talks to an Ollama or LM Studio instance you already run. Tier 3 calls a cloud model, and you can point it at your own API key. Neither is ever in the capture path. They run on background threads and their results arrive when they arrive.

The engineering point is the fallback column. Every tier degrades into the one below it, so missing infrastructure costs you capability and nothing else. No embedding model, no Ollama, no network, and the product still works, just less cleverly. That is what separates a local-first tool from a cloud tool with an offline mode.

Version 0.21, in daily personal use, and only now opening to anyone else. A real codebase with almost no users, and that order of operations was deliberate. Daily use is my test for whether something is finished, and I would rather ship software I find genuinely useful and pleasant to live with than move fast and break things in front of other people. The cost of that shows up in the user count, and I would take the same trade again.

Solid: the desktop app, the MCP server, the CLI, and the web platform. I rely on all four every day, which is a stronger claim than a feature list.

Not solid, stated plainly. The Telegram bots work but are in beta. The mobile app is built and unpublished, so unless you are me you cannot install it, and it is not yet wired back to the desktop. Treat both as roadmap rather than product, and discount them accordingly when judging anything above.

Further out is the part I find most interesting and have least to show for. The vault captures well and refines only in prototype. Two arms would close the loop: pulling in outside material aimed at the gaps your own notes expose, and distilling all of it into a living, interlinked concept layer that matures upward from raw entry to published page. Both exist as working prototypes rather than shipped features. That is the next real body of work, and it is the reason the operating system framing matters more to me than any single client does.

The desktop app is free and works offline with no account. If you keep notes on Windows and you have started wishing your agents could read them, it is worth twenty minutes of your time.