AgentExchange: a practitioner's guide to buying agent actions instead of building them

Every Agentforce project hits the same fork. The agent needs to do something — send a DocuSign envelope, pull a record from Workday, post to a Slack canvas, look up a shipment — and you have two ways to get there. You can build a custom action, which means code, a callout, a hand-written schema, a description you tune until the agent picks it reliably, and a maintenance burden that never ends. Or you can go to the marketplace, find an action a partner already built and got security-reviewed, and install it. For a growing share of the integrations teams reach for, the second path now exists — and most teams don’t know how to evaluate it.

That marketplace is AgentExchange, and in 2026 it stopped being a side gallery and became the Salesforce marketplace. This is a practitioner’s guide to buying from it: what the four building blocks actually are, how to decide when to install versus build, what the security review does and doesn’t guarantee, and what changed when Salesforce folded AppExchange and the Slack Marketplace into it. If you’re on the other side of this — a partner trying to get listed — our writeup on what the security review actually checks is the one you want. This post is for the buyer.

What AgentExchange is, and the 2026 unification you need to know about

AgentExchange launched in March 2025 as the “trusted marketplace for Agentforce” — a place to discover, try, and buy prebuilt agent building blocks, opening with more than 200 partners and hundreds of ready-made components. Named launch partners included Google Cloud, Box, DocuSign, and Workday, and the pitch was straightforward: stop hand-building the same agent integrations everyone else is hand-building.

Then, in April 2026, Salesforce did something bigger. It merged AppExchange, the Slack Marketplace, and the Agentforce ecosystem into a single unified platform — and kept the AgentExchange name for it. The consolidated marketplace brought together the 10,000+ existing Salesforce apps, 1,000+ prebuilt agents and sub-agents, tools, and — notably — MCP servers from the Agentforce ecosystem into one storefront. Existing reviews, install history, and listings carried over; appexchange.salesforce.com now redirects to the unified platform. In other words: the thing you knew as AppExchange is now a section of AgentExchange, and the agent building blocks sit alongside the traditional managed packages.

The mental shift is that “install an app” and “install an agent capability” are now the same shopping trip. That’s convenient — and it means the discipline you apply to a managed package now has to apply to an agent action too, because they arrived through the same door.

Two features of the unified marketplace are worth flagging because they change discovery. Search is now semantic, powered by Data 360 — it matches your business intent, not just keyword overlap — and Salesforce has signaled conversational search (ask follow-ups, compare solutions side by side) landing later in 2026. And critically, the security review process carried over unchanged from AppExchange: every listed solution still goes through Salesforce’s review for security, privacy, and compliance. Hold onto that fact — we’ll come back to what it does and doesn’t mean for you.

The four building blocks, and what each one commits you to

The reason “buy versus build” is a real decision and not a slogan is that AgentExchange sells four different kinds of thing, and they commit you to very different amounts of the agent. From smallest to largest:

• Actions — the individual jobs an agent can do, usually wrapping an integration: create a case, cancel an order, send a Slack DM, update a Slack canvas, search a system. An action is the atomic unit. Installing one gives your agent one new capability, and it’s the lowest-commitment purchase.
• Topics — a focused bundle that groups related actions with the instructions that govern them, scoped around a single job or task. A topic is a behavior, not just a capability: it carries the guardrails for how those actions should be used. Installing a topic shapes how the agent acts, not just what it can reach.
• Prompt templates — reusable, pre-written prompts that produce consistent outputs for a repeated interaction. These slot into Prompt Builder-style grounded generation and save you from re-deriving a prompt everyone needs.
• Agent templates — the largest unit: a whole agent solution combining multiple topics, prebuilt actions, metadata, and global instructions that span topics. This is closest to “install a working agent and adapt it” rather than “add a capability to mine.”

The size of the block is the size of the decision. An action is a low-risk install — it’s one tool, you allowlist it, you test it, done. An agent template is nearly an architecture choice: you’re inheriting someone else’s topic structure, instructions, and action wiring, and adapting a template you didn’t design can cost more than building a lean agent from scratch if your process doesn’t match the template’s assumptions. The trap is treating a template purchase as a shortcut when it’s actually a commitment to someone else’s model of the work.

Buy versus build: the decision that actually matters

Here’s the framing we use when a client asks whether to install from AgentExchange or build it themselves. It comes down to three questions.

Is the capability generic or is it yours? A DocuSign envelope, a Slack post, a Workday lookup — these are the same for every customer, and a partner action that’s been installed a thousand times is almost certainly more robust than the one you’ll write once. But a capability that encodes your business logic — your pricing rules, your eligibility checks, your data model — has no off-the-shelf equivalent, and installing something generic and bending it to fit is usually worse than a clean custom Apex action. Buy the commodity; build the differentiator.

Does the maintenance move to the partner, or stay with you? The real cost of an integration isn’t building it — it’s maintaining it when the upstream API changes. A well-maintained partner action means that burden moves to someone whose business is keeping it working. That’s the strongest argument for buying. The counter-argument: you’ve now taken a dependency on a third party’s release cadence and support quality, which is exactly why the partner’s track record matters more than the demo.

Would you rather vet a vendor or vet code? Buying means vetting the partner — their security posture, their support, their longevity. Building means owning the code and its bugs. Neither is free; they’re different kinds of work. For a team already stretched, moving the work to vendor selection is often the better trade — as long as you actually do the selection.

The security review is a floor, not a finish line

This is the point most buyers get wrong, and it’s the most important one in the post. Every solution on AgentExchange passed a Salesforce security review. That’s a genuine, meaningful signal — it means the listing cleared a real bar for security, privacy, and compliance, and it’s the reason the marketplace can call itself “trusted.”

