Own the adapters ourselves rather than betting on harness maintainers
Section: Open risks, point 1 (Harness adoption)
If no harness ships an adapter, the marketplace is a publishing format with no consumers... If we cannot land at least three real harness adapters in the first year, the project does not have a path.
I don't think we should let the existential risk depend on other people showing up. I'd rather we own the adapters ourselves and ship them for Claude Code, Codex, Nanocoder and whatever else people actually use. We maintain the translation layer, so the moment someone publishes to our format they know a user can install it into their chosen agent. No permission needed from anyone.
This flips the bet. Right now the doc is hoping harness maintainers build adapters. If we own them, adoption is something we control, not something we wait for. The whitepaper already half says this, since the Claude Code adapter is described as a standalone CLI a user runs, so I want to make it the actual strategy rather than the fallback.
The pitch to authors gets cleaner too. Write once to our format and we guarantee it installs everywhere. That guarantee is the thing worth showing up for, and it means an author does zero adapter work to reach every harness.
Two things I want us to be honest about if we go this way:
- The maintenance load lands on us. Every time Claude Code or Codex changes its on disk format our adapter can break, so we need a test per harness that catches the drift early.
- We would be writing into harness config directories without the vendor's blessing, which is exactly the vendor hostility risk in point 4. Worth deciding now how we react if a vendor pushes back.
Ask: Can we commit to the collective owning the first set of adapters as the default plan, and treat harness maintainer built adapters as a bonus rather than the path? And can we name a realistic starting set, say Claude Code, Codex and Nanocoder?
Own the adapters ourselves rather than betting on harness maintainers
Section: Open risks, point 1 (Harness adoption)
I don't think we should let the existential risk depend on other people showing up. I'd rather we own the adapters ourselves and ship them for Claude Code, Codex, Nanocoder and whatever else people actually use. We maintain the translation layer, so the moment someone publishes to our format they know a user can install it into their chosen agent. No permission needed from anyone.
This flips the bet. Right now the doc is hoping harness maintainers build adapters. If we own them, adoption is something we control, not something we wait for. The whitepaper already half says this, since the Claude Code adapter is described as a standalone CLI a user runs, so I want to make it the actual strategy rather than the fallback.
The pitch to authors gets cleaner too. Write once to our format and we guarantee it installs everywhere. That guarantee is the thing worth showing up for, and it means an author does zero adapter work to reach every harness.
Two things I want us to be honest about if we go this way:
Ask: Can we commit to the collective owning the first set of adapters as the default plan, and treat harness maintainer built adapters as a bonus rather than the path? And can we name a realistic starting set, say Claude Code, Codex and Nanocoder?