An Agent Marketplace Solves Distribution, Not Adoption

More than once, I've found out that a plugin that worked for me wasn't being used by someone else in the team. The cause was their local setup, the way they used their agents, or the plugin was not providing value for them.

The plugin was installed. It just wasn't live.

I've written two articles about the technical side: how I package agents and skills as a Claude Code marketplace, and how the same source now runs in Copilot CLI and Codex. That turned out to be the easier half.

The marketplace answers one question

A marketplace answers "how do we get this capability to every developer?" It handles the distribution of agents, skills and workflows for code review, testing and releases.

It does not answer "will people use it, trust what it returns, and come back to it next week?" Every developer still decides whether to invoke a skill, and whether to act on its output.

Having a workflow that works for me is a starting point. Helping other developers find it, judge its output and keep using it is a different job. These are the six questions I'd focus on.

1. Can developers find the right capability when they need it?

A catalogue lists what exists. It doesn't tell anyone which entry to reach for in the middle of a task.

Each capability needs examples of when it helps, written against the kind of work the team actually does. People also need practice deciding what to delegate and what to inspect. That is a judgment, not a lookup.

I'd make it part of onboarding, and use real work from the team rather than demo repositories.

2. Does it solve a problem they already care about?

"Our new agent platform" is a hard sell. "This catches what you keep missing before review" is not.

I'd start with one recurring pain, like preparing a change for review or checking a release. Show how the workflow handles that task. Then give people something useful to try on their next piece of work.

Capability first, platform second. The platform becomes visible through what it does.

3. Does each project get the capabilities it needs?

In my own setup, about five plugins come into every project. The rest depend on the stack and the work.

At team scale, that selection matters more, not less. A mobile project and a backend project need different things. Installing everything for everyone means more noise in the context, more tools for the agent to choose between, and instructions that don't apply. Each of those costs trust in the capabilities that do apply.

So the marketplace is a catalogue to compose from, not a bundle. Someone has to help each project maintain its selection.

4. Who keeps each capability useful?

Once more than one person contributes, the capability layer is software. It needs owners, validation and ongoing maintenance like any other code.

As contributions grow, overlap follows: two review workflows solving the same problem slightly differently. Someone has to merge them, and retire the ones nobody maintains anymore.

Updates have their own gap. In the previous article, Codex copied installed plugins into a versioned cache, so rebuilding the source changed nothing for anyone who had already installed it. "We fixed the skill" and "everyone runs the fixed skill" are two different statements.

5. Do we know whether people get value from it?

Install counts are easy to collect and say almost nothing. A marketplace can be installed everywhere while its capabilities sit unused.

Installation is not adoption. For a review workflow, I'd want to know whether developers return to it, which findings they fix, and which they dismiss as false positives.

The chain worth following runs past the agent run itself:

invoked → output acted on → pull request → merged → outcome later

Each false positive is a small reason to stop running the reviewer. That feedback should guide what we improve next.

6. Do we hear about the problems that stop people using it?

This is where I started. The plugin worked for me. For someone else it didn't, and I heard nothing.

People who hit a problem with an internal tool rarely file a report. They stop. So I'd actively ask the people who stopped using a workflow what happened.

We need feedback from across developers' environments, including the people who quietly gave up. Their setups are where the next fix is.

Treat it as a product, not a launch

This is where I'd want engineering leads and the people responsible for learning and onboarding working together. Developers need time to practise on real tasks, discuss the results, and learn where their own judgment is still needed. That time has to be planned. It doesn't appear on its own next to delivery work.

A marketplace makes capabilities available. It does not make them useful.

I'd treat the capability layer as a living internal product, with adoption and learning included in the work of maintaining it. Every line to the marketplace can exist. The work is making more of them live.