How to Build an AgentExchange App: From Package Architecture to Security Review

To build an AgentExchange app, you register as a Salesforce Partner, develop in a namespaced Developer org, package the metadata with second-generation packaging (2GP), then pass Salesforce security review before you list it. The build itself is ordinary Salesforce work. The permanent decisions and the review are where projects stall.

We write this from the position of having shipped our own. Flexible Team Share (FTS) and Smarter Files are both live on AgentExchange, so the steps below are the ones we walked, not ones we read about. The order matters more than most tutorials admit.

The honest effort picture

Building the functionality is the part you already know how to do. Apex, Lightning Web Components, flows, a data model: that is a normal Salesforce build. The AgentExchange-specific work sits around it, and it is roughly a third of the total effort on a first app.

That third is namespace and packaging discipline, install-time behavior on orgs you have never seen, and security hardening to a bar higher than most internal projects ever hit. Teams that budget only for features get surprised by the rest.

If you are building a tool for one internal org and never plan to distribute it, you do not need any of this. Unmanaged metadata or a simple unlocked package covers you. The AgentExchange path only earns its cost when you intend to list, sell, or distribute to orgs outside your control.

How do you publish an app on AgentExchange?

Publishing an app on AgentExchange follows five steps: register as a Salesforce Partner and provision your Partner Business Org, build and package your app with 2GP in a namespaced org, create the listing in the Partner Community, submit the package for security review, then publish once Salesforce approves it.

Each step gates the next. You cannot register a namespace without a Dev Hub, you cannot list without a Partner Business Org, and you cannot publish a paid or managed listing without passing security review. Start the partner registration early, because provisioning and agreements take real calendar time before you write any packaged code.

The architecture decisions you cannot undo later

Three decisions are effectively permanent. Make them deliberately, at the start, with an architect in the room.

The namespace is first. You register one namespace in a Developer Edition org linked to your Dev Hub, and it becomes a global, permanent prefix on every component. You cannot rename it, reuse it across a different package family, or recover it once burned. Pick a short, product-neutral namespace before the first packaged commit.

The packaging model is second. New apps use 2GP, built and versioned against your Dev Hub, with source tracked in Git. First-generation packaging (1GP) still shows up in older Trailhead modules and blog posts, but it ties your package to a single packaging org and makes CI awkward. Migrating 1GP to 2GP later is possible and unpleasant, so choose 2GP from day one unless a hard constraint forces otherwise.

The org strategy is third. Keep the namespace org, the Dev Hub, and your testing orgs separate, and run your development and installs against fresh scratch orgs spun from the Dev Hub. Building and testing in one long-lived org hides the failures that only appear on a clean install, which is exactly where reviewers and customers meet your app.

Building to AgentExchange standards from day one

The security review checks the same things a Salesforce Certified Technical Architect checks in a review, so building to that bar as you go is cheaper than retrofitting.

Enforce CRUD and FLS on every database operation. Modern Apex makes this direct: run queries and DML in user mode with WITH USER_MODE on SOQL and AccessLevel.USER_MODE on Database calls, so the runtime enforces object and field permissions instead of you hand-writing isAccessible() checks everywhere. LWC and Aura components that read data need the same discipline behind them.

Close the injection surface. Use bind variables in SOQL, never string-concatenate user input into a query, and pass anything dynamic through String.escapeSingleQuotes. The scanner flags concatenated dynamic SOQL and SOSL as SOQL injection, and it is right to.

Handle secrets and outbound calls correctly. No hardcoded credentials or session IDs, no endpoints in code: use Named Credentials and Protected Custom Metadata or Custom Settings. Document every external service the app calls, because reviewers need to see where data leaves the org.

Reach at least 75% Apex code coverage, with assertions that actually test behavior. Coverage padding clears the platform deployment gate but not a reviewer reading your test methods. Write tests that assert outcomes, not tests that just execute lines.

The end-to-end AgentExchange milestone checklist

Work the milestones in order. The right column is the trap that catches first-time ISVs at each stage.

