A marketplace listing is not a working agent

The short version

• An agentic AI marketplace is a catalogue of prebuilt agents and agent components that install into a platform you are already paying for.
• A listing ships prompts, routing and the shape of a tool call, not credentials, field mappings or your permission model.
• Agent platforms are priced by consumption, so a marketplace agent costs more as it is used more, not as more people get logins.
• A failed conversation usually costs the same as a successful one, which is why cost per resolved request is the number that matters.
• Buying off the shelf is the right call when the task is generic, the cost of being wrong is low, and a person sees the output.

What do you actually get when you install an agent from a marketplace?

A configuration, not a colleague. The unit on sale is usually a bundle: a set of instructions, a short list of actions the agent is allowed to call, the topics or intents that route a request to those actions, and sometimes a surface to chat with it in. It runs inside the host platform, on the host's model, under the host's guardrails.

Salesforce made the pattern explicit when it launched AgentExchange, a marketplace for Agentforce where partners list prebuilt actions, topics and templates. Microsoft did the same inside Microsoft 365 Copilot with its Agent Store, announced in May 2025 as a place to build, publish and discover agents. Most of the other stores you will meet follow the same shape, because a store exists to make the platform underneath it harder to leave.

That tells you where the value sits and where it stops. A template can carry the generic version of a task: the wording, the sequence, the standard objects a CRM or a mail client exposes to everybody. It cannot carry your field names, your approval steps, your exceptions, or the fact that one customer segment is handled differently for reasons that predate everyone currently employed.

Why does a marketplace agent stop working where the demo ended?

Because the demo ran on the generic case, and the generic case is the only thing a template can contain. An agent is a loop: read the request, pick a tool, call it, look at the result, decide again. A listing can ship the prompt and the shape of the tool call. It cannot ship the credential, the field mapping, the rate limit, the retry behaviour, or the decision about what the agent should do when the lookup comes back empty.

The second gap is your content. Any agent that answers questions is only as good as the material it retrieves, and most organisations discover at this point that half their policy documents contradict the other half. The template assumes a tidy knowledge base. Getting to one is the actual project, and no store sells it.

The third gap is permission. In a demo everything is readable by the person demoing. In production the same question has a different correct answer depending on who asked it, and that has to be enforced before retrieval rather than filtered out of the answer afterwards. A marketplace agent inherits whatever the platform enforces, which is usually role level and rarely record level.

What does the listing cover, and what stays with you?

What does a marketplace agent cost once real traffic hits it?

More than the listing suggests, and in a unit you are probably not budgeting in. Agent platforms are priced by consumption rather than by seat. Salesforce's own published pricing page is a fair illustration: it lists Flex Credits at $500 per 100,000 credits, and offers an alternative of $2 per conversation.

Per conversation pricing is easy to model and easy to underestimate. At $2 a conversation, ten thousand conversations a month is $20,000 a month, which is arithmetic rather than a prediction about your volumes. The part that catches teams out is that a conversation costs the same whether it ends in a resolved request or an escalation, so a half working agent gets charged twice: once by the platform, and once by the person who picks up what it could not finish.

So the number to track is cost per resolved request, not cost per month. It is the only figure that puts an off the shelf agent, a custom one, and doing nothing on the same axis. It also tells you when to stop. An agent that resolves a third of its queue and irritates the rest is not a cheap win, whatever the per unit price looks like.

When is buying from a marketplace the right call?

When the task is generic, the data already lives in that platform, and a person sees the output before it matters. Meeting summaries, drafting a reply for review, coding an expense, pulling up a standard record: these are solved problems, and buying them is sensible. You are paying to skip work that gives you no advantage even when you do it well.

It is also the right call when you do not yet know whether the workflow is worth automating at all. An install you can abandon in a fortnight is a cheap experiment, and cheaper than the three week build you would have scoped from a guess. Treat it as research rather than as a rollout. What you want out of the pilot is the list of requests it could not handle, because that list is the specification for whatever you build next.

Buying is the wrong call when the agent sits in the path of revenue, safety or a regulator, when the workflow crosses several systems that each hold a different idea of what a customer is, when entitlement is per record rather than per role, or when the behaviour you want is the thing that makes you different from your competitors. A template cannot encode your advantage. It was sold to everybody.

What should you check before you install one?

• •Which systems it asks for access to, and whether that access is read or write.
• •Whether it can be scoped to one team or one queue before it meets everybody.
• •How it behaves when a lookup returns nothing, which is the most common real failure and the least common demo.
• •Where an escalation goes, who receives it, and what context travels with it.
• •What gets logged, how long logs are kept, and whether you can read them without asking the vendor.
• •What counts as one billable unit when a user asks three questions in a row.
• •Whether you can export the configuration, or only screenshot it.

What happens to a marketplace agent when you change platform?

It does not come with you. A marketplace agent is expressed in the host's own schema: its action definitions, its topics, its connectors, its guardrail syntax. Prompts are portable because they are prose. Very little else is, and an agent assembled from three partner listings is less portable than one you wrote yourself.

That is not a reason to avoid marketplaces. It is a reason to be deliberate about which assets you keep outside them. Three are worth owning in your own repository no matter where the agent runs: the evaluation set you built from real requests, the logs of what users actually asked, and a written description of the workflow as it is, exceptions included. Those survive a migration. The configuration will not.

The practical test is a question worth asking before you install rather than after: if this vendor doubled the price, what would we do in the following month? If the honest answer is 'pay it', you have bought a dependency rather than a tool. That can still be the right trade. It should be a decision, not a discovery.

Who is the marketplace model actually built for?

Organisations that already pay for the platform the store is attached to. That is not a complaint, it is the business model. The agents are there because an account that runs four agents renews more reliably than one that runs none.

It also matches where adoption currently sits. The Census Bureau's Business Trends and Outlook Survey, which asks firms whether they used AI in any business function in the past two weeks, finds that larger firms, those with at least 20 employees, are the biggest users of AI. Those are the firms already running the suites the stores sit inside, and the firms for whom one more install is a small decision.

If you are smaller, or your work does not live inside one vendor's platform, a marketplace is a store attached to a subscription you may not want. The alternative is not necessarily a large build. It is often one narrow agent against your own systems, with your own permission model and an evaluation set you wrote, which is a smaller piece of work than a suite migration and considerably easier to switch off.