The Salesforce marketplace stopped being a place people browse. If a product only delivers value through screens, it is now invisible at the moment the decision gets made.
In April 2026, at TrailblazerDX, Salesforce merged AppExchange, the Slack Marketplace, and the Agentforce ecosystem into a single destination called AgentExchange. Ten thousand Salesforce apps. More than a thousand pre-built agents, sub-agents, tools, and MCP servers. Twenty-six hundred Slack apps. One catalog.
Most of the coverage treated this as a rebrand. The URL redirects, the listings carried over, the reviews and install counts survived. Nothing broke. Brian Landsman, who runs AgentExchange and global partnerships at Salesforce, framed it as generational: “Now, we are evolving the marketplace for the agentic era.”
That is accurate, and it is also easy to skim past. The thing worth noticing is not the name on the door. It is that the mechanism by which a customer finds a product changed, and the new mechanism has a hard requirement that a large share of the existing catalog cannot satisfy.
What actually changed
Three shifts arrived together.
- The catalog unified. Apps, agents, Slack apps, tools, and MCP servers now share one discovery surface. A customer searching for lead enrichment sees a managed package, a pre-built agent, and a Slack action in the same result set. Those are not comparable artifacts, and they are now competing for the same click.
- Search moved from keywords to intent. Semantic search on AgentExchange is powered by Data 360 and matches customers to solutions based on business intent rather than literal string matching, with recommendations shaped by each org’s existing Salesforce and Slack configuration. Conversational refinement and intelligent comparison are slated for fall 2026.
- Discovery moved inside the builder. This is the one that matters. Agentforce Builder now surfaces relevant agents, sub-agents, and tools contextually while an admin is building. Salesforce’s own example: a user assembling a service agent gets shown knowledge connectors, case management tools, and sentiment analysis capabilities, in flow, without leaving the canvas.
Read that last one again with a vendor’s eyes. The highest-intent moment in the entire funnel, the moment where a customer has a specific unmet need and is actively assembling something to meet it, now happens inside a builder that recommends components. Not products. Components. Things an agent can call.
What did not change, and why that is the real story
There has been some commentary suggesting the security review got materially harder for AI components. It did not. The AgentExchange security review guidelines carry an effective date of August 9, 2023. The ISVforce Guide was retitled “Build and Distribute AgentExchange Solutions,” but the substance underneath is the same follow-the-data methodology it has always been: wherever the customer’s data goes, Product Security goes, including external web applications, third-party servers, and any callout path. Managed package format, fees, and the Partner Console are unchanged. Salesforce still conducts periodic re-reviews and still flags versions with significant change.
So the barrier did not rise. Something more awkward happened instead. The barrier stayed exactly where it was and the reward moved.
A product can pass security review, hold a five-star listing, carry a decade of install history, and still be structurally unable to appear at the point where the buying decision now happens. Not because it failed a check. Because there is nothing in it for an agent to invoke.
The architectural line
Every product on the marketplace sits on one side of a line that did not used to exist.
On one side: value is delivered through an interface. A user logs in, navigates, sees a screen, clicks, and gets an outcome. The interface is the product. Everything underneath exists to render it.
On the other side: value is delivered through discrete, addressable operations. Something calls a thing, passes parameters, and gets a structured result. The interface, if there is one, is a convenience layer over operations that stand on their own.
For twenty years, both sides were fine. AppExchange was a catalog of installable software and a human read the tile, watched the demo video, and made a judgment. A beautiful UI was a competitive advantage. It still is, for the human buyer.
But an agent cannot watch a demo video, and it cannot click a button. It reads a description of what an action does, decides whether that action is relevant to the task in front of it, and calls it. A product whose functionality is only reachable through a rendered screen is not a candidate. It is not even in the consideration set. It is not that it loses the evaluation. It never enters one.
That is the whole argument. Everything else is implementation.
What an action surface actually requires
“Expose your functionality as actions” is easy to say and gets waved at a lot. The work is more specific than that, and most of it is design work, not code.
Decomposition into units that mean something alone. A screen can be a workflow. An action cannot. If a product’s core value is a seven-step wizard, the useful question is which of those steps is a coherent operation that produces a result someone would want on its own. Usually two or three are. The rest are UI scaffolding for a human who needed guiding. Publishing the wizard as one giant action produces something no agent will ever successfully call.
Descriptions written for a reasoning model, not a marketing page. Action selection is a language problem. An agent decides whether to call something based on how the thing describes itself. Vague, branded, or clever descriptions lose to plain ones. This is also now true of the listing itself, since semantic search matches on business intent. Listing copy optimized for keyword SEO is optimized for a retrieval mechanism that is being deprecated in front of everyone.
Deterministic boundaries around non-deterministic callers. An agent will call an action with parameters no human would have entered, in an order no human would have chosen, at a volume no human could produce. Validation that lived in the UI layer is now absent from the call path. Anything safety-critical belongs in Apex, enforced at the trigger, not in a screen flow or a client-side check that only a browser session ever saw.
Permission scoping that survives delegation. Admins on AgentExchange control data permissions, API scopes, and integration boundaries per solution. When an agent invokes an action on a user’s behalf, the question of whose permissions apply stops being academic. Object and field level security has to hold on the call path, not on the page layout.
An audit record of the invocation. A human clicking a button generates a session, a login history entry, and usually a record change with an owner. An agent calling an action at three in the morning generates whatever the action chose to write down. If the answer is nothing, the customer’s compliance team will find that out at the worst possible time.
There is a fifth item that is really a restatement of the first four: this is an architecture problem, and it does not get solved by a wrapper. Bolting an invocable façade onto a product whose logic lives in its UI produces actions that are thin, brittle, and dangerous under load. The decomposition has to be real.
The off-platform version of this problem
Products that integrate with Salesforce from outside it face the same requirement, plus a second one.
An external product exposing actions to Agentforce is exposing them across a network boundary, under a standing credential, at agent-driven call volume rather than human-driven call volume. Every one of those properties is a cost or a risk. Traffic across that boundary is increasingly billable, which is a separate discussion and one worth having. But the security dimension is more immediate: 2026 has already produced a third repetition of the same OAuth supply chain compromise pattern against Salesforce customers, and the common factor every time is a third-party application holding standing access into the org.
Native packages are not immune to bad architecture. They are, however, not participating in that particular failure mode, and their action surface does not have to cross a network to be invoked.
The unified marketplace makes both kinds of product sit in the same search results. The install decision is where the difference shows up.
What to do about it
For anyone holding a listing, the work sorts into four questions, in order.
- Is any part of this product callable today without a browser? If the honest answer is no, that is the entire roadmap for the next two quarters, and nothing else on the list matters yet.
- Which two or three operations are worth publishing first? Not the most impressive. The most self-contained. The ones that produce a result a reasoning model could recognize as useful without understanding the rest of the product.
- Does the listing describe outcomes or features? Semantic search matches on intent. A listing that reads as a feature inventory is being asked to answer a question it was never written for.
- What breaks when the caller is not a person? Rate, ordering, parameter shape, permission context, and audit. Every one of those assumptions was quietly load-bearing and is now unsupported.
None of this requires a rewrite. It requires deciding that the product’s logic and the product’s presentation are separate things, and then actually separating them. Teams that built that way already have most of the work done. Teams that did not are looking at a real project, and the window in which it can be done calmly is closing.
Resource Interactive builds native Salesforce applications and designs them as action surfaces first, on the theory that a product a machine can call is also a product a person can use, and that the reverse has never been true.
Sources
- Salesforce Ben, “AppExchange, Slack Marketplace, and the Agentforce Ecosystem Are ‘Now One’ With Fresh $50M Funding,” April 2026
- Salesforce, “What’s New on AgentExchange,” agentexchange.salesforce.com
- Salesforce Developers, ISVforce Guide, “Pass the AgentExchange Security Review,” effective August 9, 2023
- Salesforce Developers, ISVforce Guide, “Required Materials for Security Review Submission”
- ReliaQuest Threat Research, “Threat Spotlight: Integration Abused in CRM Data Theft,” July 2026
Leave a Reply