I got tired of my Obsidian vault rotting, so I built an AI to maintain it. (Open-sourcing my LLM-Wiki)

The strongest part is that the agent works inside plain Markdown instead of becoming another knowledge silo. For founder workflows, I would make the first promised outcome very specific: keep the decision log, source notes, and current index in sync for one project.

That is the wedge I would trust before a broader "personal OS" promise. If it reliably prevents one vault from rotting for 30 days, the expansion path is obvious.

I've gone through the exact same decay cycle with my own vaults. Start organized, lose it within two weeks. The lint workflow is the smartest part of this, because almost nobody builds for upkeep, everyone builds for capture and then walks away. One thing I keep running into though, is that the capture step itself is still surprisingly high friction. Opening the vault, finding the right note, typing out a half-formed thought, that's enough friction that a lot of ideas just evaporate. I built DictaFlow (dictaflow.io) to solve that part. Hold a hotkey, speak, and it types wherever your cursor is. The LLM wiki handles the organization from there. Voice capture plus AI maintenance feels like the full loop for a knowledge system that actually survives past week two.

The plain Markdown choice is the part I’d trust most here. If the agent can improve the vault without forcing a migration, the adoption friction drops a lot.

I’d be curious what the first “must not break” rule is: preserve original intent, avoid bad merges, or make every change easy to review?

The part I would stress-test is the "health check" loop, because that's where this can become more than better capture. A useful guardrail might be to make every maintenance run output a tiny changelog with three buckets: safe cleanup, suggested merges, and decisions needing human review. That keeps the agent doing the boring upkeep while preserving intent on the knowledge-shaping calls.

For founders, I'd also consider a weekly "what changed in my operating picture?" digest as the sharpest habit hook. If it can surface stale assumptions, open decisions, and contradicted notes before planning starts, it becomes an ops system instead of another note workflow.

This hits close to home. I have the exact same pattern with my own knowledge files. Start organized, two weeks later everything is a mess of orphaned notes and broken cross-references. The maintenance overhead is the real killer, not the initial capture.

What I find interesting about your approach is the "lint the vault" workflow. That's the part most knowledge tools ignore. They focus on input (capture, clip, save) but leave the upkeep entirely to you. Having an agent that can run health checks and surface decay before it compounds is genuinely useful.

One question: how do you handle cases where the agent's synthesis disagrees with your original intent? Like when it merges two concept notes that you actually wanted to keep separate. Curious if you have a guardrail for that or if you just catch it during review.

Also smart to keep the engine open and monetize the domain-specific packs. Founder OS sounds like the right wedge because founders have the most acute version of this problem (decisions scattered across docs, chats, emails, notes) and the highest willingness to pay for a fix.

This is a strong pattern because the pain is not “note-taking.” It is knowledge decay. Most people can capture information, but very few systems keep the structure alive after the first week.

The Founder OS direction is more interesting than the open-source vault itself, because that turns the engine from a useful personal workflow into a decision and operating layer for founders. If you push that angle, I’d make the positioning less about “LLM-Wiki” and more about a self-maintaining workspace that keeps decisions, research, notes, and operating context from drifting apart.

The naming is worth pressure-testing early though. LLM-Wiki is clear for the open-source engine, but it may box the bigger product into a technical/wiki frame when the real business layer sounds broader: founder workflow, decision memory, operating context, and AI-maintained knowledge infrastructure.

Xevoa .com would fit that direction well because it feels more like an AI workspace or operating layer than a wiki/tool name. If Founder OS becomes a hosted product with skill packs, workflows, and paid verticals, the brand shell probably needs to carry more than the current LLM-Wiki frame.

I’d separate the open engine name from the commercial product name before too many docs, examples, and early users lock onto the wrong category.