I work with founders at the structural layer of their business — and install the AI operating architecture that lets it run from what it actually is.

Every business runs on an implicit theory of itself. What it is. What exists inside it. What the customer is buying. What is primary and what is secondary. The founder almost never wrote this down. The team inherited it through observation. The customer experiences it as either coherence or friction.

Most strategy work, most operations work, most consulting work, sits on top of this layer without ever touching it. The assumption is that the layer is settled — that everyone already agrees on what the company is, and the only remaining questions are tactical. Strategy becomes how to grow what you have. Operations becomes how to run what you have more efficiently.

But the layer is rarely settled. The founder's theory of the company drifts as the company changes. The team operates from a different theory because they see the daily work, not the original vision. The customer is buying something the company doesn't quite know it's selling. Three different theories of the same business, each partially true, none of them complete, and nobody making the gap visible.

Strategy applied to the wrong picture compounds in the wrong direction. Operations that runs on the wrong frame becomes a more efficient version of work the business should not be doing. Every tactical investment downstream of a fractured substrate makes the fracture more expensive to fix.

This practice works that layer first.

In computing, the substrate is the layer the applications run on. In biology, the substrate is what the organism grows in. In chemistry, it is the surface the reaction takes place on. Across every serious field, the word means the same thing: the layer underneath that makes everything above it possible.

A business has a substrate too. It is not the org chart. It is not the pitch deck. It is not the marketing site. It is the structural reality those things sit on top of — what the company actually is when you strip away how it has been described, and what it is becoming when you watch it move under pressure.

The substrate is visible if you know how to read it. It is what the founder describes in private when nobody is judging. It is the workaround the operators built because the official process doesn't work. It is what the customer says they bought when they describe the purchase to a friend. It is the work the team actually does when the work that was supposed to get done turns out to be the wrong work.

Three or four conversations into a business and the substrate starts to surface. Not as a single sentence, but as a shape. A pattern. The thing the company keeps trying to become every time it makes a decision, even when nobody has named it yet. Reading that pattern is what an audit is.

Once the substrate is visible, the work becomes obvious. The architecture installs on top of what is actually there, not on top of the inherited theory. The team begins operating from the corrected picture daily. The business stops fighting itself.

The work is a single engagement, not a menu. The audit and the install are not separable — the install only works if the audit is correct, and the audit is only worth running if you intend to do something about it. What scales between businesses is not the offer. It is the stakes. The same seeing applied to a solo operator is the same seeing applied to a thirty-million-dollar founder. The price reflects what the correction is worth at that scale.

1. Audit

   I read the company at the structural level.

   Extended conversation with the founder. Interviews with the operators. Review of customer conversations and feedback where it exists. I am not running a diagnostic. I am reading the company across three surfaces — founder, team, customer — and listening for the divergences between them. The gaps between what the company says it is, what its decisions reveal it to be, what the team experiences it as, and what the customer is actually buying.

   The audit produces a written articulation of the company's underlying structure — what is sound, what is fractured, and where leverage is leaking. For many founders, this document alone is the most valuable artifact of the engagement. It is often the first time they have seen their own company clearly.

2. Install

   I build the AI operating architecture that materializes the corrected picture.

   Once the audit is signed off, I install an operating architecture mapped to what the business actually is — not to the inherited org chart. The architecture is built on a published methodology called Interpretable Context Methodology, which uses folder structure as the orchestration layer for AI agents. Every workspace, every routing file, every reference document is calibrated to the structure surfaced in the audit.

   The architecture is delivered as a Git repository the company owns outright. No proprietary platform. No license fees. No vendor lock-in. Anyone on your team — technical or not — can read, edit, and operate it.

3. Handoff

   The architecture is built to be left.

   A live training session with the operators who will run the system. A written playbook documenting the architecture and the structural reasoning behind it. Seven days of post-install support while the team uses the system for the first time. After that, the architecture belongs to the company. The structural correction is encoded in the operating layer of the business itself, and the company runs from it forward.

   I am not retained as ongoing infrastructure. If the install is correct, you do not need me afterward. That is the test of whether the work was real.

