Why I’m building my business around folders

An operations hub, one folder at a time

Inside my assistant folder, I’m gradually building a hub for how I run the business. Research, reporting, sales, client operations and other aspects of the work have their own places. More of the operation is becoming folders as I work through what belongs there and how it should work.

Those folders contain a mixture of instructions, reference material and the work itself. Some describe a repeatable process. Others hold knowledge or the context for a particular project. The hub gives an assistant a starting point and a way to find the material relevant to the task.

It is still developing. What interests me most about it is the useful life of what I’m building.

I expect to change AI tools many times. I want the effort I put into explaining my work to survive those changes. If I’ve taken the time to describe a process, record a decision or organise useful knowledge, I want to be able to carry that forward.

Files and folders make that feel like a reasonable expectation.

What I mean by ICM folders

The workflow pattern comes from Interpretable Context Methodology, or ICM, created by Jake Van Clief and described in a paper co-authored with David McDermott.

ICM organises work into stages with written instructions and file-based handoffs. Each stage defines what it reads, what it does and what it produces. A person can inspect and edit an intermediate result before the next stage uses it. The original repository explains the conventions and provides examples.

My hub brings several of these workflows together alongside reference knowledge, memory and project material. That larger arrangement is my implementation. ICM applies within its workflows; the hub gives those workflows somewhere to live.

The interesting part for me is how much can be expressed in materials that are easy to open, read and change.

The investment survives the agent

When I write down how a piece of work should be done, I’m making an investment in that understanding. I want it to be available to the next session, the next tool and the next person helping me.

A folder gives that understanding a home outside the conversation in which it was created. A capable agent with file access can read the guidance and the saved work without having participated in the original discussion. It still needs to orient itself, but there is something explicit to orient itself from.

That is the durability I care about. I can stop using an agent without abandoning the material I built with it. I can open the same files in an editor, move them to another machine or give a future tool access to them.

For as long as computers can read text files and navigate folders, there is a straightforward way into this work. I don’t have to predict which agent I’ll prefer in a few years to make use of that interface today.

There is a limit to the claim. An integration may change. A script may need updating. A future agent may interpret an instruction differently. Readability gives me a starting point for adapting the work; it doesn’t promise that every part will execute unchanged forever.

The part I want to preserve is the accumulated description of what needs doing, what matters and what has already happened.

An afternoon, a few months, or many years

Durability is useful even when the work is temporary.

A workspace might exist for one task. I can put the brief and source material together, produce the result, and archive the folder when I’m finished. It has served its purpose. If I need to revisit the result later, the material is still there.

A project might take several weeks or months. It will have pauses, changing requirements and decisions that need to survive between sessions. Saving those things explicitly gives me somewhere to return to and gives a new assistant a way to pick up the thread.

An ongoing business function might last for years. Its instructions and references can develop as the business changes, while individual runs remain separate pieces of work.

The structure can be as small or as extensive as the work requires. A short task may need only a brief, some inputs and an output. A recurring process may justify several stages and shared reference material.

The workspace’s lifetime belongs to the work. I can close the agent, leave the folder alone for six months and return to what I saved. Whether the task lasts an afternoon or a decade, it has somewhere to exist between conversations.

What the next agent finds

The root of my hub contains a map that routes tasks to the appropriate workflow. From there, the workflow describes its stages, and each stage identifies the material it needs.

Reporting is a concrete example. The workflow has three stages: pull the data, analyse it into findings, and format the report. A catalogue defines the available report types. Each execution chooses one report type and gets a separate run folder.

Here is a simplified view of that arrangement:

reporting/
├── CONTEXT.md
├── _config/
│   └── reports.md
├── stages/
│   ├── 01-pull/CONTEXT.md
│   ├── 02-analyze/CONTEXT.md
│   └── 03-format/CONTEXT.md
└── runs/
    └── <date-and-report>/
        ├── 01-pull.md
        ├── 02-analyze.md
        └── 03-format.md

The analysis stage reads the relevant report configuration and the data collected for that run. Its instructions ask for findings, supporting evidence and uncertainty. Formatting comes later.

That separation gives the next agent useful answers. It can discover what the report is for, which stage it is carrying out, what evidence is available and where its result belongs.

