Portable AI Personas: Decoupling Identity from Project

The Problem

In the current paradigm, we treat AI system prompts as configuration files for a specific chat or project. This is like reinstalling your operating system every time you open a new folder.

If the LLM is the raw compute, then the instructions we provide are the harness — the identity, rules, and tools that make it useful. When I move from working on my blog to working on a systems tool like clicky, I don’t want a “new” AI. I want the same architectural rigor, the same preferences, and the same reporting structure I’ve spent months tuning.

Contextual Amnesia

Currently, AI personas are tethered to the environment they inhabit. Custom GPTs live in that UI. A local system_prompt.txt lives in that repo. When you switch projects, you lose:

1. Identity: The specific tone and persona that understands your shorthand.
2. Invariants: The hard rules (e.g., “never use placeholders,” “always run tests before committing”).
3. Tooling: The custom scripts and specialist agents that make the AI productive.

The Fix: Portable Harnesses

I’ve decoupled the harness from the project. A harness is a portable, versioned folder that can be “mounted” onto any directory. It has three layers:

1. Identity: The high-level persona and preferences.
2. Invariants: Immutable rules that don’t change regardless of the project.
3. Specialists: A registry of tools and sub-agents the harness knows how to invoke.

What This Looks Like

All persona logic now lives in ~/dotfiles/soul/harnesses/teddy-architect/v1/. A mount.sh script projects this into the Gemini CLI’s agent directory using symlinks.

Whether I’m in my blog repo or a new systems project, I run:

./mount.sh ~/dotfiles/soul/harnesses/teddy-architect/v1 teddy

And the agent is instantly active with all my preferences, rules, and tools.

Next up: how the registry knows which harness to boot for each project without needing config files in every repo.