Separate State, Knowledge, and Interface

Most knowledge tools collapse three different jobs into one app: tracking what you're working on, remembering what you've learned, and giving you a way to interact with both. The collapse feels efficient and is the source of almost every long-term failure mode.

The principle

A KMS has at least three distinct layers, each with a different shape and lifecycle:

• State — what is currently active. Priorities, open questions, in-flight work. Mutable, lightweight, frequently overwritten.
• Knowledge — what is durable. Concepts, entities, decisions, insights, sources. Append-mostly, linked, slow-changing.
• Interface — how you interact. Conversation, dashboard, search, agent. Adaptive to the moment.

At team scale a fourth layer appears: a warehouse for the structured tail — events, tickets, customer records — that knowledge synthesis pulls from but does not own.

Why it matters

State and knowledge have opposite update patterns. State wants to be wiped and rewritten. Knowledge wants to accrete and connect. Stuffing them into one tool means knowledge gets cluttered with stale state ("active project: …" from six months ago) and state gets buried under knowledge it can't find a way past.

Interface wants its own freedom too. The right way to add a meeting note is a 30-second conversation. The right way to read it back is a search-on-demand. The right way to surface it in context is an agent pulling it into the current task. None of those are the same UI.

How it works

Each layer gets its own home:

• State lives in a small set of mutable markdown files (tracker.md, priorities.md) that the agent rewrites freely.
• Knowledge lives in folders structured by entity type, with stable slugs and wikilinks.
• Interface is whatever surface the user is on right now — Claude in terminal, an Obsidian vault open on iPad, a Slack message to a bot.

The same agent reads from all three but writes to each through different rules. State gets overwritten. Knowledge gets appended. Interface produces no artefact at all.

In Claude primitives

• CLAUDE.md declares the three layers as named directories and the rules for each — "files under state/ may be wiped; files under knowledge/ are append-mostly; never write to interface/."
• Skills are split by layer — update-tracker (state), save-concept (knowledge), surface-relevant (interface).
• Memory (Claude's session memory) is interface-layer scratch; durable knowledge gets explicitly written to disk.

Where I've seen it

In a personal KMS I use daily, the split is state/ vs vault/ vs the conversation surface. In a team KMS for client work, state lives in an app DB, knowledge in markdown, interface in chat — and the warehouse layer (events, customer records) feeds knowledge synthesis without being owned by it. In an app-scoped second-brain KMS, the failure mode of not separating state and knowledge is the bug we keep relitigating.

The contrarian read

It looks like over-engineering for one person. It is not. The cost of building three layers from day one is low; the cost of disentangling them after two years of mixing is the cost of starting over.