A technical follow-up on agent-harness: why reusable AI-agent assets need discovery, staging, activation, and host-aware wiring instead of one giant context bundle — and where I need feature suggestions, issues, tickets, and PRs from real users.
I recently shipped agent-harness v1.0.0.
It is a Node.js / TypeScript CLI for discovering, staging, activating, and wiring reusable AI-agent assets across VS Code / GitHub Copilot, Cursor, OpenCode, Zed, Claude Code, and Pi.
The first announcement explained what it is.
This follow-up is about the design problem behind it — and why I am looking for more than page views or stars.
I want criticism, feature suggestions, issue reports, tickets, and code contributions from people who actually use AI coding tools in real projects.
The problem is not “more context”
A lot of AI coding workflows drift toward the same pattern:
- collect more prompts
- collect more skills
- collect more examples
- collect more MCP configs
- collect more instructions
- put them somewhere the model can see
That can be useful, but it has a cost.
Context is not free. Even when the tokens are technically available, attention is still scarce. Irrelevant instructions compete with useful ones. Tool-specific assumptions leak into repos where they do not belong. Old experiments stick around because removing them is less obvious than adding another file.
At some point, the workflow stops feeling like “better assistance” and starts feeling like a context landfill.
The question I wanted to explore was:
How do you make useful agent assets portable across projects and tools without dragging everything into every workspace?
That question became agent-harness.
Why a lifecycle?
The core idea in agent-harness is that reusable agent assets should move through a lifecycle:
- discover
- mirror / stage
- install
- activate
- wire
That may sound like extra ceremony. In some cases, it probably is.
But the lifecycle exists because “available somewhere” and “active in this repo right now” are very different states.
A skill, instruction, prompt pack, MCP server, or workflow might be useful in general but wrong for a specific repo. It might be relevant to a frontend project but noise in a backend service. It might be useful for Cursor but not for Claude Code. It might be safe to stage but not safe to activate automatically.
A lifecycle gives the system places to make those distinctions.
Discovery should not mean activation
One of the mistakes I wanted to avoid was treating discovery as permission to inject context.
Discovery should answer:
What might be relevant?
Activation should answer:
What should actually be active here?
Those are not the same question.
If a project looks like a Flutter app, it may be reasonable to discover mobile, Android, Firebase, testing, and UI-related assets. But that does not mean every vaguely mobile-related asset should be wired into the editor context.
The tighter the activation boundary, the less likely the system is to bloat the workspace with clever-but-irrelevant material.
Host-aware wiring matters
Different AI coding hosts expose different surfaces.
VS Code / GitHub Copilot, Cursor, OpenCode, Zed, Claude Code, and Pi do not all consume project instructions, prompts, tools, and local assets in the same way.
Pretending they are the same usually produces either:
- a lowest-common-denominator setup that wastes host-specific strengths, or
- a messy pile of adapters hidden behind vague “it works everywhere” claims
agent-harness leans into host differences instead. It tries to keep assets reusable while still wiring them through the surfaces each host actually supports.
That is the bet, at least.
It may turn out that the abstraction is too complex. That is exactly the kind of feedback I want.
The uncomfortable part: this started vibe-coded
This project was mostly vibe-coded at the start.
I think that matters to say plainly.
The good part is that it came from real workflow pain and moved quickly. The bad part is that vibe-coded systems can easily grow accidental abstractions that make sense only to the person building them.
So after the initial build, I pushed it through a stricter phase:
- release audits
- real workspace testing
- Windows validation
- issue-driven cleanup
- host adapter tightening
- docs and changelog cleanup
- release workflow hardening
The result is more disciplined than the prototype, but I still do not want to assume the idea is automatically good.
What I want from other developers
I am not looking for generic praise on this one.
I am looking for validation or invalidation.
Useful feedback would be things like:
- “this should be much smaller”
- “this host should not be supported”
- “this lifecycle is unnecessary ceremony”
- “this should just be config files”
- “this breaks in my repo because…”
- “the restrained alternative framing does / does not hold up”
I would also really value concrete contribution paths:
- feature suggestions for missing lifecycle steps or host surfaces
- issues/tickets for rough edges, unclear docs, or broken assumptions
- PRs that improve host adapters, discovery sources, tests, docs, or examples
- small reproducible fixtures from real projects where the selection logic gets it wrong
- examples of workflows this should support, but currently does not
If you try it, the most useful thing you can do is open an issue or discussion with:
- repo type / stack
- host used
- OS
- what you expected
- what actually happened
- what felt confusing or unnecessary
- whether the core idea seems useful or wrong
- what feature or simplification would you want next
Links:
If the idea is wrong, I would rather learn that early.
If the idea is useful but incomplete, I would love help shaping it through issues, feature requests, and PRs.