Should you build AI agents on Salesforce or buy a third-party app?
TL;DR: Buy for common use cases, build for the one or two workflows that are genuinely yours, and own the governance layer either way. A security-reviewed AgentExchange (formerly AppExchange) app usually installs in hours and carries a predictable per-user price. A custom Agentforce build carries metered usage and services costs that our own pricing analysis estimates run roughly between $50,000 and $250,000 in Year 1 for a mid-market rollout. Neither path makes you compliant on its own.
An AI agent on Salesforce is software that reads your CRM data, decides what to do, and takes actions (answering a customer, updating a record, routing a case) with limited or no human input. You can build one on Salesforce's Agentforce platform, assemble one with pro-code, or install a prebuilt one from the marketplace.
Most teams end up with a mix: buy the fast, common use cases, build the one or two workflows that differentiate the business. The practical question for any given project is which path fits that use case, given your budget, timeline, and compliance requirements.
What does "build" actually mean on Salesforce?
Build spans a range. On the light end, you use Agentforce's low-code Agent Builder and Prompt Builder to assemble agents from your existing Salesforce data and Flow automations. On the heavy end, you write Apex, integrate external systems, model data in Data 360 (formerly Data Cloud), and stand up a full autonomous agent stack with custom actions.
A few facts worth pinning down:
- Agentforce does not strictly require Data 360, but Salesforce positions it as the engine that grounds agents in unified customer records, and most non-trivial deployments end up adopting it (Salesforce). The Data 360 Starter SKU lists at $60,000/year for 10 million credits and 5 TB of storage, and production data footprints often push past six figures annually (Salesforce Help).
- Agentforce usage is metered. Salesforce lists it at $2 per 24-hour conversation, or $500 per 100,000 Flex Credits, where a standard action costs about 20 credits (~$0.10) and a voice action about 30 credits (~$0.15). Flex Credits and Conversations cannot be used in the same org at the same time (Salesforce).
- There is a genuine free tier. Salesforce Foundations gives Enterprise Edition customers 200,000 Flex Credits, 250,000 Data 360 credits, and access to Agent Builder and Prompt Builder at no cost, which is enough to prototype (Salesforce).
The build cost that surprises people is not the license line, it is the implementation: knowledge base setup, data modeling, integration, and professional services. For a non-trivial mid-scale rollout, professional services alone commonly run $50,000 to $150,000, which is what pushes typical Year 1 spend into the $50,000 to $250,000 range cited above (Enterprise Dreamin).
What does "buy" actually mean on Salesforce?
Buy means installing a managed package from Salesforce's marketplace (now AgentExchange, formerly AppExchange) that already handles your use case (Salesforce). Setup is typically measured in hours or days rather than weeks.
Buy does not mean no work. You still configure permissions, connect your data, map fields, and test the app against your own scenarios. What you skip is building the agent runtime, the prompt orchestration, and the model integration from scratch.
Pricing on the buy side is often per-user and flat, which makes budgeting predictable, though flat seat pricing scales with headcount and can exceed metered usage for large teams. The AgentExchange catalog includes agent and AI apps from a range of vendors: some run the AI inside your own org, some call an external service, and some layer specialized skills onto Agentforce itself. Apps that follow the "install inside your own org" pattern, such as GPTfy, keep AI execution inside your Salesforce org and let you connect an outside model through Salesforce Named Credentials; others take a different approach. Which specific vendor you pick matters less than the build-vs-buy decision itself, so compare each app on its own architecture rather than by category.
The honest tradeoffs of buying: you accept the vendor's roadmap and release cadence, customization is bounded by what the app exposes, per-seat cost rises with headcount, and switching later means migration work. Those are the flip side of the speed and predictability.
How do build and buy compare across the trade-offs?
| Trade-off | Build (Agentforce / custom) | Buy (AgentExchange app) |
|---|---|---|
| Time to value | Weeks to months; driven by data modeling, integration, and testing (Enterprise Dreamin) | Hours to days for a security-reviewed package |
| Cost model | License + metered usage ($2/conversation or Flex Credits) + Data 360 + services; our own pricing analysis puts Year 1 at $50K to $250K+ (Salesforce; Enterprise Dreamin) | Often flat per-user, which scales with headcount, plus any model token spend you take on directly |
| Model flexibility | Agentforce supports a defined set of models; deeper choice needs pro-code | Varies by app; some let you bring OpenAI/Claude/Gemini via Named Credentials |
| Data residency | Depends on architecture; Data 360 and the Trust Layer keep data in Salesforce with zero-retention options (Salesforce) | Depends on the app; some run entirely in-org so data does not leave, others call an external service |
| Customization depth | Highest; you control actions, orchestration, and logic | Bounded by the app's design and config options |
| Maintenance | You own it: prompts, actions, model updates, regressions | Vendor ships updates through the managed package, and you inherit its roadmap and pace |
| Lock-in | Lower; you own the configuration, though you own the upkeep too | Higher; you depend on one vendor's pricing, roadmap, and continued support |
| Governance burden | Yours to configure (masking, retention, audit) | Still yours to configure, even if the app helps |
Note on the security review: Salesforce's security review inspects a package's code and configuration for common vulnerabilities before it is listed (Salesforce Developers). It is a check on the package, not a guarantee that the app is safe or compliant for your specific data and regulatory context.
Where does the model run, and does your data leave the org?
This is the question compliance teams care about most, and the answer depends on the path.
Agentforce routes prompts through the Einstein Trust Layer, which supports data masking and zero-retention policies so raw data is not stored by the model provider (Peergenics). Marketplace apps vary: some keep AI execution inside your org so no data leaves your Salesforce infrastructure, while others send requests to an external service. Check each app's architecture rather than assuming.
Whichever path you take, the platform gives you the tools but does not make you compliant by default. As practitioners note, Salesforce and Agentforce follow a shared-responsibility model: the platform supplies the governance infrastructure, but you must configure encryption, access controls, masking, and audit logging to meet HIPAA, GDPR, or the EU AI Act (Cirra).
That responsibility does not shift to the vendor when you buy. Whether you build agents or install an app, you are the one masking PII before it reaches a model, enforcing data retention, honoring deletion requests, and keeping an audit trail of prompts and responses. HIPAA audit controls, for instance, expect immutable logs of every retrieval, prompt, response, and redaction event, retained per your policy (Fini).
Because of that, many teams treat governance as a separate decision from build-vs-buy: a dedicated masking, retention, and DSAR/RTBF layer that sits underneath whichever agent path you pick. Options here include Salesforce's own Shield encryption and event monitoring, data-governance tools such as Own (formerly OwnBackup) and Prodly, and dedicated privacy products such as Cloud Compliance, which automates masking, retention, consent, and DSAR/RTBF across frameworks like HIPAA, GDPR, India's DPDP, and POPIA (Cloud Compliance; India DPDP). The specific tool matters less than the point: the masking-and-audit problem exists no matter which path you choose, so budget and plan for it explicitly.
When does each path actually fit?
Lean toward build when:
- The workflow is core to your business and genuinely differentiated, not a common pattern others have already packaged.
- You need autonomous, multi-step agents acting across your data with custom actions and orchestration.
- You already run (or can justify) Data 360 and have implementation budget and admin/dev capacity.
- You are prepared to own ongoing maintenance: prompt tuning, action updates, and regression testing.
Lean toward buy when:
- The use case is common (support deflection, sales research, summarization) and a reviewed app already covers it.
- You want predictable per-user cost instead of usage that scales with conversation volume.
- You need to ship in days and prove value before committing to a bigger platform investment.
- You want a specific model and an app supports bringing your own via Named Credentials, and you are comfortable depending on that vendor's roadmap.
The common real answer is to buy for breadth and build for the one thing that is yours. Piloting a bought app is also a cheap way to learn what "good" looks like before you invest engineering time in a custom agent.
