TL;DR

  • ICM is a way to organize your files so an AI can find its way around them. A few small files each say where to go next, so the agent reads only what its task needs.
  • Folders tell an agent where to look. Six questions cover the rest of the handoff: owner, context, effects, evidence, continuity, learning.
  • The free Second Brain Starter ships the two ICM skills I use for this: Jake Van Clief's original icm-architect, which I borrow, and my own second-brain-icm.

I write Code Meet AI, the newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

You hand an agent a task and plenty of context, and the handoff still goes wrong. Six short questions, answered before the task starts, close the gap I kept hitting: the agent had the files and still did not know who owned a fact, what it could change, or how to prove the work. They sit on top of a method called ICM, so that comes first.

Part 1: ICM lets your folders do the navigating

ICM stands for Interpretable Context Methodology. It is how you arrange files so an AI can find its way.

My second brain fits in four files: a top file routes each task to one folder, and each folder holds one short file that says what to read and what to do. The smallest version looks like this:

a tree command listing the four files of my-second-brain with a one-line note beside each.

Ask for an article and the agent starts at the top file, moves to the writing folder, reads one short file and begins. It never opens the code folder. Nobody pasted the whole project into the prompt.

The method comes from Jake Van Clief, who teaches it for free in his Clief Notes community on Skool and in his posts, which is where I follow it. He wrote it up with David McDermott in a March 2026 paper (arXiv:2603.16021). Their claim is that, for work that runs in steps, a folder structure can do the job of an agent framework (the extra code that coordinates several agents). You keep one agent, and the folders tell it what to read. In the paper's abstract: "You need one orchestrating agent that reads the right files at the right moment."

Part 2: six questions cover what folders leave out

Folders tell the agent where to go, and stop there. Nothing in them says what it may change, how to check the work, or what to leave for the next agent. Six short questions fill that gap. I made them up myself, and ICM does not include them. Each one becomes a single line you can paste into an AGENTS.md (the instruction file an agent reads first), a rule or a skill (a saved instruction the agent loads when it needs it).

1. Owner: who has the real copy?

Every fact should live in one place. When two files hold the same fact, the agent has to guess which one is right. Pick the file that owns each fact the task touches, and tell the agent to read it there.

Owner: every fact has one home. Name it before editing. If a copy exists, check it against the home. 

2. Context: what must it read first?

More files in the prompt mostly add noise. Give the agent one file to read first, and let it search wider only if the answer is not there.

Context: read FACTS.md first, the one file that holds names, links and handles. Search wider only if the answer is not there. 

3. Effects: what may it change?

An agent that can press Publish will press it. Write down what the task may change, and what needs your yes before it happens.

Effects: fill drafts only. Never press Publish or Send. Stop and show me a screenshot. 

4. Evidence: how do you know it worked?

One passing check can be luck. Write down the check that proves the work, and a case that should make it fail, so you know the check can fail at all.

Evidence: three readers score it and I use the average (each reader is a fresh model that did not write the draft). Show the check failing a bad sample first. 

5. Continuity: what does the next agent need?

A question that is answered but still marked open gets asked again by the next session. Close it in the same edit that answers it, with the date and the source.

Continuity: when a question is answered, mark it closed in the same edit, with the date and the source. 

6. Learning: what changes after a miss?

Telling the agent to try harder fixes nothing, and neither does apologising to it. After a miss, change the tool or the rule, then check it again on the next few tasks.

Learning: when a miss repeats, fix the tool or the rule. Re-check on the next three tasks. 

All six as one block

one task folder in the middle; the six questions light up around it one by one (owner, context, effects, evidence, continuity, learning), each drawing a line to

The lines above are mine, filled in. Here is the blank version. Paste it at the top of a task folder, or into the AGENTS.md that routes to it, and fill in one line per question.

Before any task, six lines: Owner: <the file that owns each fact this task touches> Context: <the one file to read first> Effects: <what it may change, and what needs my yes> Evidence: <the check that proves it worked, and a case that should fail> Continuity: <what to close, link or date when done> Learning: <what to change if it goes wrong> 

Six lines are cheaper than one bad handoff

Six lines take me about two minutes per task, which is the whole cost of what looks like paperwork for a solo builder. When a question does not apply, I write N/A and the reason, and move on. A one-line pointer edit needs no review, and the payoff is a task the next agent, or the next you, can pick up without reading the whole history.

The free Second Brain Starter ships icm-architect, Jake Van Clief's own skill for the method (MIT licence, bundled unmodified), and second-brain-icm, the skill that asks for these six lines whenever you change your own rules, skills or workflows. Builder AI OS is the paid layer for later, once one project is working.

Three earlier pieces set up this one

Write the six lines for one task

Pick one AI task you run every week, then:

  • Paste the blank block into its folder and fill it in.
  • Hand the task to your agent with that note as the brief.
  • Compare the result with last week's run, and write down what changed.

This one came from Code Meet AI, the newsletter where I write up the setups I actually run on my own projects.