The report definition can be reused across many runs. The findings from a particular week belong to that week’s run. Keeping those distinct makes it easier to see which material describes the process and which material is the product of carrying it out.

This is an example of how the workflow is defined in my hub. The folder layout alone is not evidence that a particular report has been produced successfully; the saved output and its review would need to show that.

Why this appeals to an engineer

I’ve spent twenty years across software engineering, infrastructure and operations. Being able to inspect and maintain a system matters to me. That preference carries over to how I want to work with AI.

If an output is wrong, I want to see the material it was built from. If a requirement was missed, I want to find the instruction that was supposed to capture it. If I change that instruction, I want a way to understand the change later.

Readable files make those questions approachable. I can open a stage’s instructions alongside its input and output. I can correct an intermediate artifact before proceeding. Where I deliberately track the relevant files in Git, I can compare versions and restore an earlier definition.

There is also value in knowing where a piece of work stops. A stage with a defined output gives me something specific to review. I can decide whether that result is ready to support the next step.

None of this exposes the internal reasoning of a model. It makes the recorded workflow available for inspection. That is useful enough on its own: I have evidence to examine and places where I can intervene.

It also changes the handover. Another person can read the same instructions and artifacts. They may still need explanation, access and domain knowledge, but the process has an accessible written form.

Improvements have somewhere to accumulate

I want a useful correction to have a life beyond the output I happen to be reviewing.

Suppose a recurring report needs to distinguish confirmed information from uncertain information. I can fix an individual report when that distinction is missing. If it is a standing requirement, it also belongs in the instructions that govern future reports.

That is the sort of improvement I want the hub to retain. The next run should have access to what I clarified, even if it is carried out by a different agent.

There is judgement involved. A change requested for one client or one occasion should not automatically become a rule for everything. I need to decide whether it belongs in the current run, a particular workflow or shared guidance.

Over time, those decisions can make the hub a more useful description of the operation. They also create maintenance work. Old guidance needs retiring, contradictions need resolving, and shared information needs a clear home.

The value comes from making and maintaining those improvements. The folder gives me somewhere to keep them.

What still needs care

A saved instruction can still be a bad instruction. A neatly named output can still be incomplete. A folder full of files can leave the next agent uncertain about what is current, what has been approved and what remains to do.

Durable work needs those distinctions written down. It also needs appropriate access to the tools that carry it out. A procedure describing how to collect information from a service cannot supply working credentials or repair a changed API by itself.

Multiple agents working at once introduce further questions about ownership, conflicting edits and execution order. Unattended production work can require queues, monitoring and recovery mechanisms beyond the folders.

The ICM paper acknowledges limits to its evidence: the practitioner observations are preliminary, and it does not report a controlled comparison establishing an output-quality advantage over monolithic prompting. Its discussion identifies concurrency and complex automated branching as areas needing more machinery. Paper, limitations and scope.

My reason for liking this approach is practical. It gives the knowledge and instructions an understandable home, and leaves me room to add the machinery a particular job needs.

Start with one useful piece of work

You don’t need an entire operations hub to try the idea. A sensible starting point is one task with inputs you can identify and a result you know how to assess.

Write down what the task is for and what a good result must contain. Put the reference material somewhere explicit. Tell the agent what to read, where to save its output and when you want to review it.

Then use it. Inspect the result and the points where the instructions left too much unclear. Improve what deserves to be reused.

Stages become useful when there is an intermediate result worth checking. For a report, that could be the collected evidence or the findings before presentation. For a proposal, it might be an agreed outline before the full draft.

Let the structure earn its place. Add it where it helps you understand, repeat or resume the work. A folder for a single afternoon’s task is a perfectly reasonable outcome.

What I want to keep

I expect the way I interact with AI to keep changing. The agent I use, its interface and the tools available to it may all look different in a few years.

Meanwhile, I’m gradually making more of my work explicit. Some of those folders will finish their job quickly. Others may become part of how I run the business for a long time.

I want both to remain understandable when I return to them. I want a person or a capable agent to be able to open the folder, find the context and work out how to continue.

I’ll keep changing the tools I use. I want the understanding I build along the way to stay useful.

---

If you’d like help building a workspace like this for your business, email us at hello@coralgardensoftware.com. We can start with one useful workflow and build from there.