On March 13th I was sitting at my desk at 8:30pm, talking through a problem with my AI assistant. Kleos — a voice-first PWA I’d been building for months — had a redundant AI layer. The local Ollama model doing categorisation was a weaker version of something my agent backend already handled. The voice capture and PWA shell were good. The brain was wrong.

We worked through the pivot: strip the local AI, wire Kleos into the NanoClaw backend as a web dashboard. Chat interface. KB browser. Voice conversation with the full knowledge base behind it. Clean decision. I wrote it up. Three artifacts in the KB.

Then I went to take a shower.

The shower is where it clicked

Standing under hot water, not thinking about code, the picture rearranged itself.

I’d been building three projects as separate things: NanoClaw (the agent backend), Kleos (a web app), and Nyx (a Rust terminal I hadn’t started yet). In that moment, I saw them as one system with three surfaces.

Lyra (NanoClaw — Claude + KB)
├── WhatsApp / Telegram  — mobile, async
├── Kleos (PWA)          — web, voice, rich UI
└── Nyx (terminal)       — dev workflow, local AI

Same brain. Same knowledge. Different interface for different contexts. WhatsApp for quick captures while walking the dog. Kleos for deep voice conversations with dashboards. Nyx for dev sessions where terminal context — current directory, active project, git branch — makes the AI responses sharper.

More importantly, I saw what Nyx should not be. The tempting idea — “let Lyra execute commands through Nyx” — was a trap. Claude Code already does that, built by a team with resources I don’t have. Nyx’s job isn’t execution. It’s ambient context: detect the project you’re in, surface relevant KB knowledge, let you log progress without leaving the terminal.

I got out, dried off, sat back down. Twenty minutes later I had a brainstorm document with the full ecosystem diagram, the integration direction (build this / don’t build this), and the open source narrative: NanoClaw as the platform, Kleos and Nyx as reference clients.

This is not about showers

The point is not “go take a shower.” The point is that pattern recognition — the kind that connects three separate projects into one coherent system — doesn’t fire when you’re staring at a diff. It fires when you step away. When you stop holding the problem actively and let the background process run.

Every experienced engineer knows this. The fix that comes to you while making coffee. The design that crystallises on the drive home. The naming that lands while you’re falling asleep.

What most of us don’t have is the infrastructure to capture it.

I came back from that shower and had a structured knowledge base waiting for me. A routing system that knew brainstorm notes go in 01_Projects/Nyx/Brainstorm/. An AI assistant that could take a raw idea and help me shape it into a decision document, a set of scoped artifacts, and a content plan update — all in twenty minutes, before the clarity faded.

The real investment

Building a personal knowledge system is not about productivity hacks. It’s about reducing the latency between insight and artifact. The gap between “I see it” and “it’s written down, structured, and findable.”

That evening session produced a project pivot, an ecosystem architecture, three new content pieces for this site, and the clearest product vision I’d had in weeks. Not because I had a breakthrough. Because I had the system to catch it.

The architecture happens in the shower. The discipline is what’s waiting when you get out.