Blog / September 22, 2026
Agentforce vs a custom AI agent
Use Agentforce when the work lives inside Salesforce and looks like what Salesforce modeled. Build a custom agent when the work crosses systems, or when the logic encodes something specific to how your company operates. We build custom agents, which is a reason to read the case for the other side first.
The case for the platform agent
A native agent starts inside the security model. It inherits sharing rules, field-level security, and profile permissions without anyone reimplementing them. That is not a small convenience. It is the part of a custom build that takes longest to get right and is easiest to get subtly wrong.
It is also administrable by the people who already administer the system. Configuration lives where admins work, changes go through the same release process, and the vendor maintains the integration as the platform changes underneath it. Nobody on your team owns an upgrade path.
If the requirement is answering questions from knowledge articles, guiding a service process, or drafting inside a record, a platform agent will be running before a custom one is scoped. Those are the tasks the platform was designed around, so the configuration surface covers them well. Choosing to build in that situation is choosing to maintain something you could have configured.
Where platform agents stop
They stop at the platform boundary, and revenue work rarely respects it. A process that reads a product usage warehouse, checks a provisioning system, looks at support history in another tool, and then updates the CRM is not a CRM task with some external calls attached. Most of it happens outside, and the CRM is the last step.
Three other limits show up in practice. Model choice is the vendor decision, not yours, so behavior can change under you. Prompt-level control is bounded by what the configuration surface exposes, which matters when output quality is the requirement. And the audit trail is the one the platform provides, which may not match what your own reviewers ask for.
The comparison that actually decides it
| Question | Platform agent | Custom agent |
|---|---|---|
| Where the work is | Inside the CRM | Across several systems |
| Permissions | Inherited | You implement and prove them |
| Model control | Vendor decides | You choose and can change it |
| Audit trail | What the platform provides | Shaped to your requirement |
| Who maintains it | Your admins, plus the vendor | You, permanently |
| Time to first run | Short | Longer, and front-loaded |
The both answer
These are not exclusive, and the split most teams end up with is reasonable: platform agents for in-CRM tasks under the CRM permission model, custom agents for orchestration across systems. Draw one boundary deliberately. Whatever writes to the CRM should go through a single governed path, regardless of which side built it. Two agents writing through two different mechanisms with two different logs is how you end up unable to answer what changed a record, which is the question that gets asked first when something goes wrong.
How to decide in one pass
List the systems the work touches. If the list is one, and it is Salesforce, configure the platform agent and stop. If the list is three, the orchestration is the project and the CRM is a destination in it, so build. If the list is two, decide on the audit requirement: the stricter it is, the more the custom side wins, because you can shape the trail to it.
SYN.AUTON builds custom agents and the governed write path between them and Salesforce. When the work fits inside the platform, the recommendation is to configure Agentforce instead. See AI Agents, Salesforce Automation, or tell us what you want to automate.
Common questions
- When is Agentforce the right choice?
- When the work happens inside Salesforce, the data it needs is already there, and the task resembles something Salesforce modeled: answering from knowledge articles, guiding a service flow, drafting inside a record. Platform-native agents inherit the permission model and admin tooling, which is real value that a custom build has to recreate.
- When does a custom AI agent make more sense?
- When the work spans systems Salesforce does not own, when the logic is specific to how your company operates, when you need control over which model runs and how it is prompted, or when you need an audit trail shaped to your own requirements rather than the platform's.
- Can you use both?
- Yes, and it is common. Platform agents handle in-CRM tasks under the CRM's permission model while custom agents handle cross-system orchestration. The boundary worth drawing is that whatever writes to the CRM should go through one governed path, whichever side built it.
Related reading
- Clay vs Apollo for enrichment
Apollo sells you a database. Clay orchestrates many databases, including Apollo. That structural difference decides which one fits, and it is not the one most comparisons lead with.
- Build vs buy for CRM automation
Buy when the problem is common and the vendor already solved it. Build when the logic is specific to how your company sells. Here is the test that separates the two, and the costs each side hides.
- n8n vs Zapier for revenue operations
Zapier bills per successful action, which makes multi-step revenue workflows expensive at volume. n8n bills per execution and can be self-hosted, which matters when CRM data cannot leave your infrastructure. Here is how to choose.