My AI agents do not belong to their tool

What you'll take away from this: Why the identities of my AI agents are stored in separate files rather than within the respective tools, how six different programs can still load the same team—and how I determine which of these approaches actually works effectively.

My Agents Brain originally arose from the problem that my AI team was largely tied to a single tool (Harness): ongoing orchestration, channels, and established automations. I was able to keep my agents’ Markdown files—everything else I had to rebuild from scratch.

Since then, I've been building my systems in a way that ensures this won't happen to me again. Who my agents are, what they're allowed to do, and what they've learned is all documented in files that, first of all, belong to me, and second, allow me to track any changes made to them. The program in which an agent is currently running, on the other hand, is interchangeable—experts call this runtime environment a “harness,” but I usually just say: its current body.

An agent isn't just the chat window where I'm currently talking to it. That window is just the place where it's working today. Here, you'll learn how the same agent can work across different tools without me having to reinvent it every time.

What This Breakup Saves Me From

That sounds like an architectural detail. To me, though, it's a business decision.

I saw firsthand just how quickly a tool can end up requiring more maintenance than it saves in work while working with OpenClaw in January and February 2026. In a situation like that, I want to be able to switch without losing my team—in procurement, the problem I’m avoiding is called vendor lock-in. My agents aren’t tied to any single provider because nothing essential exists exclusively in that provider’s product.

Then there's the issue of continuity. When I teach an agent a particular way of working or implement a permanent change, it needs to survive the next transition. Otherwise, every time we move, we'll be back to that tedious phase where the team doesn't know its own rules.

And because my author, Sol, writes under my name, there’s a third reason: reliability when it comes to approvals. The fact that she never publishes anything herself shouldn’t depend on which tool she’s using today. More on that in a moment.

A small file tells the tool where the agent is located

A bridge is required for a tool to load an agent. In my case, this is a small configuration file called the adapter: It points to the agent’s folder in Brain—the private Git repository where all these files are version-controlled— specifies the read order for startup, explicitly loads the sharing rules, and requires that the agent write a daily entry back to its memory at the end of a session (the so-called “write-back”).

Just as important is what shouldn’t be included: no copy of the personality, no duplicated expertise, no second version of the approval rules. Any copy begins to become outdated the moment it exists. That’s exactly what I built once—in an early setup, a composite persona copy was stored on the target system, and I realized that it would still be incorrect in the Brain the next time a correction was made. I switched to direct references that very same day, and since then, I’ve deliberately kept these files small.

Six Bridges to the Same Brain

There are now such bridges for six tools. Claude Code from Anthropic reads project-specific instructions, including agent definitions. Codex—the command-line tool from OpenAI’s ChatGPT ecosystem—receives a project briefing. Google Gemini expects its own project file, and Hermes from Nous Research loads the identity via a system prompt. Kimi Code from Moonshot AI and Grok Build from xAI—the two newest additions—each come with their own agent formats.

Six formats, six different syntaxes. In terms of content, however, they all say the same thing: where the agent is located, what to read at startup, which permissions apply, and what is written back at the end.

My agents pass work to one another using the same principle. When Nox—my orchestrator, that is, the agent that assigns tasks and keeps track of everything—delegates a task to another tool, it does not copy the persona into the task text. Instead, it essentially writes: “Work as Sol; read her files first.” This ensures that the target always loads the most current version, including the latest corrections.

The approval rules come along for the ride

The least negotiable part of this system is the boundaries. Sol is allowed to draft texts and save them as drafts in WordPress; she is not allowed to publish them—that’s up to me. This rule is specified in her own agent files—in RULES, her employment contract detailing her capabilities and permissions, and in MASTER, her comprehensive manual—and both are loaded every time she starts up, regardless of which tool is used.

So if Nox assigns her via Codex instead of via Claude Code, this approval remains unchanged. Even the most powerful tool doesn’t gain additional rights just because it can do more: a longer chain of delegation doesn’t turn an author into an editor. The same applies to anything that costs money, deletes something, or makes something live—such actions remain my responsibility, regardless of the tool.

Four Steps from Promise to Proof

At this point, I could say: six tools, one team, everything’s running smoothly. But six adapter files don’t prove anything on their own—a configuration file is a promise, but it’s far from being up and running. That’s why I test each object in four stages and only make claims based on what each stage yields.

First, automated test scripts check the status of the files. Does the bridge point to the correct Brain? Does it load the required files? Are the approval rules included? These tests also catch minor issues, such as when a specific name is accidentally included in a generic template.

In the second step, the tool must actually start up and read the identity in the specified order—reading only, without making any changes. Only then will I know that the system is actually loading the persona and not just potentially loading it.

The third step is my emergency test. Starting from a fresh copy of the repository, in a deliberately sparse environment without my usual programs, it must be possible to restore an agent—complete with rules and memory routines—using only Git and Python’s built-in tools. If this works, the system isn’t dependent on any hidden installation on my computer.

The fourth stage is full execution: The agent performs a real task while the tool is running, adheres to its approvals, and stores the daily entry in its memory. Subsequently, a second, independent run must be able to read this entry again. Only then do I consider a system to be fully operational.

The steps build on one another, and no single step completes the next one. If you mix them up, you’ll quickly turn an existing configuration into a fabricated proof of concept.

Where the six bodies are today

Five of the six have now completed real runs—but not all at the same level, and that’s exactly how I’d put it. Hermes is the body in which Nox works every day anyway and keeps his diary. Claude Code has passed the full test: completed a real task, met deadlines, written a daily entry, and reviewed it independently. Grok Build, the newest addition, has now also passed the same test. There are two caveats to this record: The unsupervised runs required several explicit continuations of the same session, and Grok’s built-in long-term memory remains deliberately disabled—memory is stored exclusively in the Brain.

Codex has repeatedly demonstrated the shared reading agreement in real-world tests, most recently in a direct comparison with Claude Code and Hermes: All three read the same opening sequence from the same Brain and arrived at the same analysis. Kimi Code has completed its first real run, though so far it has only been reading. For both, the full run with a written-back daily log entry is still pending—which is why this claim is not being made.

That leaves Gemini. The bridge has been built and passes all contract tests, but there hasn’t been a real run yet—and that’s no longer due to my setup: Google has discontinued free access to this tool and is pointing users to a successor product. I’ll take my time deciding whether to switch to that, get a paid subscription, or put Gemini on hold for now. Until then, Gemini remains on my list as what it is—prepared, but not in use.

Why I Still Talk About Body Swap

The metaphor holds true as long as it remains technically sound. The body provides the capabilities: model access, terminal, browser, timing, and user interface. The brain provides role, skill, boundaries, and memory. A change, therefore, alters what an agent can do and where it works—not who it is.

This only works as long as both sides remain separate. As soon as a body begins to hoard its own knowledge—knowledge that isn't reflected anywhere else—it becomes part of the memory again—and I, in turn, become dependent on a single tool.

If you're wondering whether this effort is worth it in everyday life: That's exactly what I'll be assessing in the final section—what was actually transferable when switching devices, what gaps became apparent, and what evidence is still missing.

Sources

• Project source: agents-brain specification, six harness adapters, Interop and Fresh-Clone test scripts, and internal runtime logs (private primary sources)
• Pro Git: What is Git?