{"id":3903,"date":"2026-07-29T07:45:00","date_gmt":"2026-07-29T05:45:00","guid":{"rendered":"https:\/\/isla-stud.io\/?p=3903"},"modified":"2026-08-15T00:29:22","modified_gmt":"2026-08-14T22:29:22","slug":"the-same-agent-four-tools","status":"publish","type":"post","link":"https:\/\/isla-stud.io\/en\/ki-b2b\/derselbe-agent-vier-werkzeuge\/","title":{"rendered":"My AI agents do not belong to their tool"},"content":{"rendered":"

What you'll take away from this:<\/strong> 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\u2014and how I determine which of these approaches actually works effectively.<\/p>\n\n\n\n

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\u2019 Markdown files\u2014everything else I had to rebuild from scratch.<\/p>\n\n\n\n

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\u2014experts call this runtime environment a \u201charness,\u201d but I usually just say: its current body.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

What This Breakup Saves Me From<\/h2>\n\n\n\n

That sounds like an architectural detail. To me, though, it's a business decision.<\/p>\n\n\n\n

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\u2014in procurement, the problem I\u2019m avoiding is called vendor lock-in. My agents aren\u2019t tied to any single provider because nothing essential exists exclusively in that provider\u2019s product.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

And because my author, Sol, writes under my name, there\u2019s a third reason: reliability when it comes to approvals. The fact that she never publishes anything herself shouldn\u2019t depend on which tool she\u2019s using today. More on that in a moment.<\/p>\n\n\n\n

A small file tells the tool where the agent is located<\/h2>\n\n\n\n

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\u2019s folder in Brain\u2014the private Git repository where all these files are version-controlled\u2014 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 \u201cwrite-back\u201d).<\/p>\n\n\n\n

Just as important is what shouldn\u2019t 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\u2019s exactly what I built once\u2014in 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\u2019ve deliberately kept these files small.<\/p>\n\n\n\n

Six Bridges to the Same Brain<\/h2>\n\n\n\n

There are now such bridges for six tools. Claude Code from Anthropic reads project-specific instructions, including agent definitions. Codex\u2014the command-line tool from OpenAI\u2019s ChatGPT ecosystem\u2014receives 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\u2014the two newest additions\u2014each come with their own agent formats.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

My agents pass work to one another using the same principle. When Nox\u2014my orchestrator, that is, the agent that assigns tasks and keeps track of everything\u2014delegates a task to another tool, it does not copy the persona into the task text. Instead, it essentially writes: \u201cWork as Sol; read her files first.\u201d This ensures that the target always loads the most current version, including the latest corrections.<\/p>\n\n\n\n

The approval rules come along for the ride<\/h2>\n\n\n\n

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\u2014that\u2019s up to me. This rule is specified in her own agent files\u2014in RULES, her employment contract detailing her capabilities and permissions, and in MASTER, her comprehensive manual\u2014and both are loaded every time she starts up, regardless of which tool is used.<\/p>\n\n\n\n

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

Four Steps from Promise to Proof<\/h2>\n\n\n\n

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

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.<\/p>\n\n\n\n

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

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\u2014complete with rules and memory routines\u2014using only Git and Python\u2019s built-in tools. If this works, the system isn\u2019t dependent on any hidden installation on my computer.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

The steps build on one another, and no single step completes the next one. If you mix them up, you\u2019ll quickly turn an existing configuration into a fabricated proof of concept.<\/p>\n\n\n\n

Where the six bodies are today<\/h2>\n\n\n\n

Five of the six have now completed real runs\u2014but not all at the same level, and that\u2019s exactly how I\u2019d 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\u2019s built-in long-term memory remains deliberately disabled\u2014memory is stored exclusively in the Brain.<\/p>\n\n\n\n

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\u2014which is why this claim is not being made.<\/p>\n\n\n\n

That leaves Gemini. The bridge has been built and passes all contract tests, but there hasn\u2019t been a real run yet\u2014and that\u2019s no longer due to my setup: Google has discontinued free access to this tool and is pointing users to a successor product. I\u2019ll 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\u2014prepared, but not in use.<\/p>\n\n\n\n

Why I Still Talk About Body Swap<\/h2>\n\n\n\n

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\u2014not who it is.<\/p>\n\n\n\n

This only works as long as both sides remain separate. As soon as a body begins to hoard its own knowledge\u2014knowledge that isn't reflected anywhere else\u2014it becomes part of the memory again\u2014and I, in turn, become dependent on a single tool.<\/p>\n\n\n\n

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\u2014what was actually transferable when switching devices, what gaps became apparent, and what evidence is still missing.<\/p>\n\n\n\n

Sources<\/h3>\n\n\n\n