Agentforce
Publishing to AgentExchange: what it takes to list an agent action, not an app
AppExchange is now AgentExchange, and the thing you ship might be a single agent action, not a whole app. Here's how an action, topic, or agent template is packaged as Agentforce metadata, how the security review changes, and what a customer needs licensed to install it.
You built an Apex action that does one thing your agent needs, and does it well. A customer sees it in a demo and asks the obvious question: can we get that? For fifteen years the answer was “install our managed package.” Now there’s a second answer. Install this one action into your own agent.
That second answer is what AgentExchange is for, and the shift is smaller than it sounds. The unit you distribute changes from an app to an action. Most of the machinery underneath, the package, the security review, the license management, is the AppExchange apparatus you may already know. If you’ve listed a managed package before, you own most of the plumbing already.
So here’s the opinion up front. Don’t treat AgentExchange as a new platform to learn. Treat it as a new packageable unit (Agentforce metadata) riding the ISV pipeline you already understand, with one new thing to prepare: the trust story for what your action does with an LLM.
AppExchange is now AgentExchange
The naming caught people off guard. Salesforce launched AgentExchange as a separate agent marketplace at TDX 2025. Then at TDX 2026 it folded AppExchange, the Slack Marketplace, and the Agentforce ecosystem into one storefront under the AgentExchange brand. appexchange.salesforce.com now presents as AgentExchange, and existing listings, reviews, and install history came along.
If you have a classic app listed, nothing broke. It’s still there, still a managed package, still reviewed the same way. What’s new sits alongside it: a set of listing types built for agents rather than for humans clicking a UI.
The unit you ship is an action, or a topic, or a whole agent
AgentExchange lists a few kinds of building block, and picking the right one is the first design decision.
- An action is a single reusable task an agent can call, built from Apex, Flow, a prompt template, or an external API. The customer wires it into their own agent’s topics.
- A topic is a group of related actions plus the instructions and guardrails that scope one area of behavior, like billing or returns.
- A prompt template is a grounded, reusable prompt for consistent output.
- An agent template is a whole deployable agent, several topics and actions and the planner that ties them together, that a customer stands up in one move rather than assembling.
The difference that matters commercially is standalone capability versus a finished agent. An action drops into an agent the customer already runs. An agent template hands them a working agent. Ship the smallest unit that solves the problem, because a narrow action is easier to review, easier to install, and easier for a customer to trust than a whole agent they have to adopt wholesale.
Packaging is metadata, and the names are specific
Under the hood, an Agentforce action is not code you hand over. It’s metadata, and each concept maps to a metadata type you retrieve into a DX project and put in a package. Get the names right, because the packaging and the dependencies are unforgiving about them:
- An action is a
GenAiFunction. - A topic is a
GenAiPlugin. - A prompt template is a
GenAiPromptTemplate. - The planner, one per agent, is a
GenAiPlannerBundle. - The agent and its version are
BotandBotVersion. - A full agent template is a
BotTemplate.
One version note worth carrying: the older GenAiPlanner type was deprecated at API version 64.0 and replaced by GenAiPlannerBundle, so build against the bundle and confirm the exact API version your retrieve and package steps require before you pin it. The Agentforce metadata model has moved more than once in 2026, so treat any version number you read, including here, as something to check against the current metadata guide.
The packaging itself is the standard second-generation flow. Retrieve the components, put them in a package directory, cut a version:
# Retrieve the action and its topic into a DX project (adjust members to your org)
sf project retrieve start \
--metadata GenAiFunction:Get_Order_Status \
--metadata GenAiPlugin:Order_Servicing
# Create a 2GP managed package version, then promote when the review passes
sf package version create --package "Order Servicing Actions" \
--installation-key-bypass --code-coverage --wait 30Watch the dependency chain, because it’s the most common packaging failure. A GenAiPlannerBundle references its topics, and a GenAiPlugin references its actions, so every referenced GenAiPlugin and GenAiFunction has to be present in the package or the target org, or validation fails. Package the whole graph, not the top of it.
The other thing that decides whether your action gets used isn’t in the metadata schema at all. It’s the action’s description. The planner reads that description to decide when to call your action, so a vague one is a capability the agent never reaches for.
That’s the same lesson as building any custom Apex action, where the description is the code that matters most. On AgentExchange it’s also your product’s discoverability.
The security review is the one you know, plus a trust story
An AgentExchange listing passes the Salesforce Security Review. It’s the same ISVforce program, the same five stages: you submit, it’s verified, it enters the Product Security queue, it’s tested, you’re notified. Everything in the AppExchange Security Review still applies. CRUD and FLS enforcement, no injection surface, secrets out of source, explicit sharing.
What’s layered on top is the agent-specific trust documentation. Because your action feeds and reads an LLM, reviewers expect a data-flow diagram showing how inputs and outputs move, your guardrail configuration, and the compliance story for anything that leaves Salesforce. Prepare that as a design artifact, not a submission afterthought. An action that sends a full record to an external model is exactly what the extra scrutiny exists to catch.
Listing an external MCP server is a different route
Not every capability is Salesforce metadata. If you run tools on your own infrastructure, AgentExchange also lists external MCP servers, and the mechanism is different from a package.
The server is registered in the Salesforce API Catalog. Salesforce discovers its tools through the Model Context Protocol handshake, and an admin creates a connection that authorizes it. OAuth 2.0 is supported, with token handling managed for you.
The customer connects to a running service rather than installing metadata. If your value lives outside the platform, this is the path. It’s the same MCP server integration Agentforce uses for any external tool, packaged for distribution.
The money, and the part that doesn’t change
Monetization runs through AgentExchange Checkout. The published revenue share is 15% to Salesforce on a Checkout sale, with a small per-transaction add for card payments, and a fixed-fee alternative for some cases. Check the current partner terms for the exact figures, since the program terms moved with the April 2026 relaunch.
The part that surprises returning ISVs: Checkout does not replace the License Management App. When a customer buys, Checkout writes a license record into the LMA, and subscription changes update it. The LMA is still where you provision and track licenses, exactly as for a classic app.
Salesforce also announced a $50M Builders Initiative aimed at smaller shops that struggle to clear the enterprise security bar. It’s worth a look if the review is the thing standing between you and a listing.
What the customer needs to run your action
An installed action isn’t useful on its own. It runs inside the customer’s agent, which means their org needs Agentforce enabled and credits to spend, because every action the agent executes meters. That’s a real gate: a customer without Agentforce can install nothing here.
Data 360 is a narrower requirement than people assume. An action that works over CRM records through Flow, Apex, or a prompt template with merge fields doesn’t need it. It becomes necessary when you’re grounding on unstructured data, the knowledge and documents case.
Say which your action needs in the listing. A customer who installs expecting it to work and then hits a licensing wall leaves a one-star review.
Once installed, your action shows up in the customer’s Agent Builder as something their admin adds to a topic. You’re shipping a capability into their agent, not an app onto their org, and that framing is the whole difference from a classic listing.
AppExchange app versus AgentExchange action, side by side
| Classic AppExchange app | AgentExchange action | |
|---|---|---|
| Unit shipped | An app (objects, Apex, LWC, Flows) | An action, topic, template, or MCP tool |
| Packaged as | Managed package of platform metadata | Managed package of Agentforce metadata (GenAiFunction, GenAiPlugin, …) |
| Who consumes it | A person using a UI | An agent calling it at runtime |
| Customer prerequisite | A Salesforce license | Agentforce enabled and credits; Data 360 for unstructured grounding |
| Review | ISV Security Review | Same review, plus LLM trust artifacts |
| Monetize / license | Checkout and the LMA | The same Checkout and the LMA |
Where to start
If you already ship on AppExchange, the move is small and worth making. Pick the single most useful thing your product does inside an agent, and package that one action rather than porting your whole app. Get the metadata graph complete so packaging validates. Write the action description as carefully as you write the code, because the planner reads it to decide whether your action exists. Prepare the LLM data-flow and guardrail documentation early, because that’s the new part of the review. Then decide, honestly, whether you’re shipping an action a customer bolts onto their agent or a whole agent they adopt, because that choice shapes everything from the metadata to the listing to the support you’ll owe.
The plumbing is familiar. The unit is new. Ship the smallest one that works.
Understanding the basics
Is AgentExchange the same as AppExchange now?
Since TDX 2026, yes, they’re one marketplace under the AgentExchange brand, with the Slack Marketplace folded in too. Existing AppExchange managed-package listings, their reviews, and install history carried over and still work. What’s new is a set of agent-native listing types (actions, topics, prompt templates, agent templates, and external MCP servers) built on Agentforce metadata rather than on the objects, Apex, and LWC of a classic app.
How do I package an Agentforce action for AgentExchange?
You distribute it as a second-generation managed package of Agentforce metadata. An action is a GenAiFunction, a topic is a GenAiPlugin, a prompt template is a GenAiPromptTemplate, and the planner that ties an agent’s topics and actions together is a GenAiPlannerBundle. Retrieve those components into a DX project, package the full dependency graph so referenced topics and actions are present, cut a package version, and submit it for the Security Review. Confirm the required API version against the current metadata guide, since the Agentforce metadata model has changed during 2026.
Is the AgentExchange security review different from the AppExchange one?
It’s the same ISVforce Security Review pipeline and the same five stages, and everything the classic review checks (CRUD and FLS, injection, sharing, secrets) still applies. The addition is agent-specific trust documentation: a data-flow diagram of how LLM inputs and outputs move, your guardrail configuration, and compliance evidence for anything that leaves Salesforce. Prepare those as design artifacts before you submit.
What does a customer need to install my agent action?
Their org must have Agentforce enabled and credits available, because the agent spends credits every time it runs your action. Data 360 isn’t required for actions that work over CRM records through Flow, Apex, or prompt templates with merge fields; it’s required when your action grounds on unstructured data like knowledge or documents. State the requirement in your listing so a customer doesn’t install it and hit a licensing wall.
If you’re weighing whether to turn a capability you’ve built into an AgentExchange listing, or want the Security Review cleared with the LLM trust artifacts in place the first time, talk to us. Building managed packages to the review bar, now including agent actions and templates, is exactly the AppExchange product engineering we do.
