In-place AI

The drag-and-drop pattern

Most people putting AI to work are running it through a chat tab - stuck in a loop of copying data in, asking the next question, and copying the answer back out. The shape is familiar:

• Open a new chat
• Drag some files in, or paste some text
• Ask the questions
• Close the tab
• Start over tomorrow

Fine for a one-off. A terrible system for anyone running more than one project at a time.

Some memory gets captured along the way, but you don’t know where it lives, whether it has gone stale, or how much context is bleeding from chat to chat. Project folders and document libraries inside the chat UI solve part of this - at the cost of a duplicated copy of your work in the custody of a third party, with the context stranded inside a UI you don’t control. AI is supposed to lighten the load, not split the work into a primary copy and a shadow copy that has to be kept in sync.

I spent the last year running AI across a sponsor shop at Structured, across three separate CBKDI consulting engagements, and across my own business - simultaneously, constantly - and the failure mode of drag-and-drop AI shows up the moment your projects multiply. Knowledge doesn’t persist reliably or locally. Every session starts from zero. You re-teach the AI your own deal every time.

The cost is invisible because every web-chat AI is designed to feel fresh each visit. The reset is the product. But for knowledge work that accumulates over months or years - development deals, underwriting, operations, a consulting book - the missing context is what holds you back.

In-place AI

The alternative is simple, and once you have seen it you cannot unsee it:

AI should meet your file system in place, read and write directly to the directory tree you already have, and let new knowledge stack on top of the baseline files. No chat tab. No drag-and-drop. No re-teaching.

Call it in-place AI. The verb-contrast is deliberate. The dominant pattern is drag-and-drop AI; the alternative is AI that stays put.

Three moves doing the work:

1. Meet in place - AI reads and writes to your file system, not to a chat tab’s memory.
2. Stack on top - knowledge accumulates as a layer over the files you already have, not as a parallel universe.
3. Travel with the project - the knowledge replicates, backs up, and moves with the directory tree itself.

My current weapon of choice is Claude Code, in the terminal, invoked at the directory I need for that moment’s work. Here is an example of my working structure today.

The federated shape at Structured

Here is what it looks like at Structured, where I run AI across a multi-deal sponsor shop.

mothership/                              sponsor-shop root
├── CLAUDE.md                            ← mothership memory
└── projects/                            container, no own brain
    └── 2507 - Sample Project/           one deal
        ├── CLAUDE.md                    ← deal-level memory
        ├── proformas/                   financial models
        ├── construction/                drawings, schedules
        ├── leases/                      tenant thread
        │   └── CLAUDE.md                ← topic-level memory
        └── due diligence/               underwriting materials

At the root of the directory sits a mothership-level CLAUDE.md - Claude Code’s convention for project-level instructions. It describes who I am, who Structured is, how the company operates, working vocabulary, the names of current partners and stakeholders, anything that is true across every deal. When I open a session from the shop root, that is what loads.

Each active deal has its own subdirectory. Inside each deal, its own CLAUDE.md - this one describes the deal itself. Partners, capital stack, timeline, what has been agreed, what is contested, what the current blockers are. Starting a session from inside a deal directory narrows the context to the deal only, improving token efficiency when the scope of work is narrow.

Below the deal level, important topics earn their own brain. A leases thread with renewal calendar and tenant history is a typical example - the context is focused enough to deserve separation. Most topic folders don’t earn it - proformas, construction, due diligence usually inherit from the deal level rather than carrying their own.

This is the federated shape: mothership → deal → topic-inside-deal. It mirrors how any multi-project sponsor shop already organizes itself. The directory structure was there before AI. Adding CLAUDE.md files at each level is a light touch on top - a few hundred words per file, sometimes fewer - and the accumulation of context across levels does the work.

Nothing about this is specific to sponsor shops. Any practice running multiple projects simultaneously already has this shape. A consulting book. A design studio. A law firm’s matter tree. A GC’s job folders. The pattern just inherits the organization that already exists.

Closeout and dream

Federation by itself is not enough. Without discipline, the setup degrades two ways:

1. Memories accumulate at the wrong level or drift. Context about a tenant can get stuck at the leases level and get missed at the project or entity level.
2. Old memories linger. A note about a partner’s preferences written six months ago keeps firing even after the preference has shifted.

I built two small Claude skills to handle this: closeout and dream.

