Sixteen months ago, I described a business operating system for the age of AI. I deliberately left it unnamed. Today I can finally tell you what it became.
In May 2025, I published an essay called:
I was laying the foundation for something I could not yet fully see. I knew its five building blocks: mental models, principles, metaphors, frameworks, and AI agents. I knew it had to be rooted in craft. And I knew it could not be another productivity template with AI sprinkled on top.
I ended with a promise:
I haven’t named this system publicly yet.
Today, I am keeping that promise.
The name is CraftOS™.
But I owe you more than a name. I owe you the story of what changed between that essay and this one—because CraftOS did not simply acquire more features. My understanding of the problem changed.
The year I did not rush
The dominant instruction in AI has been: build. Ship something. Move fast. Automate a workflow. Connect legacy systems with AI through fancy MCP connectors and AI-written APIs. Launch agents. Orchestrate agentic flows. Loop. Graph. Do the AI thing—whatever that happens to mean this week.
All of the above have their value. I did something less fashionable. I thought.
For much of the year, I thought about what work was becoming. I studied what the machine was good at, what human beings remained responsible for, and what separated using an AI tool from becoming native to an AI-shaped world.
To be honest, I took longer than I should have. I was thinking and learning, but I was also circling the problem instead of committing to a form. Still, the delay was not empty. It was diagnosis before prescription. It forced me to question the work itself. Otherwise, we will use extraordinary technology to reproduce yesterday’s thinking at greater speed. That is not transformation. It is confusion—faster.
There was building during this period, but it happened close to the work. I built for myself first. I experimented with personal agents, memory, context, tools, controls, and recurring work. I began bringing the same ideas into Atlantis Leadership, a business where the work involves real people, real relationships, and real consequences. The leaders in our organization and their teams continue to give me room to experiment. That matters. In an existing business, technical permission is not enough. Change also requires earned trust: enough credibility with the people affected by the system that they will help test a different way of working.
The thinking shaped the building. The building corrected the thinking.
That loop became CraftOS.
From five building blocks to a working system
Looking back, I can see the progression more clearly than I could while living through it.
In early 2025, CraftOS was primarily a system of thought. Mental models simplified complexity. Principles guided decisions. Metaphors made difficult ideas memorable. Frameworks turned thinking into action. AI agents carried out parts of the work.
Then I treated Notion as a possible home for those pieces—a practical canvas where the system could become visible. I thought in Lego blocks: useful modules that could stand alone and also connect. I imagined building agents for my own business, learning through use, and eventually helping others do the same. My mind was connecting like this: use the system and refine it in real work.
That early architecture was directionally right. But it was incomplete.
I was right to think about the container. But the system was not the files and content inside Notion. At the time, the word I needed had not yet entered the lexicon. That word—harness—entered the public vocabulary in February 2026. And it led to a deeper question. Not only, Where does the system live? but What must the system do?
Today, CraftOS has two inseparable layers:
A thinking layer that helps us identify the craft, judgment, principles, and standards at the center of the work.
An execution layer that turns that judgment into a system of agents, memory, tools, controls, and reusable units of work.
The first layer asks better questions. The second makes the system operational.
That is the evolution: from a library of building blocks, to a workspace or container, to an execution environment—the harness—and finally to an operating architecture for human judgment and machine capability.
AI nativity is not tool adoption
I have been using the phrase AI native for some time. It now needs a sharper definition.
AI nativity is not measured by the number of tools we use. A tourist can carry an excellent phrasebook. A native does not translate every sentence before speaking.
AI nativity is the degree to which a person or organization has reimagined its work on the assumption that capable AI is part of the operating environment from the beginning. It’s not a patch on the legacy systems. That is why AI nativity is not about business transformation through AI. It’s re-envisioning a business with AI from the get-go.
Most AI adoption still begins with the old work and asks how to perform it faster:
How can AI write this email?
How can it summarize this meeting?
How can it automate this workflow?
How can the same output require fewer people?
These can be useful questions. They are simply not the first-principles question.
The first-principles question is:
If we were designing this business today, with these capabilities available from the beginning, what would the work become?
That question does not merely automate a process. It opens the process. It asks which steps exist for good reason, which are historical residue, where judgment truly matters, and what only a human being should decide.
Picture a score. One hundred is the asymptote: every module of the business reimagined, with the craft amplified rather than replaced.
Most businesses I encounter sit at ten or twenty—not because they lack tools, but because they are diligently answering the wrong question, or they think they cannot afford AI nativity with existing legacy workflows, systems, employees and paying customers. How a business can raise its AI nativity score is a question for another day. The answer will depend on the specifics of the business.
This led me to an inversion I did not expect: AI nativity is not only a destination. It can become a condition for deeper thought.
As parts of my operation became more capable—retaining context, preparing work, organizing knowledge, and carrying tasks forward—they returned something precious to me: time to think. Better thinking then produced better systems. Better systems created more room for thought.
I could begin this way because my AI work had no employees, inherited workflows, or legacy systems. Treating myself as a business—and that is a useful way to look at it—I carried very little baggage. Applying this within an existing operating organization was different. It had real people and real processes. Bringing AI nativity there required trust from the leaders in our organization and their teams.
Nativity funds thought. Thought compounds nativity.
That is the flywheel.
The durable value is moving up the stack
During this same period, the AI field widened its focus.
First came prompt engineering: learning how to ask the model well. Then context engineering and loop engineering: giving the machine the right memory and letting it act, inspect the result, and try again. Now the attention is moving toward harness engineering, graph engineering, and ontology engineering: building the runtime the model inhabits, mapping the work and its relationships, and naming the units of work precisely with the right provenance.
The frontier is no longer only the intelligence inside the model. It is also the system around it: memory, tools, permissions, feedback, state, evaluation, and human control.
That system is the harness.
Think of a car.
The model is the engine. Engines matter, and some are better suited to particular work than others. But engines are increasingly interchangeable. Today the engine may be Muse. Tomorrow it may be Astra, Fable, or multiple engines serving multiple purposes. The car does not depend on a single engine remaining under the hood.
The accelerator is autonomy: how much the system may do without stopping to ask.
The brakes are guardrails: approvals, limits, and kill switches.
The gears are modes of operation: from supervised drafting to bounded execution.
The gauges are observability: the ability to see what the system is doing, what it used, and where it may be wrong.
The steering is human intent.
Most important, the destination remains a human choice.
This is where I would sharpen one of my earlier beliefs. The model creates value, but the more durable value moves toward the harness—because the harness contains the context of the business and its way of working. It carries the permissions, memory, standards, and judgment that a generic model does not possess.
My own path through this became very concrete. It began with Garry Tan’s GBrain, an open-source memory layer for agents. Then came Meta’s personal agent Muse. I installed GBrain through my Codex harness. Then came the Muse–GBrain integration. Then my own system, my “K-brain.” Grokbots are next. Not yet.
My personal agent, Hannah, is one inhabitant of this harness. The names will change. The models certainly will. What matters is the architecture that lets all of them serve a coherent purpose.
I have a state-of-the-art Mac mini M5 Pro coming to run my CraftOS lab. The 48 GB unified-memory beast—with its 15-core CPU, 16-core GPU, and 16-core Neural Engine—will be a rich playground. I plan to set up multiple sub-harnesses and environments: Claude Code, Codex, GeminiLM, Muse, Grokbot, OpenClaw, and Hermes. I will use them to run my personal agents and K-Brain and to do work for our organization.
I claim expertise. I do not claim completeness. In AI, completeness would be a confession that we had stopped looking. New capabilities arrive constantly. Just recently, a fast, general-purpose classifier called Jev appeared. It performs classification and returns the results in a structured format—remarkably fast. In my testing, it did this work better than any of the language models I tried. Testing it was fun. It is the kind of development that forces us to revisit our assumptions about which jobs require a large generative model.
The missing unit: work itself
A harness still needs something to operate on.
The smallest piece is a work unit: a bounded piece of executable work with an expected outcome. Connect work units through dependencies, decisions, and changing state, and we get a work graph. Bound part of that graph around a meaningful, repeatable outcome and we get what I call a WAI Module™. WAI means Work by AI: work is the primary unit, performed by the AI module. It does not merely mean working with an AI module.
Consider a proposal.
In many companies, proposal creation is a familiar workflow: gather notes, find an old document, copy the structure, draft the language, check the numbers, circulate it for review, and hope the best thinking survives the handoffs.
Automating that workflow would make the same chain move faster.
A WAI Module begins elsewhere. It asks:
What must be understood before a proposal should exist?
What does an excellent proposal look like here?
Which judgments belong to an expert?
Which research and preparation can an agent perform?
What evidence must be visible?
Where is approval required?
What should the system learn after a win or a loss?
The result is not simply an automated document. It is a bounded operating capability. The module carries the standards, context, controls, and feedback needed to produce the outcome repeatedly—without pretending that judgment has disappeared.
The organization’s craft is encoded in the module. The machine extends its reach.
I eat my own dog food. The first modules were built for my own personal assistance. Now the same approach is going into our organization, where it will serve its leaders and their teams. One module at a time. Thinking in action, not thinking about action.
Craft is the part we should not automate away
Why call it CraftOS?
Because craft has always been the point.
When I launched the Craft publication, I began with Cal Newport’s craftsman mindset in
: focus on what we can offer the world, build rare and valuable ability, and become so good we cannot be ignored. I was writing about the craft of the individual.
CraftOS extends that idea to the enterprise.
Every good business contains knowledge that is difficult to see from the outside. A practiced eye notices what a novice misses. An experienced leader hears what was not said. A skilled advisor knows when the standard process is wrong for the situation. A great team shares an understanding of what good looks like, even when that understanding has never been documented.
That judgment is the real asset.
If we automate only the visible steps, we risk stripping the craft out of the work. If we design the harness carefully, we can do the opposite: make the craft explicit, preserve it, teach it, improve it, and allow it to compound.
In a world of increasingly abundant machine intelligence, generic output becomes cheaper. Specific custom harnesses, judgment, taste, accountability, and earned trust do not.
Craft is not a nostalgic defense of human work. It is the design principle for deciding what the human-machine system should become.
An operating system—not an AI product with business language attached
I want my non-technical readers to hear this clearly: CraftOS is not an AI product with a little management philosophy attached.
Four of the five original building blocks—mental models, principles, metaphors, and frameworks—are ways of thinking. Only the fifth was the agent. That proportion was not accidental.
The Window and the Mirror helps a leader distinguish accountability from blame. The Chinese Bamboo Tree makes invisible preparation easier to understand. The Iceberg reminds us that the forces most likely to derail the work may sit below the visible surface. A framework turns insight into repeatable action. A principle helps us decide when the framework does not fit.
AI does not make those distinctions for us. It increases the consequences of whether we make them well.
This is why CraftOS needs both faces:
The human face asks what the business is, what it values, and where its craft lives.
The machine face builds the harness through which that craft can operate at greater scale.
The thinking layer without execution remains a collection of good ideas. The execution layer without the thinking becomes efficient emptiness.
CraftOS is the bridge.
The name—and the work—ahead
Giving the system a name does not mean declaring it finished. It gives the work a center of gravity—something I can explain, test, and improve in public.
The work is not finished. It should not be.
The technology changes too quickly for a serious practitioner to declare victory. Models will improve. New kinds of memory and decision systems will appear. Today’s architecture will be tested by tomorrow’s capability. Completeness in this field would not be a badge of confidence. It would be evidence that we had stopped looking.
I am building CraftOS™. As time permits, I will also write in public about the components taking shape. Some editions may open the hood on the machine: memory, controls, agents, work graphs, and WAI Modules. Others may return to the thinking layer: mental models, principles, metaphors, and the nature of work and craft itself.
The car in this piece is more than an analogy. It is also a map for what comes next. In a future edition, I will open the hood on the control layer: how the brakes work, how the gauges work, and how we remain in command of a system that can act on our behalf.
We need both.
Sixteen months ago, I could see the pieces but not yet the system. Today, I can name the system and state its purpose:
CraftOS™ is an operating architecture for identifying human craft, encoding it into AI-native work, and keeping human judgment in command as the system scales.
The engine may be rented.
The harness must be custom-designed and owned.
The craft must remain ours.
AI disclosure: The underlying ideas, judgments, lived examples, and final editorial choices are mine. I used AI as a research and editorial collaborator in developing this draft.
CraftOS™ and WAI Module™ are claimed trademarks.
Follow me on LinkedIn