Salesforce launched AgentExchange as the marketplace for Agentforce: prebuilt agents, actions and templates you can install instead of building from scratch. The pitch is familiar if you’ve been around Salesforce long enough. AppExchange did the same thing for apps fifteen years ago. Install instead of build, and get to value faster.
The question that actually matters isn’t “should I use AgentExchange.” It’s which decision applies to the thing in front of you: build it yourself, buy something off the shelf, or buy something and then rework it until it fits. Most teams default to one answer regardless of the situation. That’s the mistake.
What’s actually on AgentExchange
Listings fall into a few buckets. Fully packaged agents aimed at a specific job, like a service agent or a sales research agent. Agent actions, smaller building blocks you drop into your own agent. And templates: a starting structure for topics, instructions and guardrails that you still have to configure for your org.
The marketing treats all three the same way. They’re not the same decision at all. A packaged agent is closer to installing an app. An action is closer to installing a library. A template is closer to downloading someone else’s starting notes.
Build, buy, or customise
Three honest options, and most orgs land in the third one more often than they expect.
Buy wins when the job is generic
If the task doesn’t touch anything specific to how your org runs, a prebuilt agent is usually the right call. Lead qualification against standard fields. Case summarisation. FAQ-style support questions where the knowledge base is already clean. These are commodity problems. Paying to solve them yourself is paying to reinvent something a vendor has already tested against thousands of orgs.
The failure mode here is skipping evaluation because the install was easy. An easy install doesn’t mean the agent’s reasoning matches your process.
Build wins when the logic is the differentiator
If the value sits in how your org actually makes a decision, not whether a decision gets made, build it. A contact-centre team I worked with had a triage process that weighted case severity, customer tier and SLA exposure in a specific order, tuned over years. No off-the-shelf agent was going to replicate that without being rebuilt into something custom anyway. At that point, you’re not saving effort by starting from a template. You’re adding a translation step.
Build also wins when the data behind the agent is genuinely unusual. If your object model, your Apex business logic or your approval chains don’t look like anyone else’s, a generic agent will either ignore that complexity or get it wrong.
Customise is where most of this actually lands
In practice, a lot of AgentExchange installs end up as a customise decision whether or not anyone planned it that way. You install a packaged agent, discover it’s 70% right for your process, and then start rewriting instructions, swapping actions and adding guardrails until it matches. That’s fine. It’s often faster than building from nothing. But budget for it as a build, not an install. Teams that treat a prebuilt agent as finished the moment it’s installed end up shipping something that technically works and practically annoys every user who touches it.
What to check before you trust a prebuilt agent
A few things matter more than the demo:
- Where does it get grounded? If it’s pulling from Data Cloud, your data quality becomes its accuracy ceiling, no matter how good the agent’s reasoning is.
- What actions can it actually take? A read-only agent and a write-access agent are different risk profiles. Know which one you’re installing before you see what it does in production.
- Can you see its reasoning? If the vendor can’t show you why it made a call, you can’t debug it when it makes a wrong one, and it will eventually make a wrong one.
- Who maintains the underlying logic? A vendor update to a packaged agent can change its behaviour without you touching anything. That’s a different maintenance burden than code you own.
None of this is unique to AgentExchange. It’s the same diligence you’d apply to any third-party integration. The difference is that an agent making a wrong call is harder to spot than an integration throwing an error. A failed callout shows up in the logs. An agent that quietly routes a case to the wrong queue, or summarises a complaint in a way that drops the part that mattered, just looks like a slightly bad outcome. Nobody gets paged for that.
The actual decision framework
Before installing anything, answer three questions. Is the underlying process generic across orgs, or specific to how we run things? Does getting it wrong cost us a bad customer interaction, or something worse, like a compliance or financial problem? And are we prepared to own the maintenance of whatever we install, the same way we’d own a build?
If the process is generic and the stakes are low, buy and move on. If either answer tips the other way, plan for build or customise from the start rather than discovering it three months in, once the packaged agent can’t be stretched any further.
AgentExchange is going to keep growing. The marketplace model works, and Salesforce has every incentive to make it the default path into Agentforce. That’s a reasonable thing for a platform to want. It’s not a reason to skip the evaluation most teams would already run on any other third-party tool going into a production process.