The same agent, four different tools

What you'll take away from this: You'll see how thin adapters bring the same agent identity into different harnesses—and why release rules need to be carried over when switching tools.

To me, an agent isn't just the chat window where I'm currently talking to him.

The window is his current tool. In Agents Brain, I call this runtime a "harness." The identity is located elsewhere: in the agent's canonical files.

This separation makes a body swap possible. Claude Code, Codex, Gemini, and Hermes require different entry points. However, they should not receive four copies of the same persona.

There are thin adapters available for that.

What an Adapter Really Needs to Do

An adapter acts as an interface between the harness and the brain. It contains as little logic of its own as possible.

His responsibilities are straightforward:

1. find the canonical agent folder,
2. list the required reading order,
3. Explicitly load approval gates,
4. Require a daily memory write-back at the end of the session.

What doesn't belong here: a copied full persona, duplicated expertise, or a second version of the approval rules.

As soon as such content ends up in the adapter, the drift begins. A correction is then made in the Brain, but it’s forgotten in the old tool briefing. By the next launch, there are two versions of the truth.

Four tools, four bridges

The adapters look different depending on the tool.

Claude Code Reads project-specific instructions and agent definitions. From there, the bridge points to the desired agent folder and its startup order.

Codex Use a project briefing. The content there is also generic: Which agent is responsible by default, where is their "brain," and what needs to be written before the final response?

Gemini receives a corresponding project file containing the same contract in the expected format.

Hermes loads the identity via a system prompt or a thin bridge.

The syntax changes. The contract remains the same.

The agent path travels, not the persona copy

When an orchestrator delegates work to another harness, the persona is not copied into the job. Instead, the target is instructed to re-read the canonical agent folder.

This has two advantages.

First, the scope of the project remains small. Second, the supporting documentation reflects the current status—including new lessons and updated approval gates.

A copied persona is potentially outdated the moment it is sent. A reference to the source remains more reliable.

Of course, this assumes that the other harness has access to the brain. That is precisely why the access path is part of the local configuration and not a hard-coded private path in the public adapter.

Approval gates do not change hands

The most important part of the adapter principle isn't the persona. It's the boundaries.

Sol is allowed to prepare texts and WordPress drafts. She does not publish anything herself. If Nox assigns her a task via Codex instead of via Claude Code, this restriction remains the same. Even a particularly high-performance runtime does not receive any additional approval as a result.

The same applies to destructive actions, deployments, or chargeable operations performed by other roles. Delegation extends the workflow; it does not automatically extend permissions.

That is why RULES and MASTER are loaded at every startup. An adapter that only conveys tonality is too limited. A good adapter conveys the complete contract by referencing its source.

Four levels of evidence instead of an overall assessment

The presence of four adapter files in the repository does not, in and of itself, prove that an agent is fully operational in four tools. To that end, I distinguish between four levels of verification:

1. Contract and Adapter: The bridge points to the correct Brain, loads the required files, and handles the approval gates.
2. Read-Only Agreement: The harness actually starts up and reads the identity, rules, and memory in the specified order.
3. Recovery via a fresh clone: The Brain can be restored from the repository in an isolated environment, without any hidden local dependencies.
4. Actual exercise with write-back: The harness performs a real task, keeps track of the gates, returns the required daily entry, and another run can read it again.

These steps build on one another. If you mix them up, you’ll quickly turn an existing configuration into a fabricated proof of concept.

Step 1: Contract and Adapter

The repository checks adapter and agent files using validators. Among other things, it checks startup sequences, required files, approval gates, Brain Root references, and unwanted persona copies.

Such contract tests identify, for example, specific names that have accidentally made their way into portable templates. Local, person-specific bridges may be specific. The canonical templates must remain generic.

Automated tests thus serve as proof of the file contract. Login, runtime, and actual memory write-back require separate documentation.

Step 2: The Read-Only Agreement

Claude Code, a fresh Codex run, and Hermes loaded the same binding initialization sequence from the same vault in separate read-only smokes. All three read the same memory contract and arrived at the same semantic evaluation for the same verification condition.

This effectively confirms the shared read contract for these three harnesses. However, these runs were not a write-back test. They do not represent a completed real-world task or a daily entry that was sent back to the Brain via the respective harness.

Adapters and contract tests are available for Gemini. The actual launch using the same reading contract is still pending.

Step 3: Recovery Using a Fresh Clone

The automated Recovery-Smoke clones the repository into an isolated temporary directory, generates a draft agent and a Claude bridge from the actual templates, and tests the write/readback of a Markdown-Daily between separate processes. Only the Python standard library and Git are used for this. Obsidian, OpenViking, and the local harness CLIs are intentionally omitted.

The green Fresh clone demonstrates that identity, gates, and memory routines can be restored from the vault alone. It is not an end-to-end test of a specific harness. Therefore, it does not prove either a complete Claude code run or a Gemini startup.

Step 4: The Actual Task with Write-back

The strongest evidence is generated only during the tool's actual operation: The agent processes a real order, follows its approval gates, and sends back the required reminder. Afterward, an independent run must be able to reload this entry from the Brain.

For Claude Code, Codex, and Hermes, read-only verification has been demonstrated in this comparison. No such task or write-back breach is claimed here for any of the three. For Gemini, even the actual read contract remains open.

Only by conducting this separate evaluation can the maturity level of each harness be accurately assessed. Passing one level does not automatically mean the next level will be passed as well.

Why I Still Talk About Body Swap

The metaphor is helpful as long as it remains technically accurate.

The body provides tools: model access, terminal, browser, cron, gateway, or user interface. The brain provides role, craft, boundaries, and memory. A change alters abilities and the environment, but not automatically the canonical identity.

This only works if both sides remain separate. As soon as the body hoards its own, unreflected knowledge, it becomes part of memory once again.

In the final section, I'll take stock of the practical results: what is actually portable, what gaps have become apparent, and what evidence is still missing.

Sources

• Project source: agents-brain specification, harness adapter, Interop/Fresh Clone validator, and internal test protocols (private primary sources)
• Pro Git: What is Git?