Agents Should Be Distributed Like Libraries, Not Like SaaS
The marketplaces want to be the App Store of agents. The package manager has been waiting the whole time.
The pitch deck arrived last Tuesday and it had four logos on the front page. Four agent marketplaces, all launched in the last eight months, all promising the same thing: a hosted runtime, a discovery surface, a billing rail, and a “deploy in one click” path from somebody else’s agent to your production environment. The model is familiar because it is the same model every vendor reaches for when a new category opens up. Build the SaaS. Own the runtime. Become the App Store of agents.
The vendors selling this are not stupid and the model is not crazy. Marketplaces capture value. Hosted runtimes lock in customers. The economics work for the platform. They work less well for the customer, and they work badly for the agent itself, and the people who will figure that out first are the practitioners who have already had this argument once, around containers, and once more, around CI/CD, and at least twice more around package management. The shape of the answer has been known for a decade. Agents are not a new category. They are libraries with a loop on top, and libraries get distributed through source control and package managers, not through hosted catalogs run by people who want a percentage.
The case for treating agents like libraries is mostly a case about three things the SaaS model cannot give you and that the library model gives you for free: version pinning, code review, and a clean separation between the artifact and the runtime. None of these are exotic. Every working engineering org has them for normal code. The interesting question is why the agent ecosystem keeps acting like they need to be reinvented.
Version pinning is the most concrete one. When an agent’s behavior changes, somebody has to know. In the library model, the agent is a versioned artifact in your package.json or your requirements.txt or your equivalent. A version bump shows up in a pull request. A diff exists. A reviewer signs off. The change is auditable six months later when an incident sends somebody digging through git blame to figure out when the triage flow started misclassifying severity. In the marketplace model, the agent is hosted somewhere, the vendor pushes an update, and your production behavior changes overnight with no diff, no review, and no audit trail beyond the vendor’s changelog, which is written by the vendor, for the vendor, and which you do not get to verify. The vendors will tell you that you can pin a version. Some of them even mean it. Most of the time the pin is a soft pin, the deprecation window is short, and the next major model upgrade silently moves under you anyway because the agent’s behavior depends on the model and the model is not part of the pin.
Code review is the second one and it is the one practitioners feel the hardest after a few months of running agents in anger. An agent’s behavior is encoded in prompts, in tool definitions, in skill files, in retry policies, in routing logic. Every one of those is text. Every one of those benefits from a second pair of eyes. When the agent lives in a GitHub repo, every change to it is a PR, every PR has a review, every review enforces whatever conventions the team has decided matter. When the agent lives behind a vendor portal, the closest thing to review is a “preview this version” button and a textarea where one person clicks save. That is not a workflow. That is a foot-gun with a UI on top.
The runtime question is where the library model breaks cleanly from the SaaS model, because this is where the vendor’s incentives diverge from yours hardest. A hosted agent runtime gives the vendor leverage over your dependency graph. The agent only runs on their platform. The model calls are routed through their inference layer. The observability data is theirs. The cost model is theirs. The migration path off the platform, if you ever want one, is theirs to define and theirs to make difficult. None of this is hypothetical. We have run this exact movie with workflow automation tools, with iPaaS platforms, with low-code builders, and with every prior generation of vendor-mediated runtime, and the ending is the same every time: the bill goes up faster than the value, the lock-in becomes a board-level conversation, and somebody gets handed the project of getting off the platform two years too late.
The library model unbundles all of that. The agent is a package. The model is whatever you point it at. The runtime is your own infrastructure. The observability is whichever tracing stack you already use. The bill is the inference cost plus a rounding error of CPU. The migration path is the same migration path you have for any other library, which is to update the dependency or fork it, and that path stays open because the artifact is text in a repo you control.
The objection from the vendor side, and from a non-trivial number of engineers who have been burned by self-hosting, is that the SaaS model exists for a reason. Operating production infrastructure is real work. Patching is real work. Observability plumbing is real work. The platforms charge a premium because they handle that work, and a team that adopts the library model has to handle it themselves. This is true and it is the strongest argument for the SaaS approach. The counter is that the work in question is work the team already does for the rest of its production stack, and the marginal cost of adding agents to that stack is far smaller than the marginal cost of running a parallel governance regime for one vendor-hosted carve-out. If your team is already doing platform work for its services, adding the agent layer to that work is incremental. If your team is not doing platform work at all and the agent is the first production workload, the SaaS model is genuinely the right choice for a while. The trap is staying on it after the first answer stops applying.
The other objection is discovery. A marketplace solves a real problem, which is that finding good agents written by people you trust is hard, and an open ecosystem of GitHub repos does not solve it by itself. This is fair. The honest answer is that the discovery problem is not solved by handing it to a vendor either. The vendor’s incentive is to surface the agents that pay for placement, not the agents that work best for your use case. The discovery problem is solved by the same mechanism that solved it for libraries, which is reputation, community curation, and the slow accumulation of trust around specific maintainers and specific orgs. That is a slower mechanism than a marketplace launch event, and it is more durable, and it does not put a vendor between you and the artifact.
Where this lands, after a year of watching teams try both models, is that the agent layer is going to look more like the library layer than the platform layer, and the teams that figure that out first are going to spend less, lock in less, and ship more. The marketplaces will exist. Some of them will even be useful for a particular niche. They are not the default. The default is the same boring answer engineering has been giving for two decades when a new category of artifact appears: put it in a repo, version it, review it, ship it through the package manager you already use, run it on the infrastructure you already own.
If the agent in your production stack is on somebody else’s runtime, behind somebody else’s portal, with a version number you do not control, ask the question now rather than the quarter the bill triples.
If this was useful, forward it to one engineer who needs less noise in their feed.