Part II: Inside My Personal AI Campus™

Once I understood that I was building a Personal AI Harness™ rather than collecting better prompts, I still had a practical problem: how should all of the pieces fit together in a way I could actually understand and use?

For me, the answer became a campus.

I did not start with a plan for buildings, offices, directors, and a town hall. The metaphor developed because I needed a simple way to think about a growing collection of responsibilities without turning everything into one giant folder or one giant AI persona.

I tend to understand systems better when responsibilities have a place. Financial work should feel separate from technology work. Managing a rental property should not be mixed into language learning or travel planning. Designing the Harness itself is different from deciding what I need to do this afternoon.

So persistent areas of responsibility became Domains, and in my own implementation I pictured those Domains as Buildings.

The distinction matters. A Domain is the structure. A Building is only my metaphor for it.

The metaphor was useful because a building already makes intuitive sense. It has a purpose, material that belongs there, people with different jobs, and routines for keeping the place usable. Most importantly, you do not carry the contents of every building with you all day.

AI benefits from the same restraint. Giving a model everything you have ever written does not necessarily make it more useful. Too much undifferentiated context can make it harder to see what matters now. A Domain lets related information stay together while keeping unrelated material out of the way.

At the center of my system is the Operational Hub. This is where I coordinate work across the Harness at the level where I actually need to act. Projects, Next Actions, reviews, and possible future commitments belong here rather than inside every specialist Domain.

One small feature became especially useful: the Project Candidate. AI is good at noticing possibilities, but I do not want every interesting idea converted into an obligation. A Project Candidate lets the system hold an idea without pretending I have committed to it.

Around the Operational Hub are the Domains. As one area grows complicated enough to need its own context, reference material, or specialist perspective, it can become a Domain without forcing me to redesign everything else.

My AI Campus eventually added a coordination space I call Town Hall. It is not another required layer of the Personal AI Harness. It is simply how I picture work that crosses Domains, acting as a router for message traffic. A technical decision may affect a larger project. A financial question may need facts from another area. Town Hall gives those crossings somewhere to happen without collapsing all the specialties back into one assistant.

The same logic led me to separate two roles I had originally asked one assistant to perform.

“Kat” is the name I gave my AI persona that serves as my operational secretary. Her concern is the movement of work: what I am trying to accomplish, what happens next, what is waiting on someone else, what needs review, and where a new commitment belongs.

“Artemis” is the AI vault architect persona. Her concern is the structure underneath the work: whether information is organized coherently, whether responsibilities are becoming confused, and whether the Harness will still make sense as it grows.

I did not create those roles because I wanted more AI personalities. I created them because operating a system and designing a system are different jobs.

That distinction made the Harness more modular. A new specialist role could grow inside one Domain without changing the rest of the system.

The AI Campus metaphor also gave me a useful way to think about entering and leaving work.

In an ordinary AI conversation, a model can feel as though it has walked into a room without knowing where it is. In my Harness, each important area has enough orientation material for the AI to understand the environment, its responsibility, the current state of the work, and anything worth carrying forward.

When I enter a Building, I do not want to spend twenty minutes reconstructing the last session. When I leave, I want durable changes preserved somewhere outside temporary conversation history. That may mean updating a project, recording a lesson, or identifying the next action. If nothing durable changed, nothing needs to be written.

The point is continuity, not an endless list of logs.

That principle matters more to me than any particular AI Campus terminology.

Someone else might imagine military commands, hospital departments, classrooms, rooms in a house, sections of an orchestra, or no metaphor at all. The metaphor earns its place only if it reduces cognitive friction.

Mine works because I can picture it. I can enter a Domain, work with the context that belongs there, return to the Operational Hub, and see what actually requires my attention. I can bring several Domains together when a problem crosses boundaries. I can change one part without rebuilding everything else.

Underneath the imagery, the machinery is ordinary: files, instructions, defined responsibilities, current work, reference material, and a way to preserve useful state.

The Personal AI Harness is the structure and the AI Campus metaphor helps me know where things are and get work done, even in the absence of an active AI model running in the system.

That is the distinction I want to keep clear. Building a Harness does not mean creating an imaginary university full of AI characters. That just happens to be the implementation that became natural for me.

In Part III, I will leave the AI Campus metaphor mostly behind and focus on what became more important as the system matured: who owns the context, what should stay private, and whether the whole thing can survive a change of AI providers.