Milestone	What it involves	The trap that bites
Partner registration	Sign the Partner Program agreement; provision the Partner Business Org and Environment Hub	Doing it late. You need the Business Org before you can register a namespace or create a listing.
Namespace decision	Register one namespace in a Developer org linked to your Dev Hub	It is global and permanent. You cannot rename or reuse it, so choose before any packaged code exists.
Packaging model	Create a 2GP managed package against Dev Hub; track source in Git	Following 1GP tutorials. 2GP is the current path; migrating 1GP to 2GP later costs real rework.
Org strategy	Separate namespace, Dev Hub, and testing orgs; install to fresh scratch orgs	Building everything in one org, which hides clean-install failures until a reviewer or customer finds them.
Security by construction	Enforce CRUD/FLS via USER_MODE, use bind variables, escape dynamic SOQL, remove hardcoded secrets	Retrofitting field-level security across a finished codebase is far slower than writing it in from the start.
Test coverage	Reach 75%+ Apex coverage with meaningful assertions	Padding coverage without assertions. It passes the platform gate and fails reviewer scrutiny.
Security review submission	Run Code Analyzer clean; prepare a false-positive memo and a test environment with login access	Submitting with no documented test path or scan results, which pushes you back in the queue.
Listing and publish	Build the AgentExchange listing, provider profile, pricing, and demo org; publish after approval	A thin listing with no demo or docs, which stalls customer trust even after a technical pass.

What listing and distribution actually involve

The listing is a marketing and trust artifact, not a formality. You build it in the Partner Community: overview, features, screenshots, pricing model, support terms, and a provider profile. A working demo org or a clear install guide does more for conversion than another paragraph of copy.

Distribution then depends on your license model. You choose how licenses are provisioned to subscribers through the License Management App, whether the app is free or paid, and whether you offer trials. These are business decisions with technical consequences, so settle the license model before you finalize packaging.

When you do not need a partner for this

Plenty of teams ship their first AgentExchange app without outside help, and that is a fair call when the app is small, the data model is shallow, and no one on the roadmap depends on the timeline. Trailhead’s ISV modules plus the security review documentation get a determined team through it.

Bring in help when the permanent decisions carry weight: a namespace you will build a product line on, a data model that has to scale across subscriber orgs, or a security posture that has to clear review on the first pass because the launch date is fixed. That first-pass certainty is what our architect-led engagements are built around. Every Tucario engagement runs with a Salesforce Certified Technical Architect involved (1 of fewer than 500 worldwide), and we hold our dedicated client builds to the same AgentExchange standards whether or not they are ever listed.

If you want a second set of eyes on the package architecture or a review-readiness pass before you submit, that is exactly the shape of our AgentExchange Product Development engagement. For a deeper walk through the review itself, see our security review guide.

Frequently asked questions

How long does it take to build and list an AgentExchange app?

It depends on scope, but the security review adds meaningful time beyond feature development, and partner registration and namespace setup should happen weeks before you package. Treat AgentExchange-specific work as roughly a third of the total effort on a first app, then plan the review as a fixed, non-negotiable gate.

What is the difference between 1GP and 2GP packaging?

First-generation packaging (1GP) ties a managed package to a single packaging org and predates source-driven development. Second-generation packaging (2GP) builds package versions against your Dev Hub from Git-tracked source, which suits CI and modular releases. New AgentExchange apps should use 2GP; 1GP mainly persists in older listings and tutorials.

Do I need to pass security review to list on AgentExchange?

Yes, for managed and paid listings. Salesforce security review inspects your package for CRUD/FLS enforcement, injection safety, secret handling, and external data flows before it can be publicly listed or sold. You submit scan results, a test environment with login access, and a memo explaining any scanner false positives.

Can I build an AgentExchange app if I only know Apex and LWC?

You have the core skills, since the functionality is normal Salesforce development. The gap is AgentExchange-specific: namespace and 2GP packaging, clean-install behavior on orgs you do not control, and hardening to the security review bar. Those are learnable, but they are where first-time ISVs underestimate the effort.

What does the AgentExchange security review check?

It checks that your package enforces object and field permissions (CRUD/FLS), avoids SOQL and SOSL injection, stores no hardcoded secrets, uses Named Credentials for endpoints, and documents where data leaves the org. Salesforce Code Analyzer covers much of it automatically, but manual review examines architecture and data handling too.