Part I: Building My Own AI Harness

The Problem:

I used AI the way most people do. Open a conversation, work the problem, copy what was useful, and move on.

The models were already good enough to help me troubleshoot software, sort through a pile of notes, draft something, or push back on a plan with too many moving pieces. Intelligence was not the bottleneck. Starting over was.

Every new conversation meant explaining who I was, what I was working on, how I wanted the answer, and what we had already decided or ruled out. Longer projects scattered that context across tabs and conversations.

To be fair, the AI companies were already working on this problem.

Project spaces in services such as ChatGPT and Claude made longer work much easier to manage. Files, instructions, and related conversations could finally stay together instead of being scattered across dozens of unrelated windows. That was a real improvement. But the project still lived inside that provider’s environment. If I wanted to move the work somewhere else, much of the structure I had built around it stayed behind.

Connecting AI directly to coding tools and text editors opened another door. For programming, that was enormously useful. An AI could read a codebase, make changes, test its work, and leave the project itself better than it found it. But most of what I was trying to manage was not software development. It was the ordinary administrative work of life: projects, research, finances, household responsibilities, travel, documents, decisions, and all the unfinished things that needed to remain understandable tomorrow.

I also tried going further.

When OpenClaw was getting a great deal of attention in early 2026, I made my own attempt to get it running locally. I have all the respect in the world for the people who got systems like that working well. I did not. Mine never became the dependable personal assistant I was looking for.

Since then, personal agents have become much easier to use. Grok Bot can work across applications on its own computer, and Meta’s Muse gives users a persistent agent running inside its own virtual computer. These are far more capable approaches to long running work than the simple browser conversations I started with.

But they still did not completely solve the problem I was interested in.

As an AI relationship grows, so does the amount of context around it. Conversations accumulate. Files accumulate. Instructions accumulate. Some information becomes stale. Context windows still have limits. Useful details can be crowded out by irrelevant ones. Behaviors drift. Mistakes and assumptions can propagate from one session into the next. Eventually, giving an AI more context can start making the system harder to understand rather than easier.

And underneath all of that was another concern: the structure was still largely tied to the company providing the AI.

I was not looking only for a model that could remember more.

I wanted a way to decide what should be remembered, where it should live, what should stay separate, and how another AI could pick up the work later without inheriting every conversation that came before it.

That was the problem I was actually trying to solve.

After a while, I realized the solution might be found in a lesson I had already learned several years earlier.

The solution:

Over the years, I had used different systems to manage military PCS moves, a rental property from overseas, work in healthcare, and the normal accumulation of projects and responsibilities that come with adult life. The systems that helped most were the ones that held onto commitments and useful information so I did not have to keep everything in my head.

David Allen’s Getting Things Done was one of the larger influences on how I approached that problem. I never cared much about following a particular productivity method simply for the sake of the method. There are plenty of popular systems out there, and people have strong opinions about which one works best. What stuck with me was something more basic: if something matters, it needs a trusted place to live.

So I started wondering whether I could do something similar with AI.

My first idea was fairly straightforward. I wanted a local assistant that already understood the productivity method I used to manage projects, notes, commitments, and the things I was trying to accomplish. If I stopped working today and came back tomorrow, I wanted it to be able to pick up where we left off without requiring another briefing or a series of instructions telling it how to get started again.

The turning point

The day it finally clicked for me came from a slight shift in how I was thinking about the problem.

Until then, I had been asking AI to work on top of my productivity system. I had my own notes, project files, lists, and ways of organizing things, and the AI was something I brought in to help me work through them.

Then I started wondering what would happen if the AI could participate in maintaining that system itself. And perhaps, be an integral part of the system.

Instead of simply reading my notes and giving me advice, I began having the model write its own operating instructions, maintain dedicated files, update project notes, and leave useful information behind for the next session.

That changed the relationship.

A project folder could hold the notes, instructions, documents, and code associated with the work, and the AI could update those files as we went. The useful part of the project no longer had to exist only inside a browser conversation.

More importantly, one session could leave something useful behind for the next one. A decision could be recorded. An unfinished question could remain visible. A lesson could be written down. The next session, or even a different AI model, could read what had happened before and continue from there.

The model itself had not become smarter.

The environment around it had become more useful.

From there, the system grew mostly by solving problems as I encountered them. I wrote instructions more carefully. I stopped asking one general assistant to handle every kind of work. When an AI made the same mistake more than once, I recorded the lesson somewhere the next session could find it. Instead of trusting conversation history to preserve unfinished work, I began leaving short handoffs in the files themselves.

At some point, I realized I had stopped collecting useful prompts and started building something around the model.

That is what I mean by a Personal AI Harness™.

The term harness is not something I invented. It is a useful way of describing the structures people build around AI so the model can do more than answer a single question in a browser window.

My version is built mostly from ordinary files, written in plain English.

Those files can describe roles, responsibilities, boundaries, reference material, lessons, project state, and the routines an AI should follow when it begins or finishes work.

The AI still provides the intelligence. The Harness gives that intelligence an organized place to work.

I like the word harness because a harness does not create the power. It gives you a way to direct power that already exists.

The same AI model can behave very differently depending on the job you give it, the context it receives, what information it is allowed to see, and what you expect it to do with the work when the session ends.

That became increasingly obvious as I started separating different kinds of work.

Technical problems, finances, household administration, travel planning, and designing the Harness itself did not benefit from sharing one giant pile of context. Giving those responsibilities separate places made the system easier for both me and the AI to understand.

That eventually became a larger part of the design, but the basic idea remained simple.

Most of the Harness is written language.

A role can be a text file. A boundary can be a paragraph. A lesson can be a Markdown note. A project can have a short record of what happened and what still needs to happen.

If an instruction is unclear, I can rewrite the sentence.

That simplicity turned out to matter more than I expected. Because the important structure lives in files I can read, I can also change it, move it, back it up, or give it to another AI model later to either follow. I can even ask the models to improve the framework and instruction sets and then review what changes make the model generate better work.

The simplicity is what makes this exciting for me, because anyone can do this for themselves!

The Harness I’ve developed is still changing because I am still using it.

Mine also reflects the way I think. As it grew, I started picturing the different areas of responsibility as parts of a small campus of administrative and corporate buildings. Different kinds of work had their own “Buildings”, and different AI roles had their own responsibilities inside them.

That picture helped me understand the system as it became more complicated.

But the Campus is not the Harness.

It is simply how I chose to picture mine.

Part II is about how that Campus developed, why I separated different kinds of work into their own places, and what happened when the Harness grew beyond a single assistant.