@[Mehadi Hasan] agent-compat protects one manifest at a time. It won't stop drift across a whole org by itself.
What holds up in a big monorepo:
registry.ts builds a Map from builtInAdapters at module load time, before you call anything registry . So the moment you `import { Agents } from "@jstn-sdk/agents`", all 41 vendor adapters are already registered in memory. You don't configure vendors one by one.
this is not a runtime, it's a library. You import it, the adapter registry is already populated, and detect()/compile() work against whatever vendor environment sits in the project directory. The plug-and-play part is real; the "100+ vendors" number just needs correcting to 41.
before end of my reply, this is currently early-stage development if you encounter not properly working or doesn't meet the expectations, anyone can open a issues or pr. I'm reading each feedback manually.
@[nouman] The capabilities object on each adapter does have a project Config boolean flag, so the schema anticipates a difference between project-level and other config scopes, but the current adapters only compile to project-local files. If your workflow depends on global-scope Claude config or .env-based settings, that's outside what compile()/detect() currently touch.
It's not a bad idea but for me, each api's file is a little different, my codex file and claude.md have somewhat different rules since their models do different things and have different issues I fix in those files. I have an agents github project that gives a UI to multiple agents and manages files etc, https://www.autolearningagents.com/ which has its own compile / docker install, I guess keeping them in sync is a benefit but I'm not seeing the connection between compiling and validating them, other than hand reading them to make sure all their rules are right, so could you expand on the use case? Like is this mainly for machines with multiple claude / codex installs and/or for one developer?
@[AIAppsAPI] it doesn't try to make one rule automatically fit Codex and Claude differently. It writes the same instructions into each tool's own file format, so you don't have to copy-paste and reformat by hand every time.
If Codex and Claude truly need different rules, this tool won't write those different rules for you. You'd still write them yourself, just in separate manifests.
What validate() does is check that the file looks right for that tool, like the right headers or structure, not whether the rule itself is good advice for that model 1 .
So think of it like a template printer, not a translator. It saves you from manually formatting the same message five different ways. It doesn't decide what each vendor needs on its own 2 .
Treating agent configuration as compilable source is the right framing. The "one source of truth, multiple native outputs" pattern is exactly how successful infrastructure standards evolve—it's the same logic that made Terraform work across cloud providers.
The drift problem you're solving is real. I've covered enterprise teams managing multiple agentic coding tools, and configuration drift between environments is a constant operational headache. When Cursor rules and Claude Code instructions diverge because someone updated one and not the other, you get inconsistent agent behavior that's hard to debug because nobody suspects the config layer first.
Your validate() step is the piece most similar tools skip. Compiling to native formats is only half the problem—confirming those outputs actually satisfy each platform's spec is what prevents silent failures.
On your questions: generated native files over runtime resolution, for one clear reason—agent behavior needs to be inspectable and versionable in git without requiring the resolution layer to be present or correct at runtime. Debugging "what instructions did the agent actually receive" should never depend on a live compilation step.
For an adapter ecosystem to be useful, the registry needs to handle partial spec compliance gracefully (your "◐" status is a good start) rather than treating every target as binary pass/fail—agent platforms are evolving fast enough that partial support will be the normal state, not the exception.
@[Tom Smith] Thanks, this matches how it actually works.
Drift is handled by the managed-block markers, compile only touches the generated section, so Cursor and Claude stay in sync without manual updates shared . Validate is the separate check that confirms output matches each target's spec, beyond what compile enforces at write time like byte limits compile .
Files over runtime resolution is accurate too, detect and compile are the only filesystem touches, both run once, no live process needed to inspect output detect . And partial compliance is already the default state, not a future fix: 6 of 41 adapters are native, 35 are portable, and the ◐ status reflects that support-matrix. .
One caveat: "single source of truth" means one set of instructions reformatted per vendor, not different content per vendor. If your rules truly diverge by tool, that part still needs manual authoring.
I like the compiler analogy here. Treating the canonical manifest as source and the Cursor/Codex/Pi representations as compiled artifacts seems much cleaner than allowing each environment to become an independently maintained source of truth.
One thing I'd add is provenance between the canonical manifest and the generated artifact. Validation can establish that AGENTS.md is valid Codex configuration, for example, but that's different from establishing that it was generated from manifest v7 using adapter v3 and hasn't subsequently been modified.
That distinction becomes important because structurally valid isn't necessarily authorized. Someone could manually change a generated agent rule and leave it perfectly conformant with the target specification. validate() might still pass while governance has failed because the deployed artifact no longer represents the canonical instructions.
I'd be tempted to have compilation produce both the native configuration and evidence tying it back to its authority: source manifest identity/hash, adapter/version, generated artifact hash, compilation timestamp, and validation result. CI could then detect not only invalid configuration but unauthorized drift between canonical source and deployed artifact.
And once those instructions govern consequential agent behavior, there's another question: not just “what configuration is valid now?” but “which authorized instruction set actually governed this agent when it took that action?”
At that point, agent configuration starts looking less like a collection of dotfiles and more like a versioned governance artifact with compiled target representations. I think that's a really interesting direction.
Contribute meaningful comments to climb the leaderboard and earn badges!