But a passed security review tells you the component isn’t malicious or grossly negligent. It does not tell you the component is right for your org, scoped correctly for your risk tolerance, or safe with your data. Those are your job, and installing a reviewed action doesn’t transfer them to Salesforce.

Concretely, before an installed agent action touches production:

• Check its permissions and scope. A reviewed action can still ask for broader API scopes or data access than your use case needs. You keep control over data permissions and integrations — use it. Grant the least privilege the action needs to do its job, no more.
• Treat installed actions as part of your attack surface. An action that pulls in external content is a channel for prompt injection exactly like one you wrote. The review didn’t neutralize that; your allowlisting and guardrails do.
• Test it against your data, not the demo. A component that works beautifully on the partner’s sample org can behave differently against your data model, your edge cases, and your volume. The install is the start of your testing, not the end of it.
• Mind the sprawl. Every installed action, topic, and template is one more thing an agent can reach and one more thing to maintain. The same agent-fleet governance discipline that applies to what you build applies to what you install — and too many tools measurably degrades an agent’s ability to pick the right one.

The review clears the supplier. You still have to clear the fit.

How you actually install, and where MCP fits now

Discovery and install happen in two places. You can browse the marketplace directly, or — and this is the smoother path — work inside Agent Builder, where AgentExchange is now embedded so relevant connectors, tools, and capabilities surface as you build, without leaving your development environment. When you’re assembling a service agent, the marketplace offers up the knowledge connectors and case-management tools that match what you’re doing.

The 2026 unification added a wrinkle that ties directly to how agents reach external systems: MCP servers are now listed on the marketplace alongside actions and templates. That means “give my agent access to system X” increasingly has a marketplace answer — find a listed MCP server, register it, allowlist its tools. If you’re weighing that path, it connects straight to how Agentforce consumes MCP servers and the broader MCP standard: the marketplace is becoming a directory of governed tool sources, not just packaged apps.

On money: partners can offer components free or paid, and Salesforce added a Go-to-Market app supporting private offers, unified billing, and automated provisioning — so a paid action can bill through the same channel as the rest of your Salesforce spend. Budget for the fact that “install from the marketplace” can be a recurring cost, not a one-time convenience, and factor a paid action’s subscription into the same ROI math you’d run on building it.

What to actually do

AgentExchange changes the default question of an Agentforce build from “how do we build this integration” to “should we build this integration at all, or install it.” That’s a healthier default — most teams over-build commodity capabilities they could have bought. But the marketplace rewards buyers who bring discipline and punishes ones who treat “it’s on AgentExchange” as a substitute for judgment.

So: buy the commodity capabilities and build the ones that encode your actual business logic. Prefer small blocks — an action you can test in an afternoon over an agent template that imports someone else’s model of the work. Read the security review as a floor that clears the supplier, then do your own job on top of it: scope the permissions down, test against your data, and treat every installed component as part of your attack surface and your maintenance load. And when you’re evaluating a partner’s component, weigh the partner’s track record more heavily than the demo, because you’re taking a dependency on their support and their release cadence, not just their code. Do that, and the marketplace genuinely accelerates you. Skip it, and you’ve just installed a fleet of black boxes with your data’s permissions.

If you’re deciding which agent capabilities to buy from AgentExchange and which to build — and you want the buy-versus-build call, the permission scoping, and the testing done properly before anything touches production — talk to us. Vetting components and building the ones that have to be yours is exactly the work we do, and choosing the right implementation partner for that call is a decision worth making carefully.

Understanding the basics

What is AgentExchange?

AgentExchange is Salesforce’s marketplace for Agentforce building blocks — prebuilt actions, topics, prompt templates, and agent templates you can install instead of building from scratch. It launched in March 2025 with 200+ partners, and in April 2026 it absorbed AppExchange and the Slack Marketplace into a single unified marketplace of 10,000+ apps, 1,000+ prebuilt agents and sub-agents, tools, and MCP servers. Every listed solution passes a Salesforce security review.

What are the four AgentExchange building blocks?

Actions are individual capabilities an agent can perform, usually wrapping an integration (create a case, send a Slack message, look up a record). Topics bundle related actions with the instructions that govern them, scoped around a single job. Prompt templates are reusable, pre-written prompts for consistent outputs. Agent templates are complete agent solutions combining multiple topics, prebuilt actions, metadata, and global instructions. The blocks range from low-commitment (an action) to nearly an architecture decision (an agent template).

Does the AgentExchange security review mean a component is safe for my org?

The review means the component cleared Salesforce’s bar for security, privacy, and compliance — it isn’t malicious or grossly negligent. It does not mean the component is correctly scoped for your risk tolerance or safe with your specific data. You still need to scope its permissions to least privilege, test it against your own data model and edge cases, treat it as part of your attack surface, and manage the sprawl it adds. The review clears the supplier; you clear the fit.

Should I buy from AgentExchange or build the capability myself?

Buy commodity capabilities that are the same for every customer (a DocuSign action, a Slack post, a Workday lookup) — a well-maintained partner component is usually more robust and moves the maintenance burden off your team. Build the capabilities that encode your business logic, pricing, or data model, where no off-the-shelf component fits and bending a generic one costs more than a clean custom action. Buying trades code ownership for vendor selection — a good trade only if you actually vet the partner’s track record and support.

---

Weighing which agent capabilities to install from AgentExchange and which to build — and want the permission scoping and testing done right before production? Talk to us. Vetting marketplace components and building the ones that have to be yours is exactly the work we do.