AI coding agents are getting plugin marketplaces. Claude Code launched its ecosystem in October 2025, and six months later researchers from Queen’s University and Concordia analyzed 1,926 repositories hosting 8,351 plugins across 2,018 marketplaces. The findings expose a maintenance model that differs sharply from traditional package ecosystems like npm or PyPI.
Agent plugins are not just code. They bundle natural-language instruction files, implementation scripts, and configuration metadata. This hybrid structure creates new co-evolution patterns and maintenance burdens that traditional dependency graphs do not capture.
What Agent Plugins Actually Contain
Traditional packages ship compiled artifacts or source modules. Agent plugins ship three component types:
- Natural-language instruction files: Markdown or text files that describe what the plugin does, how the agent should invoke it, and what parameters it accepts.
- Implementation scripts: Python, JavaScript, or shell scripts that execute the actual work.
- Configuration files: JSON or YAML manifests that declare plugin metadata, dependencies, and runtime requirements.
The instruction files are not documentation. They are runtime inputs. The agent reads them to decide when and how to call the plugin. If the instruction file is stale or ambiguous, the agent will misuse the plugin even if the implementation script is correct.
Maintenance Patterns Diverge from Traditional OSS
The study analyzed 77,773 commits and classified them using conventional commit types (feat, fix, docs, refactor, style, perf). The distribution is different:
| Commit Type | Agent Plugins | Traditional OSS | Difference |
|---|---|---|---|
| feat | 39.6% | 17.2% | +22.4pp |
| fix | 18.3% | 24.1% | -5.8pp |
| docs | 14.7% | 8.9% | +5.8pp |
| refactor | 9.2% | 12.4% | -3.2pp |
| style | 6.1% | 3.7% | +2.4pp |
| perf | 4.8% | 2.1% | +2.7pp |
Feature commits occur at more than twice the rate of traditional OSS. This suggests plugin authors are iterating on capabilities rather than stabilizing existing functionality. The high documentation commit rate reflects the need to keep instruction files synchronized with implementation changes.
Four commit types carry different meanings in plugin repositories:
- docs: Often updates to instruction files that change agent behavior, not just human-readable explanations.
- perf: Frequently refers to prompt optimization (reducing token usage or improving agent reasoning), not execution speed.
- style: Includes formatting changes to instruction files that affect agent parsing.
- refactor: May involve restructuring instruction files to improve agent comprehension, not just code cleanup.
Co-Evolution Between Instructions and Implementation
The study measured co-evolution by tracking commits that touched multiple component types within a 24-hour window. Most component types evolve independently, but instruction files and implementation scripts inside skill directories co-evolve at above-chance rates.
78% of these co-changes are functionally coupled. When a plugin author modifies an implementation script, they often update the instruction file to reflect new parameters, changed behavior, or different invocation patterns. This is a new class of maintenance dependency. Traditional packages do not have runtime-consumed natural-language files that must stay synchronized with code.
The coupling creates a failure mode: instruction drift. If an author updates the implementation but forgets to update the instruction file, the agent will invoke the plugin with outdated assumptions. The plugin may fail silently, return incorrect results, or trigger unexpected side effects.
Claude as Co-Author
Claude co-authored 34.9% of all commits in the dataset. This is not a vanity metric. The agent is generating instruction files, writing implementation scripts, and updating configuration manifests. The co-authorship rate varies by commit type:
- feat: 42.1% Claude co-authored
- docs: 38.7% Claude co-authored
- fix: 29.4% Claude co-authored
- refactor: 26.8% Claude co-authored
Claude is more involved in feature development and documentation than in bug fixes or refactoring. This suggests the agent is better at generating new functionality than diagnosing and repairing existing code.
The co-authorship pattern raises a versioning question: when the agent runtime changes (new Claude model, updated reasoning engine, different prompt handling), do plugins break? The study does not measure breakage rates, but the high feature commit rate and low fix rate suggest plugin authors are not spending much time on backward compatibility.
Dependency Graphs Are Flatter
Traditional package ecosystems have deep dependency trees. A single npm package might pull in dozens of transitive dependencies. Agent plugin marketplaces are flatter. Most plugins depend on zero or one other plugin.
This is partly structural. Plugins are invoked by the agent, not by other plugins. The agent orchestrates tool calls, so plugins do not need to import or require each other. But it also reflects immaturity. The ecosystem is six months old. Shared utility plugins and common abstractions have not yet emerged.
The flat dependency graph simplifies deployment but complicates reuse. If two plugins need similar functionality (e.g., parsing a specific file format), they duplicate the implementation rather than depending on a shared library. This increases maintenance burden and creates version skew.
Versioning and API Stability
The study does not report on versioning practices, but the high feature commit rate and rapid marketplace growth (8.8x commit activity increase in six months) suggest versioning discipline is weak. Traditional package ecosystems enforce semantic versioning and deprecation cycles. Agent plugin marketplaces do not yet have these norms.
Plugin authors face a double versioning problem:
- Agent runtime changes: New Claude models, updated reasoning engines, or modified prompt handling can break existing plugins.
- Underlying tool changes: If a plugin wraps a third-party API or CLI tool, changes to that tool can break the plugin.
Traditional packages only face the second problem. Agent plugins must track both the agent runtime and the tools they wrap. This creates a co-evolution surface that is wider and less predictable than traditional dependency management.
Observability Gaps
The study does not address observability, but the plugin structure exposes several blind spots:
- Instruction file parsing errors: If the agent misinterprets an instruction file, there is no error signal. The agent simply invokes the plugin incorrectly.
- Silent failures: If a plugin returns an error code but the agent does not check it, the failure is invisible.
- Token budget exhaustion: If instruction files are too verbose, the agent may truncate them or skip plugins entirely.
Traditional packages fail loudly. Import errors, type mismatches, and runtime exceptions are visible. Agent plugins can fail silently because the agent is the interpreter. If the agent misunderstands the instruction file, the plugin author has no way to detect it without manual testing.
Security Boundaries
The study does not analyze security, but the plugin model creates new attack surfaces:
- Instruction injection: A malicious plugin could include instruction text that tricks the agent into invoking other plugins or leaking data.
- Privilege escalation: If plugins run with the same permissions as the agent, a compromised plugin can access all agent capabilities.
- Supply chain attacks: If a plugin depends on an external tool or API, an attacker who compromises that dependency can inject malicious behavior.
Traditional package ecosystems have these problems, but agent plugins add a new vector: natural-language instructions. An attacker can craft instruction files that exploit the agent’s reasoning process, not just the implementation code.
Deployment Shape
The study analyzed GitHub repositories, so the deployment model is implicit. Most plugins are distributed as source code, not compiled artifacts. The agent clones the repository, reads the instruction files, and executes the implementation scripts.
This creates a deployment dependency: the agent must have access to the plugin repository at runtime. If the repository is private, the agent needs credentials. If the repository is deleted or renamed, the plugin breaks. Traditional package managers cache artifacts in registries (npm, PyPI, crates.io). Agent plugin marketplaces do not yet have this infrastructure.
The lack of a central registry also complicates discovery. Plugin authors publish to GitHub, but there is no canonical index. Users must search GitHub or rely on curated lists. This slows adoption and fragments the ecosystem.
Likely Failure Modes
The study exposes several failure modes that are unique to agent plugin marketplaces:
- Instruction drift: Implementation changes without corresponding instruction file updates.
- Agent runtime breakage: New Claude models or reasoning engines break existing plugins.
- Silent invocation errors: The agent misinterprets instruction files and invokes plugins incorrectly.
- Token budget exhaustion: Verbose instruction files cause the agent to truncate or skip plugins.
- Dependency skew: Plugins duplicate functionality instead of depending on shared libraries.
Traditional package ecosystems have well-known failure modes (dependency hell, version conflicts, breaking changes). Agent plugin marketplaces add new failure modes that stem from the hybrid structure of natural-language instructions and executable code.
Technical Verdict
Use agent plugin marketplaces if you are building a coding agent that needs extensibility and you are willing to accept high maintenance burden. The ecosystem is immature. Versioning discipline is weak. Observability is poor. Security boundaries are unclear.
Avoid agent plugin marketplaces if you need stability, backward compatibility, or predictable dependency management. The co-evolution surface is wide. The agent runtime is evolving rapidly. Plugins break silently.
If you are building plugins, invest in instruction file maintenance. Keep instruction files synchronized with implementation changes. Test plugin invocation manually because automated testing tools do not yet exist. Expect to rewrite plugins when the agent runtime changes.
If you are building an agent runtime, consider adding a central registry, versioning enforcement, and observability hooks. The current model (GitHub repositories with no caching or indexing) will not scale.