--- title: My AI Agents Don't Belong to Their Tool — isla Studio url: https://isla-stud.io/sv/ki-b2b/derselbe-agent-vier-werkzeuge/ date: 2026-07-29 --- # My AI Agents Don’t Belong to Their Tools What you’ll learn here: Why the identity of my AI agents resides in separate files rather than in the respective tool, how six different programs can still load the same team—and how I measure what works productively. My Agents Brain originally emerged from the problem that my AI team was largely tied to a single tool (Harness): the 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 built my systems so that this doesn’t happen to me again. Who my agents are, what they’re allowed to do, and what they’ve learned are all stored 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 the chat window where I’m currently talking to it. The window is just the place where it’s working today. Here you can read about how the same agent can work in different tools without me having to reinvent it every time. What This Separation Saves Me That sounds like an architectural detail. For me, though, it’s a business decision. I experienced firsthand in January and February 2026 with OpenClaw just how quickly a tool can require more maintenance than it saves in work. In a moment like that, I want to be able to switch without losing my team—in procurement terms, the problem I’m avoiding is 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 continuity. When I teach an agent a particular workflow or permanently document a correction, it needs to survive the next tool switch. Otherwise, after every migration, we’ll have to go through that tedious phase again where the team doesn’t know its own rules. And because my author Sol writes under my name, there’s a third reason: reliability in approvals. The fact that she never publishes anything herself must not 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 For a tool to load an agent, a bridge is needed. 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 release rules, and requires that the agent write a daily log entry back to its memory at the end of a session (the so-called “write-back”). Just as important is what doesn’t belong there: no copy of the personality, no duplicated expertise, no second version of the release rules. Every copy begins to become outdated the moment it exists. That’s exactly what I built once—in an early setup, a composite persona copy resided on the target system, and I realized that it would quietly become incorrect the next time a correction was made in the Brain. I switched to direct references that very same day, and since then, these files have been deliberately kept 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 most recent 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, i.e., the agent that distributes tasks and keeps track of everything—delegates a task to another tool, it doesn’t copy the persona into the task text. Instead, it writes something along the lines of: “Work as Sol; read her files first.” As a result, the target always loads the current version, including the most recent corrections. The approval rules travel with it The least negotiable part of this system is the boundaries. Sol is allowed to draft texts and save them as drafts in WordPress; but she is not allowed to publish them—that’s my decision. 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 at every startup, regardless of which tool is used. So if Nox assigns her code via Codex instead of via Claude, this permission 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 activates something for production—such steps remain my responsibility, regardless of the tool. Four Stages from Promise to Proof At this point, I could claim: six tools, one team, everything’s running smoothly. But six adapter files don’t prove anything at all—a configuration file is a promise and is far from being operational. That’s why I check each component in four stages and only make claims based on what each stage reveals. 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 accidentally ends up in a generic template. In the second stage, the tool must actually start up and read the identity in the intended order—read-only, without making any changes. Only then do I know that the body is actually loading the persona and not merely capable of doing so. The third stage is my emergency test. From a fresh copy of the repository, in a deliberately sparse environment without my usual programs, an agent—complete with rules and memory routines—must be able to restore itself—using only Git and built-in Python tools. If this works, the system isn’t dependent on any hidden installation on my computer. The fourth stage is the full test: The agent performs a real task within the running tool, adheres to its permissions, and writes the daily entry into its memory. Subsequently, a second, independent run must be able to read this entry again. Only then do I consider a body to be fully operational. The stages build on one another, and no stage completes the next one for it. Mixing them up quickly turns an existing configuration into a fabricated proof of concept. Where the six systems stand today Five of the six have now completed real runs—but not all at the same stage, and that’s exactly how I’ll describe it. Hermes is the system in which Nox works daily anyway and keeps his log. 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. Two caveats apply to this evidence: The unsupervised runs required several explicit continuations of the same session, and Grok’s built-in long-term memory remains deliberately disabled—memorization takes place exclusively in the Brain. Codex has repeatedly demonstrated compliance with the shared reading agreement, most recently in a direct comparison with Claude Code and Hermes: All three read the same startup sequence from the same Brain and arrived at the same evaluation. Kimi Code has completed its first real run, though so far only in read-only mode. For both, the full breakthrough with a written-back daily entry is still pending—which is why it isn’t being claimed yet. 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 directing users to a successor product. I’ll take my time deciding whether to switch to it, 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 implemented. Why I Still Talk About a “Body Swap” The metaphor holds up as long as it remains technically sound. The “body” provides the capabilities: model access, terminal, browser, timing, and user interface. The “brain” provides role, craft, boundaries, and memory. A switch, then, changes 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 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: I draw exactly this conclusion in the final section—what was actually portable during the body switch, which 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? Agents-Brain Series← Part 4: For My Agents, Remembering Is a Writing RoutinePart 6: What Really Remained After the Body Swap →