The missing folder. I spent an afternoon designing an AI that holds the judgment, not just the work.

Most people use AI to execute what they already know. I spent 5 October designing the opposite: a folder whose job is to hold the judgment, learn from what comes back, and tell the folders that do the work what to change. It does not exist yet. What exists is its design, researched against what the field has tried, and the first file it will hold: a standard of 24 rules for what a post under my name has to be. Both are in a folder waiting for a placement decision. This post is the record of how they got there, including the five times I had to correct the session that was helping me.

I'm writing this for two kinds of reader. If you build with AI, you'll find the real prompts, the briefs I gave to helper agents, the mistakes, and templates to copy. If you run a business and hand this kind of work to others, the part for you is near the end, under "What this means if you run a business." You can skip the timeline.

Eight words I use throughout, in plain terms. A folder is a real folder on my Mac that holds one job, with a plain text file saying what the job is. I work in Claude Code, an AI assistant that reads and changes files on my Mac; one conversation with it is a session, and it starts with no memory of the last one. A sub-agent is a second AI the session starts and hands a written brief to, so it can research or check something with none of the session's context. A cold read is sending a file to a sub-agent that has never seen it, playing the person who will have to act on it, and counting every word it cannot act on; each one is a stall. A commit is git saving a change with a time on it; it is how I know what actually happened. The standard is the file this afternoon produced: numbered rules for what a post under my name has to be. A domain is the new kind of folder this post is about: one that sits above several work folders, covers one area of the business the way an executive would hand it off (content, sales, finance), and makes nothing itself. And the builder is the one folder whose only job is deciding how my folders are built; the first thing it does with any proposal is decide whether it needs a new folder at all and where that folder goes, which I call the placement decision.

The short version

• The problem: my work lives in 21 folders, one per job. Seven of them are needed to make one LinkedIn post. Not one of them owned what a good post was. The posts going out were correct and flat.
• What I did: opened a session in the top-level folder that holds all 21, on purpose, so no single folder's instructions would load and steer the thinking. Four hours and 37 minutes, 23 prompts typed by me, 8 sub-agents sent out with written briefs, one commit.
• What came out: a research file (230 lines, with three full research reports appended) proposing a new kind of folder, which I'm calling a domain: one that sits above several work folders, makes nothing itself, holds the rules for what good means, learns from what comes back, and tells the work folders what to change. And the first file it would hold: the standard, 24 rules, each with its source and two counts, helped and hurt, so it can be tested against what the posts actually do.
• What did not happen: no folder was created. The record shows one commit in the whole window, two files, delivered to the folder whose only job is deciding how my folders are built. I call that one the builder. The claim is "designed," not "built."
• The lesson: the AI was not wrong because it lacked information. It was wrong because I had assumed it should execute my judgment instead of forming its own from my files. The afternoon turned on the moment I refused to write a sentence and made the system write it from the evidence.

Before

On the morning of 5 October my content system worked. A folder called content-direction wrote three posts a day from the week's chapter of the Know Who workbook, a free seven-chapter workbook that teaches executives to know exactly who their business serves, which I publish a chapter at a time. It loaded them into a database, and an automation scheduled the ones I approved. Every other folder it needed, it read by file path: the voice rules in one, the brand line in another, and in a third my consulting practice, which works out, for each step of a business, whether a person should keep it or a machine should take it. On paper it was complete.

What I wrote at 2:42 p.m. was this:

This is a thinking session. Help me organize the workspaces and their content so I can see every workspace that will help me accomplish the goal of producing appropriate content to distribute on all the channels [...] I have too many workspaces that help accomplish this task, and I don't know where to go to work through the question I have, which is: Who do I talk to? Which workspace do I work in to get alignment on what I consider a value packed post.

I had three saved posts from people whose content I admire and no idea which folder to hand them to. That is the whole problem in one line: a system that can make the thing cannot be told what the thing is for.

The setup in one picture

