I Compared My Second Brain to the Best Free ICM Implementation I've Found. Here's What I Stole — and What I Didn't.

Last week I did something uncomfortable: I put my own system on the table next to someone else's and audited both, honestly, looking for the places where mine loses.

The other system is Mark Garza's workspace-architect — a free, MIT-licensed implementation of the Interpretable Context Methodology (ICM), the folders-and-markdown approach to AI agents laid out by Jake Van Clief and David McDermott. Mark's repo, from Laimen AI, comes with a Glass Box demo that shows the whole thing working in the open: staged folders, a visible human approval gate, an agent reading exactly the files it needs and nothing else.

I ran a full comparison — a multi-agent research pass over his repo, the ICM source material, and my own vault docs. The internal report ran long. This is the short, public version, including the fork in the road I hit at the end and which way I went.

Spoiler: I didn't rebuild anything. But I did steal six things.

Same religion, different churches

Here's the thing that surprised me least but matters most: Mark's system and mine agree on almost everything foundational.

Both of us rejected the same alternatives for the same reasons. No vector databases until plain markdown retrieval actually fails, with the failure documented. No orchestration frameworks — no CrewAI, no LangChain — when a folder structure and a context file solve the problem. Mark's pitch is literally "no new code, no new dependencies," just numbered folders, plain markdown, and one agent reading the right file at the right moment. My vault's rule 13 says prefer clear folder structure and markdown over complex tooling. We wrote those independently.

Both systems put a human at every consequential boundary. Mark builds a review gate at every pipeline stage, and mismatches get logged, not silently fixed. My system requires approval metadata before anything moves to a client-facing folder. Same doctrine.

Both follow "edit the source, not the output." Fixing this run is a patch; fixing the context file that produced it fixes every future run.

And both of us refuse to build complexity on speculation. Mark's failure-mode entries are earned — added when a failure is actually observed, not guessed at upfront. My version: automate only after the workflow has earned it.

That's the ICM DNA, and it's why I trust his repo. He didn't just read the paper — he implemented its temperament.

Where we actually differ

So if we agree on the philosophy, why do the two systems look nothing alike? Because they're doing different jobs.

Mark built a workspace compiler. I built a knowledge government.

His system is phase-based. A workspace maps to a phase of work — brief, spec, build, output — never to a category of files. He's explicit about that rule. Each workspace gets a small context file, a Load table, a Skip table, and hard numbers: the root map stays under 200 lines, room files stay between 25 and 80 lines, two to three wired tools per workspace, and an audit script that fails the build if any of it is violated. The whole repo is around 1,100 lines. You can learn it in one sitting and stand up a working version in about fifteen minutes.

Mine is category-based. My vault's top-level lanes answer a different question — not "what phase am I in?" but "what kind of thing is this, and how sensitive is it?" Raw intake, needs-review, source library, client-ready, restricted. Thirteen agent charters defined in plain text. A router agent. Position-addressed memory, where the file path itself carries the client, the project, the stage, and the rules. Eighteen sprints of accumulated knowledge, 35+ sources distilled into frameworks, every unverified claim flagged as unverified.

Read Mark's rules strictly, my top-level structure is an anti-pattern — he says workspaces should never be categories of files. Read them fairly, and we're solving different problems. His workspaces are execution environments: do a job, produce an output, hand it off, throw away the working files. My vault is a repository: accumulate, keep provenance, retrieve years later. He keeps the factory and treats the products as disposable. I keep everything, with a paper trail.

One more difference, and it's the big one for my clients: Mark's repo has no privacy model. No sensitivity lanes, no approval metadata, no source-truth hierarchy. That's not a flaw — it's out of scope for a workspace compiler aimed at builders. He has honesty rules ("gaps are flagged, never faked"), which I respect. But there's nothing in the repo that answers "what happens when this folder contains a client's payroll notes?" Because that was never the job.

His enforcement is mechanical — line caps, a linter, a compliance spec where an unresolved MUST means the build isn't done, no exceptions. My enforcement is procedural — gates, lanes, decision logs, a human who signs off. Numbers versus judgment. Both work. They work on different problems.

The fork: rebuild or integrate

At the end of the audit I had a real decision to make, and I want to show the whole fork because the wrong branch is seductive.