closeout runs at the end of a session. It looks at what Claude learned during the session - new facts about a deal, new preferences I expressed, new conventions discovered - and asks: where does each of these actually belong? A fact about a project’s capital stack belongs at the deal level. A preference about how I want proformas formatted belongs at the shop level. A general habit of mine belongs at the user level, above any specific project. Closeout puts each learning at the correct layer of the tree.

It also discovers the shape of the project tree, determines which level it was invoked in, decides where the memories from that session belong, and detects drift across the whole tree.

Critically, closeout also drives memories from user-level to project-level. Claude Code distinguishes between user-level memory (attached to me as a user, across every project on this machine) and project-level memory (attached to this directory, which means it replicates with the directory). By default, new memories drift into user-level. Closeout migrates them down into the relevant project’s .claude/memory/ directory, where they sit with the files they describe.

closeout · user → project   ·   dream · project ↻ project

Project-level memory is the version that matters. It gets version-controlled if you are using git. It backs up with the rest of the directory. When you sync across machines through Dropbox or iCloud or whatever, it comes with you. When a teammate pulls the project, they inherit the memory.

dream runs on a cadence - weekly, for me - and does consolidation work on project-level memory. Reviews what has been accumulating, merges duplicates, prunes stale notes, reorganizes when a topic has outgrown its original placement. Without dream, even well-organized memory eventually congeals into a sludge of half-relevant notes.

A practical aside on where the tools themselves live. Claude Code distinguishes between user-level plugins (installed once per machine, available in every project) and project-level plugins (checked into the directory, replicated with it). The same discipline applies. Plugins that are personal to how I work - my own preferences, my own shortcuts - live at user-level. Plugins that encode how a specific project operates - a customer-specific macro convention, a project-specific proforma quirk, whatever - live at project-level. What is personal versus what is federated is a deliberate decision, not a default.

The daily payoff

The most immediate payoff of this setup is not for teams. It is for a single operator running across multiple machines.

I work on my main workstation most days. I travel with a laptop. I occasionally pick up work on a third machine. Without project-level memory, every machine is a fresh start - Claude knows nothing about the deal I was working on yesterday because yesterday was on a different machine.

With project-level memory that lives inside the project directory, the context comes with me. Dropbox syncs the directory. I open a Claude session from the same deal subfolder on the laptop, and Claude knows the deal, the shop, my preferences, the partners, and everything else Claude knew on the desktop the day before. Nothing re-taught. No re-upload. No session reset.

This is the daily payoff. It fires every time I pick up a deal on a different machine, which is multiple times a week. The team dimension is theoretical for me right now. The multi-machine dimension is the one I am actually living in.

What happens when teams show up

The same mechanism that makes solo-multi-machine work is what enables team sharing once a team exists.

When project-level memory lives in the directory, and the directory is shared across teammates through git, Dropbox, or any other sync mechanism, the memory is shared too. A new teammate pulling the project for the first time inherits not just the files but the AI’s working knowledge of the project. The learning curve collapses. The team operates from a shared working context instead of each person re-learning the project in their head.

I am not running this with a team yet. At Structured, I am the only one writing to the memory layer. CBKDI is a one-person consulting practice. The team dimension is the shape of a problem I can see coming, not a failure I have already navigated.

The shape I can see: if a teammate writes bad memory into the project layer, everyone downstream inherits the bad memory. A misfiled preference at the deal level pollutes every future session that starts from that deal. A partner note that was true six months ago keeps firing for a teammate who was not in the room when it shifted. The same discipline that makes closeout and dream useful for a single operator becomes critical team craft - the difference between a shared working context and a shared pile of noise.

That is a real risk, and I will write about it honestly when I have actually run it team-wide. For now, the argument stands on the solo case, which is where most operators reading this are sitting anyway.

The wrong question

Most of the conversation about AI in knowledge work right now is stuck at the wrong question. Which AI tool should I use? ChatGPT versus Claude versus Gemini versus whatever ships next quarter.

The more useful question is: how do I design the layer on top of the work I already have, so that the layer replicates where the work goes?

You do not migrate to AI. You augment where the work already lives.

Your file system is the scaffolding. Your existing directory structure is already the shape of how you think about your work - why would you abandon it the moment AI shows up? Meet AI there. Let it stack on top. Let it travel with the project.

That is the whole pattern.