The technical foundation of the install comes from a published methodology called Interpretable Context Methodology — ICM. It is the work of Jake Van Clief and David McDermott at Eduba and the University of Edinburgh, formalized in a 2026 paper that applies fifty years of Unix engineering principles to the problem of orchestrating AI agents.

The methodology's central claim is structural: folder structure is agent architecture. Instead of writing application code to coordinate multiple AI agents, you organize the prompts, context files, and reference material into a hierarchical folder system. One agent reads the right files at the right moment. The folder structure does the work a multi-agent framework would otherwise do in code.

I install ICM-based architecture because it is the cleanest available method for translating an audited ontology into an operating system. The folder hierarchy mirrors the corrected structure of the business. Every file is plain markdown — readable, editable, and inspectable by any operator on the team. The architecture is portable, version-controlled, and runs locally. There is no platform to maintain and nothing proprietary to license.

If you want to understand what the install actually consists of, the paper is the most direct way to see it. The preview below is enough to know whether the methodology is interesting to you. The full paper is linked underneath.

A business is not what it says it is. It is what it actually moves through the world. What it absorbs from the people who pay it. What it leaves behind in the team that runs it.

When I read a company, I am not looking at strategy, branding, or operational efficiency — those are downstream. I am looking for the gap between what the company claims and what the company does. The phrase the founder reaches for when pressed. The workaround three operators all share but nobody documents. The thing the customer actually pays for, which is often not the thing on the invoice. Whatever the four surfaces — founder, team, customer, behavior under pressure — say when you put them next to each other and refuse to look away.

What I am listening for is what the business actually produces. Not what it announces. The output is the truth. Marketing copy can lie. Pitch decks can lie. Hires can be wrong. Strategies can be obsolete the day they are written. But the work the company is actually producing, the customer it is actually keeping, the team that is actually operating — those things cannot lie. They are the substrate expressing itself.

This kind of seeing is uncommon because it requires holding the company without flinching. Most consultants are paid to reinforce the founder's existing picture, because reinforcing the picture is what feels supportive in the moment. I am paid to read the picture against the company's actual behavior and surface the divergence — which is sometimes uncomfortable to hear, and always the most valuable thing I can deliver. The relief most founders describe after the audit is not because they were told something flattering. It is because somebody finally said the thing they had been carrying without language for.

Once the substrate is named, the architecture follows. Every file, every routing decision, every reference document in the install is calibrated to it. The team begins operating inside the corrected frame daily, and the company stops working against itself.

The work does not require a particular revenue level, industry, team size, or business model to land. It requires a particular state. The state is this:

You have built something real. The work is happening. The team is there. The systems mostly work. And somewhere underneath all of that, you have felt the frame slip — the quiet recognition that the company you have built no longer matches the person you have become, or never matched what it was always actually about.

You are about to hire someone you privately know is not right. You are about to launch something that doesn't quite fit. You are sitting in meetings where you are performing a role that no longer maps to what you are doing. You can tell the difference between a consultant selling you a service and someone bringing you a perception, and you want the second. You are willing to have your assumptions about your own business examined, and you can hold that examination without getting defensive.

If that is the state, the work fits. The engagement scales with the stakes. What is bespoke for a solo operator at half a million is bespoke for a founder at thirty million. The seeing is the same. The architecture is the same. The price reflects what the correction is worth at the scale you are operating.

I have spent the last two years building AI-native workspace architectures across multiple ventures and ongoing engagements with founders developing operating systems for their own companies. The methodology is the architectural pattern I arrived at in practice before encountering the published research that formalized it. Every pattern I install for a client is one I have already built and refined inside my own work.

The folder-based architectural approach this practice uses was recently formalized as Interpretable Context Methodology. I arrived at the same pattern independently, then encountered the formalization and now work directly with it. The convergence is mentioned not as credentialing but because it speaks to how the work is done: by reasoning from first principles about how AI systems and human teams actually share context, rather than by following someone else's playbook.

The practice is structured to transfer, not to retain. The audit document, the architecture, and the working sessions are all designed so the founder leaves the engagement with the capacity to read their own business structurally going forward. The engagement ends. The architecture remains. The way of seeing remains.

Long-form essays on the work — the underlying methodology, the structural questions that shape every engagement, and reports from the architecture I am building inside my own companies. Updated cyclically as new pieces become clear enough to publish.