Option A: rebuild my system ICM-native. Tear down the category lanes, restructure everything as phase-based workspaces, inject my governance rules as reference docs, extend Mark's audit script to check my safety rules too. It would be elegant. It would be more compliant with the methodology. And I'll admit the architecture sketch looked great.

Option B: keep my vault as-is and pull specific mechanics across.

I chose B, and here's the reasoning, because the reasoning is the useful part.

First: my own doctrine forbids A. I have a standing rule — no restructuring without a documented failure that proves the current structure is broken. There is no such failure on record. Eighteen sprints of position-addressed knowledge work fine. Rebuilding would trade real migration risk for structural elegance, which is a bad trade every time.

Second: Mark's own failure-mode list warns against exactly this. One of his named traps is "building everything before using anything." The methodology I'd be rebuilding toward tells me not to do the rebuild.

Third: a rebuild solves no paid problem. Nobody is paying me for a prettier folder tree. The ICM source material is blunt about this — start with problems people already pay to solve.

So instead, six mechanics came across from Mark's repo into mine:

1. Skip columns. My routing tables said what to load; they never said what to ignore. Mark makes the Skip column mandatory, and the ICM material calls the load/skip table the most important pattern in the whole system. This was hours of work for the biggest single upgrade.
2. Size caps. Hard line limits on context files, and an 80/20 rule — at least 80% domain content, at most 20% behavioral instruction. My main agent config was drifting toward the "one giant context file" failure mode. Now it gets measured.
3. A context linter. Mark's audit script checks shape: line caps, Skip columns, trigger conditions, placeholder stubs. He's honest that a passing audit means the shape is right, not that the content is good. I'm building the sibling script for my template kit.
4. Stage contracts. Inputs, process-as-acceptance-criteria, outputs, and a Verify block that logs mismatches instead of silently fixing them. My Grow Wild field-walkthrough pipeline — photos to qualified scope to client deck — is the first candidate, because a deck where the numbers silently drift from the field findings is exactly the failure this prevents.
5. The first-run test ritual. Fresh conversation, one real task, watch four things: right workspace found, right files loaded and skipped, tools fired at the right moment, output landed in the right place. Trivial effort. I'd skipped an equivalent dry run before a client session earlier this year and felt the drift. Never again.
6. Countable packaging. Five principles, five layers, three topologies. Mark's system is teachable in one sitting because everything is countable and every concept has a metaphor — map, router, room, factory. My terminology is internally consistent but unsold. That's a me problem, and his repo is the template for fixing it.

One thing I did not take: the speed ethos, applied raw to client work. "Working system in fifteen minutes" is a genuine feature for a solo builder. Pointed at a client's confidential files, it collides head-on with my rule that no client content gets processed until privacy lanes are assigned. Speed is his feature. For my buyers, safety is the feature. Order of operations: governed context first, then agents.

The punchline: complement, loudly

Here's where I landed on positioning, and I want to say it without a hint of straw-man, because Mark's repo deserves better than that.

Workspace-architect is the best free on-ramp to ICM I've found. If you're a builder inside Claude Code and you want to feel this methodology work today, clone it. It's MIT-licensed, it's disciplined, it dogfoods its own rules, and the Glass Box demo makes the whole approach legible in a way a README never could. I'm not competing with it. I'm pointing at it.

But his repo ends where a real company's confidential data begins. That's not a criticism — it's a scope line, and knowing where it sits is the whole point of this comparison. The generic scaffold is now free and excellent, which means the scaffold is commoditized. What isn't commoditized is everything a business owner needs around the scaffold: privacy lanes assigned before any file gets processed, approval gates before anything goes client-facing, provenance on every claim, decision logs the client keeps, and a human who is accountable for the judgment calls a linter can't make.

That's the layer I sell. Mark's work makes it easier to sell, because now I can hand someone his repo, let them see the methodology is real, and then say: here's what still stands between this and your client data.

If you take one thing

When you find a great system that overlaps with yours, the instinct is to pick a winner and rebuild toward it. Resist that. Audit the overlap, name the different jobs honestly, and steal mechanics — not architecture. My vault kept its shape. It gained Skip columns, size caps, a linter, stage contracts, a first-run ritual, and better packaging. Six upgrades, zero migration risk, and the standing rule that protects all of it: don't restructure anything until a documented failure says to.

---

← Back to the Learning Log