Begin a piece of work in one AI client, close it, and open a fresh session in another. If you cannot recover the same decisions and the same next action without replaying the first conversation, the work lives inside a product rather than inside infrastructure you own.
The strongest AI work systems are becoming more capable and more distinct at the same time.
Codex, Claude Code, Hermes Agent, Cursor, OpenClaw, and other systems are adding tools, permissions, plugins, skills, memory, subagents, sandboxes, connectors, and new interaction surfaces. That is healthy competition. A good native client should have opinions about how work is executed and supervised.
Open infrastructure should not erase those opinions.
Its job is to preserve what should remain under the user’s control when the model, client, computer, or organization changes.
I draw that boundary around five things: project state, reusable methods, authority rules, coordination, and evidence. I described the project-state layer’s file conventions in AI-native project management; this piece is about making that whole layer, not just its files, portable and shared.
Native clients should keep getting better
There is a recurring temptation in multi-model tooling: build one interface, route every model through it, and declare the portability problem solved.
That can be a useful product. It also makes the new interface the owner of the tool model, permissions, memory, supervision, and workflow conventions.
Native clients deserve room to differ. Codex has its own plugin, hook, task, sandbox, and app-server contracts. Claude Code has its own plugin, hook, subagent, checkpoint, and permission systems. Hermes Agent combines an open multi-provider agent with skills, memory, tools, subagents, messaging surfaces, and lifecycle hooks.
The goal should not be to make each one behave like a weaker copy of the others. It should be to let a person choose among them without surrendering the durable parts of the work.
Project state should be portable
A long-running project needs more than a conversation transcript.
It needs a current statement of phase and status, stable reference facts, chronological history, a controlling plan, decision records, repository identity, and exact next actions. Those artifacts should live in a format the user can inspect, version, diff, synchronize, and open without the original client.
This is not an argument against native memory. Native memory can make a client more helpful. It is an argument against making that memory the only copy of a project’s operating state.
The practical test is a cold handoff: begin work in one client, checkpoint it, open a fresh session in another, and recover the same decisions and next action without replaying the first chat.
Methods should be portable
People develop valuable procedures while using agents: how they plan a code change, verify a claim, review a pull request, preserve a writing voice, manage context, or ship a knowledge-base edit.
Those methods should not remain prompt fragments trapped in old chats.
Agent Skills provides an open package format for
procedural knowledge. A shared SKILL.md can carry the method, while native
adapters handle client-specific presentation, activation, tools, and lifecycle
behavior.
That separation matters. One source prevents divergent copies. Native adapters avoid targeting the least capable common subset.
Portability should mean equivalent, tested outcomes, not identical paths on disk.
Authority rules should follow the principal
An agent may be able to delete files, deploy production, send a message, merge a change, or access private data. The boundary for those actions belongs to the person or organization granting authority, not to whichever client happens to be open.
Some controls belong inside the native client: sandboxing, permission prompts, managed configuration, and hook trust. The portable layer should express the standing intent and verify that each client implements it through a legitimate native mechanism.
The distinction between policy and mechanism lets clients improve their safety systems without changing the user’s governing rule.
It also requires honest limits. A lifecycle hook is a useful guardrail. It is
not automatically a complete security boundary. When a product surface cannot
enforce a policy, conformance should say UNSUPPORTED or UNKNOWN rather than
pretending that an inert adapter closes the gap.
Coordination should be portable
Persistent state solves handoff across time. It does not solve concurrent writes.
If several agents can work at once, they need explicit ownership:
- claim the files or source areas before writing;
- use isolated worktrees and branches;
- designate one owner for canonical project context;
- maintain heartbeats and lease expiry;
- record messages and handoffs durably; and
- fail closed when the shared lease cannot be reached.
Git synchronization is necessary but insufficient. Two writers can both pull a clean branch and then make incompatible decisions. Coordination requires one atomic ownership result, not merely eventual file replication.
An open coordination protocol also makes new runtimes easier to integrate. A runtime does not need access to another vendor’s conversation. It needs a way to read the same claims, acquire a non-overlapping lease, and leave a durable handoff.
Evidence should be portable
Compatibility statements decay as clients change.
A manifest can remain valid after the runtime stops reading it. An installed directory can remain after a plugin is disabled. A direct hook test can pass while a normal session receives nothing. A configured connector can lose its authentication.
An open conformance contract should preserve five distinct planes:
- source validity;
- installed version and provenance;
- live delivery;
- durable continuity and coordination; and
- authenticated capability.
The report should be machine-readable, but its semantics matter more than its
format. UNKNOWN cannot pass. UNSUPPORTED must name the product surface.
Live evidence needs provenance and expiry. Another implementation should be
able to run the same fixture and disagree with the result in an inspectable
way.
This is where a compatibility corpus can become valuable public infrastructure. Sanitized fixtures for stale caches, missing hooks, expired receipts, lease conflicts, malformed manifests, and unsafe cleanup targets give vendors and runtime authors cases they can reproduce before users discover the same failures in real work.
A contributor system should distribute ownership
An open project is not healthy merely because its source is visible.
It needs bounded ways to contribute:
- documentation and examples;
- skill methodology;
- scripts and safety fixtures;
- runtime adapters;
- onboarding and accessibility;
- translations and locale review;
- compatibility cases; and
- research and evidence.
Runtime stewardship is especially important. A maintainer for one adapter can own the evidence for that surface without needing to understand every part of the ecosystem. Shared specifications should use written decisions, reproducible fixtures, and public migration notes so participation does not depend on private conversation with a founder.
Credit should include the person who found the failure or supplied the design insight, not only the person who wrote the final patch.
Open does not mean economically unsupported
The core formats, baseline safety rules, reference implementations, and conformance suite should remain open. Their availability is the basis for trust.
Useful services can exist around that commons: organization onboarding, migration assessments, training, managed compatibility testing, enterprise connectors, governance packages, and sponsored adapter or accessibility work.
The boundary matters. Project portability and baseline safety should not become paid escape hatches. Commercial work should make the open layer easier to adopt and maintain, not make users dependent on a private path out.
The public test
Open agent infrastructure should be judged by use outside its founding environment.
Can a new user complete a clean-room install? Can an independent runtime pass a handoff? Can another maintainer add a fixture? Can a vendor reproduce a failure without receiving private project data? Can a writer or product manager reach a useful outcome without first becoming a plugin engineer?
Those tests are also the right basis for professional credibility. Useful public work is cited, challenged, adopted, and improved. Reputation follows the artifact rather than substituting for it.
The opportunity is not to build one client that wins every comparison. It is to build the open layer that makes every capable client more useful without taking ownership of the work away from the person doing it.