The left side is what exists. Each folder follows a method called Interpretable Context Methodology, ICM, from a 2026 paper credited at the end. In it a folder that does work is called a workspace. It has a file saying what it is, a table saying which file handles which kind of request, numbered folders for each step of its work, and reference files (voice rules, conventions) it reads every time it runs. The right side is what the afternoon designed: one folder above the seven, which makes nothing, holds the standard, reads results and outside advice, and tells the folders under it what to change by leaving them a written brief, which I call a handoff.

How one folder works

The folder on the right does not exist, so "how it works" here means the file that says how it would. Earlier the same day, in a different session, I had agreed that every folder should carry the same eight description files: what it is, which file handles what, its goal, who answers for it, its method, where it stands, what runs on its own, and a log. A domain keeps those eight and adds the five below. This is the proposal table from the research file, condensed to what each one holds. The file refers to me in the third person because sessions read it, not me.

STANDARD.md      What good means in this domain, as numbered rules. Each rule
                 has an id, one line on why, the date it was set, and two
                 counts, helped and hurt. Changed one rule at a time, only on
                 Nick's yes. A retired rule shrinks to one line in a
                 Superseded section, never deleted.

REFLECTIONS.md   Lessons, one entry at a time, never edited after. Each entry
                 names its evidence and proposes one change to one rule.
                 Written weekly by a session that did not make the pieces.

handoffs/        One file per change the domain asks a workspace to make, as
                 a brief a session there can read cold. The workspace edits
                 its own files; the domain never does.

plans/           One strategy or plan, dated. Opens with the goal it serves.
                 Ends with a Dependencies table: the folder, what it must
                 provide, and whether it is in place, missing, or requested.

inbox/           Outside advice lands here. Each item leaves with one of
                 three outcomes: adopted as rule N, rejected because, pending.

Two rules make the files work, and both came out of the research rather than my head. The folders that make things never write inside the domain. And the standard has a size budget, 200 lines of live rules, because one of the papers (Agentic Context Engineering, credited at the end) measured what happens when a model is asked to rewrite a whole document each round: it shrinks it into something shorter and less useful every time.

The two counts on each rule work like this. Eleven days after a post goes out, its reach is compared with the median reach of my posts on that platform over the previous 90 days. The post's file lists which rules it was written to follow. Each of those rules gets one added to helped if the post beat the median, otherwise one to hurt. "Ruled" on a rule means I said yes to it. "Proposed" means the session put it forward from the evidence, and it applies as written until I rule.

Here is what the standard's first section looks like now. Rule A1 is a line I typed; the "why" under it is the session's synthesis of four creators' advice. "The executive described above" refers to the reader profile at the top of the file.

A1. The post's job is not to impress the internet. It is to leave useful
evidence in public that the right people can find. Why: a feed rewards
applause from anyone; a business needs recognition from a few. Evidence
means something a reader can use and check. Useful means the reader leaves
able to do something. Right people means the executive described above,
not peers, not other creators. A post that got reach from the wrong people
is a cost, not a win. Ruled. Helped 0 / Hurt 0.

A2. Always use proven hooks. A hook is proven when it has already stopped
this reader, not when it sounds clever. The first line is never improvised.

How folders hand work to each other

Nothing in this system edits another folder. A session reads other folders by path and, when something in them should change, writes a brief and leaves it in that folder's inbox, a subfolder where items from elsewhere wait to be sorted. The afternoon ended the same way: two files delivered to the builder's inbox, beside a brief that had arrived there at 1:45 p.m. from another session proposing the eight files. The builder's first job on anything is to decide whether it needs a new folder at all and where it goes; I call that the placement decision, and one will cover all three items.

The handoff worth showing is the one that changed the afternoon. At 7:05 p.m. I refused to write the standard's problem statement myself. One minute later the session sent a sub-agent into my own files with this brief. Trimmed to the part that matters:

You are drafting one sentence for Nick Lipetzky's content standard.
Read-only task: do not write or edit any file.

THE SENTENCE TO DRAFT: the one problem Nick is known for solving, stated in
the words the reader (a senior, non-technical executive or established
founder responsible for revenue or operations) would use about themselves.

READ THESE, by path, and nothing outside them:
1. [my practice's charter: what the method is and who it is for]
2. [my practice's synthesis: the claims it makes, with evidence]
3. [three or four client case files; look for what the client said their
   problem was, in their words]
4. [the brand line, and the file saying which of my sites says what]
5. [the current definition of what I sell]
6. [the voice file, which holds my dated words about the reader]
7. [a profile of my feed audience, read with Eugene Schwartz's method]
8. [the list of problems my posts are about]

THE LENS: Eugene Schwartz, Breakthrough Advertising. Ask of the material:
how aware is the reader already of their problem, and how many similar
claims have they heard before (Schwartz calls these awareness and
sophistication)? The
problem statement must meet them at their actual awareness stage, in the
words they already use, and must be a problem Nick's cases show him
solving, not one he would like to solve.

OUTPUT: a table of evidence, each row a quote or fact with its file path
and who said it, at least 12 rows. The reader's awareness stage with the
quotes that establish it. Three candidate statements, each with the rows it
rests on and one line on what Schwartz would say is wrong with it. Your
recommendation of one. Where the placeholder sentence was wrong.

It came back in 3 minutes 45 seconds with 23 evidence rows, three candidates, and one recommendation. The sentence it recommended is now rule D1 of the standard:

We bought the automation and it works, but the business runs the way it did before: the strange cases land on one person, my team either can't use it or won't, and the vendor wants to bill me to train them. I paid for a tool, and nobody can tell me what my people are supposed to be doing now.

It also showed, from my own files, why the placeholder the session had written an hour earlier was wrong on two counts. The placeholder put my own term for my practice into the reader's mouth, and an audience profile I had approved in August says the reader does not have that vocabulary. And it said the reader could not see their own bottleneck, when my notes from two paid engagements show they usually can.

The afternoon, as it happened

2:42 p.m. The question. The prompt above. The session read seven folders' routing and voice files in under a minute and answered: yes, content-direction is the folder, and here is a table of what feeds it. Three minutes later I wrote:

Your output helps display the issue I have, which is that there seems to be an assumption that the entire content workflow is good as is. It's also assuming it's complete, and it is not. Let me know if you understand what I'm trying to express here by repeating back in your own words.

What came back named its own mistake in four lines: it had audited routing, not fitness; treated each folder's self-description as truth; shrunk my problem to a slot to fill; and assumed completeness because a map had been drawn. What it taught me: an AI that reads a well-organised system will defend it. The first job in a thinking session is to say the system is on trial.

2:50 p.m. Is it me or the method? I asked it to check my notebook of the ICM course and paper for whether I was misusing the method by having folders produce things other folders depend on.

Yes, and I think this is either my misunderstanding of the ICM framework, or it's a problem with the ICM framework that we're using (because I'm using workspaces to create elements that are used across the other workspaces). I think I do this in a way that is far beyond what the original intent of ICM is. Research the [course] NotebookLM to see if my theory is correct. Feel free to add your own ideas and theories or feedback.

Three notebook queries later: half right. The method explicitly allows folders to read each other's reference files by path. What it warns against is the number of folders. Its own content-creator example has three. I had 21, and content-direction pointed at seven others to write one post. The method's rule for splitting is whether the work needs a different kind of thinking, and I had split along the map of my business's eight functions instead.

3:01 p.m. Not a monorepo. The session leaned toward consolidating. I pushed back:

If I consolidate them, it feels like I'm creating a large mono repo within Content-direction. And then, when I need to iterate on offers or if I want to build an automation or intelligent system for generating offers or something related to that, I won't have a workspace for that. [...] Help me articulate this. What do you think I'm trying to get to here?

Its answer reframed the whole thing: the folders are not steps in a process, they are areas of knowledge, and what I lacked was not fewer of them but a way to bring several together for one job. I then pointed it at a folder where another session had, earlier that day, defined the layers of a clickable map of my business: a domain is an area an executive hands off, and a workspace is one team or set of tools doing one body of work inside it. The word I needed already existed. At 3:13 the session said so.

3:27 p.m. The experts. I gave it three saved posts from a tracking base: one on picking a side, one on giving a framework away free, one on changing how the reader sees their problem before selling anything. It read them back first, without proposing a standard, and asked which of the five things they shared was most missing from my posts. I answered: the stance and the reframe.

3:48 p.m. A guide on the LinkedIn ranking system. I pasted a seven-part summary of a public guide and asked what would happen when context like that enters the system. The answer sorted its seven parts by what each would change: the LinkedIn platform file (a slot that existed but was empty), the step that studies other creators' best-performing posts and my LinkedIn profile (both existed and were right), the plan for moving readers to email (already in the design), and the editorial standard, which had nowhere to land. Same gap, seen from the intake side.

4:08 p.m. The folder as expert.

Do you see why I feel the need for a domain folder? In my mind it acts as the digital subject matter expert or whatever the agentic version should be. To expand… i think a human expert is someone who is always leaning from external perspectives and their own experience. Then they know what and how to adjust and iterate thinking and execution.

The reply drew the line I had been circling: a stage runs once per piece and forgets; what I was describing persists and learns. Four jobs: take in outside perspective, hold its own results, keep and adjust the standard, direct the folders under it. Then a gap of 1 hour 34 minutes with nothing in the record. I don't know what I did. The transcript doesn't either.

5:43 p.m. Research. I agreed that changes to a folder arrive as handoffs, never edits, and asked for research on what the Claude Code and AI community had built for this. Three sub-agents launched 31 seconds apart with written briefs: one on Claude Code's own memory and the community's reflect-and-approve tools, one on the agent-memory papers, one on how content operators keep a standard. They came back in 5, 5 and 8 minutes with 79,000 characters between them. Two minutes after the last one landed the synthesis was on disk. The findings that mattered:

• Every learning loop found learns the human, not the domain. Memory records corrections; nothing in the field was built to get better at judging.
• Of 30 published content setups the research found (all listed in the research file), none has a written step that turns results into a change to the standard. Results get logged and not used.
• The method I follow says its reference files are "configured once, stable across every run," and names a learning loop as future work. The folder I wanted fills a gap the method admits.

5:54 p.m. Cold reads. The synthesis went to a reader with none of the session's context, playing the future session that will have to act on it. Thirty stalls. Rewrite. Twenty-four. Rewrite. Four. Most were my own vocabulary used as if the reader had been in the room: the map's words for a box and the boxes around it, the word handoff, the word batch for a week's posts. Two were contradictions in my own proposal.

6:36 p.m. The standard. "Yes, let's write the standard now." One minute and 42 seconds later it existed, 24 rules in six sections, each with its source. A cold read found 31 stalls and five rule conflicts, including a short post for new readers being asked, by another rule, to also carry the whole framework. Fixed.

6:58 p.m. The correction that mattered.

When I read the content standard first draft, what the post is for A1 lands flat. You're just using my own words and regurgitating it into a document that defeats the purpose of using intelligent AI systems. That's why I want you to use the input I give you from these experts via their social media posts. Here's an example. This is what a post is for.

The posts job is not to impress the internet. It is to leave useful evidence in public that the right people can find.

Always Use proven hooks

The session's reply: it had applied "never invent" to judgment, where it does not belong. The rule is for facts, stories and numbers. A standard is supposed to be distilled judgment, sharper than any one of its inputs. Section A was rewritten 34 seconds later. After I pasted one more creator's transcript, sections B to F followed. They carried three rules I had not asked for and would not have written: say the same thing until they cannot escape it; your own face, mistake and result are the strongest evidence you have; be known for one problem.

7:05 p.m. The refusal. The rewrite had put a placeholder problem statement in rule D1 and asked for my wording.

I'm not writing the problem statement. This is another good lesson. The reason I'm not writing the problem statement is because we should have all the context available so that this domain can write it for us. I have the entire practice workspace that talks about what we do. I have the brand workspace. I have the offers workspace and others. We have expert copywriters that we can invoke as personas, such as Swartz. Tell me how we should build domains that aren't dependent on me writing the problem statement. I want AI to do the thinking, and I'll collaborate with it.

The derivation brief above went out at 7:06. D1 was replaced at 7:10. I said keep at 7:14 and added one more requirement: every rule is something to test, so each post records which rules it followed and the results can be compared later without rebuilding anything. Committed at 7:16. Session closed at 7:19.

What went wrong

Five corrections from me, in order. Each one is a rule now.

1. It defended the system it was reading. The first answer confirmed the existing folder as correct because every other folder pointed at it. Routing is not fitness. A thinking session starts by putting the system on trial.
2. It reached for consolidation. Fewer folders was the obvious fix and the wrong one. The folders are domains of knowledge; the fix was composition, and the word for it already existed in another folder written that morning.
3. It gave work folders plans. After I asked for plan files that name the other folders a plan depends on, it implied every folder should have one. A folder that does work has a method, its numbered steps, and nothing called a plan. Plans belong to the domain above it. The confusion came from a real precedent: one work folder had written a plan inside itself three days earlier, because no domain existed to hold it.
4. It quoted me back to myself. The first standard opened with my own sentence restated. A standard built that way defeats the purpose of using a model at all. Judgment is synthesised; only facts are never invented.
5. It asked me for a sentence it could have derived. The rule against that already existed in two of my folders: before asking Nick anything, look in the sources. The session broke it, I refused, and the derived sentence was better than the one I would have typed, with 23 rows of evidence behind it and two errors in the placeholder shown from my own files.

Also, not a correction: the cold reads. Three rounds on the research file and one on the standard, 89 stalls and five conflicts in total, every one a word I use daily that a stranger could not act on.

The numbers

Steal this

The three briefs below are the ones that did the work. Blanks are in capitals. None of them needs my folders. In Claude Code, "send a sub-agent" means asking the session to start one with the brief; in any other tool, open a fresh chat with no history and paste the brief. The order that worked: research first, to learn what the field already knows; then derivation, to make the system draft the decision from your own documents; then a cold read of whatever came out. If you have no documents for the derivation, the first step is the one at the end of this post: list which documents would let someone else make the decision.

A research brief for a parallel sub-agent. Three of these ran at once.

You are a research agent. Use web search and web fetch. Do not read or
write any local files. Return your findings as markdown.

RESEARCH QUESTION: QUESTION, STATED SO THAT THE ANSWER IS A SET OF FILES
OR MECHANISMS, NOT AN OPINION.

Cover at minimum: LIST OF 5 TO 8 NAMED THINGS TO CONFIRM EXIST BEFORE
DESCRIBING.

For every source: URL, author, date, and whether you READ the full text
or only a summary. Never invent. UNKNOWN where you cannot confirm.

OUTPUT: a table (WHAT | WHAT IT KEEPS ON DISK | WHO WRITES IT AND WHEN |
SOURCE | READ STATUS); then 5 to 10 short paragraphs on what the sources
agree on and where they disagree; then the names that recur.
Plain English, no em dashes.

A cold-read brief. Send the file to a reader with no context, as the person who will have to act on it.

Read FILE. Do not read any other file. You have never seen this before and
know nothing about who wrote it. You are the reader it is for: THE PERSON
OR SESSION THAT WILL ACT ON IT, WITH NONE OF THE CONVERSATION THAT
PRODUCED IT. Go paragraph by paragraph. For each, say in one line what you
think it is asking you to do or understand. Write STALL where you cannot,
or where a word is used as if you should already know what it means here.
Do not guess politely; a confident wrong reading is a STALL too, so say
what you assumed. Then explain back, in your own words, every term the
page seems to have coined; a term you cannot explain back is a STALL.
Also say whether any two rules contradict each other.

A derivation brief. The one that replaced me.

Draft ONE SENTENCE OR DECISION, in the words THE READER would use. Read
these, by path, and nothing outside them: LIST OF 6 TO 10 FILES THAT HOLD
THE EVIDENCE. The lens: NAMED EXPERT and the question they would ask of
the material. The result must be something the evidence shows is true,
not something I would like to be true.

OUTPUT: a table of evidence (quote or fact, file, who said it), at least
12 rows. Three candidates, each with the rows it rests on and one line on
what the lens would say is wrong with it. Your recommendation of one.
Where my placeholder was wrong, if I gave one.

One rule in a standard that can be tested.

ID. THE RULE, AS A POSITION SOMEONE QUALIFIED COULD DISAGREE WITH, IN ONE
OR TWO SENTENCES. Why: THE SYNTHESIS OF THE EXPERTS BEHIND IT, SHARPER
THAN ANY ONE OF THEM SAID IT. Source: WHO AND WHEN. Status: APPROVED BY
YOU, OR PROPOSED AND IN FORCE UNTIL YOU RULE. Helped 0 / Hurt 0, counted
from whether each piece that followed the rule beat your usual result.

What this means if you run a business

The afternoon turned on one refusal. The system asked me to write a sentence about what problem my business is known for solving. I said no. Every piece of evidence for it was already in my files. A system that makes me type what it could read is a form I fill out, not an expert I work with.

That is the same question I'd put to any leadership team adopting these tools: is the AI executing your judgment, or forming its own from your evidence and showing you the work? The first is faster typing. The second is the beginning of a team. It needs three things you probably haven't written down: where the evidence lives, what lens to read it through, and a rule that a draft comes to you with its sources before a question ever does.

If you want to try it, pick one decision you make from experience every week. Write down which documents would let someone else make it. Hand those to the tool with the brief above and judge the draft, not the blank page.

Credits and further reading

• Interpretable Context Methodology, by Jake Van Clief and David McDermott: the paper. The method behind the folders, and the one that says its reference files are configured once. The folder designed here is an answer to its future-work section.
• Agentic Context Engineering, Zhang et al., arXiv 2510.04618, on why a playbook should change by small edits and never be rewritten whole.
• Eugene Schwartz, Breakthrough Advertising, for the awareness and sophistication lens the derivation used.
• The four creators whose public posts shaped the standard, one idea each: Sabri Suby (pick a side), StoryBrand (give the framework away, make it usable), Dan Henry (change how they see the problem, then show the mechanism), Sam Stoffel (be known for one problem; show your face, your mistakes and your results). Chris Donnelly's guide to the current LinkedIn ranking system supplied the three-topic rule and the funnel tiers.
• Michael Nygard's architecture decision records, and the Google SRE book on blameless postmortems, for the shape of a record that never deletes and always says why.

Where this goes next

The two files sit in the builder's inbox, beside a brief from another session the same day proposing the same eight files for every folder. Four decisions wait there, each with a recommendation: whether a domain is a new kind of folder at all; whether its three new files stay separate from the eight; whether it sits above its work folders on disk or beside them; and where the one list of every plan across all my folders lives. If the answers are yes, the next session creates the content domain, seeds it with the standard, and the first weekly reflection reads what the posts did and proposes the first change to a rule.

The standard's own last line says the method for testing it is deliberately not designed yet. Every rule is something to test. The posts will tell me which ones were right.

If you want the next build log when it's out, the newsletter sign-up is on this site. And if you try the derivation brief on a decision you usually make from memory, tell me what it found that you had forgotten you knew.