My Architect, part 7: Obsidian, Claude Code docs and OpenClaw — field notes

The series about My Architect would be dishonest without this part. I didn't invent the project-memory problem in a vacuum — I spent years solving it with other people's tools. I write agentic systems myself, so I tried everything not out of curiosity: I measured every tool against a single question — what does it do for my productivity on real projects. Here are the field notes. And a disclaimer for honesty's sake: My Architect is my own project, so apply the discount yourself.

Obsidian: a culture, not a tool

Technically, Obsidian is a folder of markdown files with a link graph and plugins on top. For an engineer who already has git, an IDE and grep, it's exactly the same knowledge in exactly the same pile of files, just with a pretty graph and a whiff of "second brain" grandeur around it.

I don't look down on people who live in it, and here's why: the real job Obsidian does is not technical but cultural. It brings non-technical people into the markdown-centric world: people who will never open a terminal start writing plain text with links, owning their data locally and thinking in structure. That's good work. It's just not the job of "running a project".

The ceiling is obvious: the knowledge in the vault sits there, but it doesn't work. A note has no executor. Had I planned a project in Obsidian, it would have been a plan nobody executes — and from part 6 you already know what I think of such diagrams: a wish, not a plan.

Claude Code docs: elegant, but with a manual gearbox

The "CLAUDE.md + docs/*.md in the repository" approach is one I've used since day one of Claude Code, and it has a quality I value to this day: the knowledge lives next to the code, is versioned by the same git, and is readable by both human and agent with no intermediaries. For a single repository it's an honest, engineer-native way.

The price has been known since day one too. Every new session starts with a ritual: load this, read that, don't forget this one file. Context is assembled by hand, and that's overhead repeated daily. Meanwhile the files drift: PLAN.md argues with ROADMAP.md, CLAUDE.md bloats into a dumping ground — I went through this in part 1. The knowledge is there, the structure above it isn't, and distributing the agent's attention across twenty markdown files is on you.

An important caveat: the approach itself is beautiful, and I didn't throw it away. My Architect adds to it elegantly: docs remained markdown files, but they hang on nodes of the model. An agent picking up a task gets its docs precisely via get_node and get_doc — nothing needs to be "loaded before the session", because loading became addressable.

OpenClaw: the best storage — and a lesson about borrowed privileges

OpenClaw is Peter Steinberger's open-source agentic framework, launched in November 2025 as Clawdbot and quick to gather a huge community. I kept my working projects in it as workspace folders — in the spirit of Projects in Claude.ai — and as a storage of work it was genuinely good: it indexes, analyzes and answers questions about project contents so well that I almost never had to search by hand.

The weak spot I kept catching was at the seam: between "read from the workspace" and "recalled from memory" there was drift. Agent memory — files the agent itself decides when to read and update — lived a life of its own, and an answer could lean on a stale snapshot instead of the folder's fresh contents. Tolerable for an assistant, bad for a project's source of truth.

But I left for a different reason, and it's more instructive than the technical one. The entire economics of my setup rested on OpenClaw reaching Claude within an already-paid subscription — via claude setup-token. On April 4, 2026 Anthropic closed Pro/Max subscriptions to third-party agentic tools: want to continue — pay separately at API rates. For heavy users that meant costs growing severalfold, for some — by an order of magnitude. The setup my daily process stood on died in a single day not because it got worse, but because someone else's policy changed.

The lesson, as I phrased it: you can't build a process on a perk someone else controls. A privilege is granted and revoked without your participation.

My Architect is built from that lesson almost literally: the open MCP protocol instead of a private integration, your own files instead of someone else's index, and the agent — any MCP-compatible one, today Claude Code, tomorrow whatever you like.

What all three have in common

Now the main observation this article exists for. Obsidian, the docs approach and OpenClaw are tools for storing knowledge: as a pile, a repository or an index. All three answer the question "where does what I know live".

But "running a project with an agent" is a different job. It needs not a warehouse but a model: a hierarchy with levels, requirements with inheritance, statuses, releases — and an executor that works against that model. Knowledge versus plan: knowledge can be stored any way you like, a plan must have structure and someone to execute it. None of the three tools does that job — not because they're bad, but because they were hired for a different one.

If I compress my notes down to three lines, it comes out like this:

• Need to bring yourself or a team into local markdown knowledge without a terminal — Obsidian does it best.
• Need knowledge next to the code of a single repository — the Claude Code docs approach is honest and simple; live with the loading ritual.
• Need an all-knowing assistant over the contents of your working folders — the OpenClaw class of tools is good, but do the math at API rates and remember the memory drift.

And if you need a project an agent runs for weeks without losing it — you need a model, not storage. How it's built is this whole series; to try it — my-architect.app. If you use any of these three differently — write to me, I'm genuinely curious what job they do for you.