Choose Agentforce when an agent's work lives mostly in Salesforce, must respect your existing permissions, and benefits from Salesforce's built-in testing, monitoring and Trust Layer. Choose a custom agent on a model API, such as Claude, when the work spans several systems or runs outside the CRM. Many companies use both, connected through MCP or APIs. Make the decision one use case at a time, not once for the whole company.
What is the difference between Agentforce and a custom AI agent?
Agentforce is a platform you configure inside Salesforce. A custom agent is software your team or a partner writes, which calls a language model and the systems it needs.
With Agentforce, Salesforce supplies the reasoning engine, the builder, the testing tools and the security layer. You supply the job description, the knowledge and the actions, such as Flows, Apex and prompt templates. Our plain-English guide to Agentforce covers those parts in detail.
With a custom agent, you choose the model and write the loop around it. That code decides which tools the model may call, how it authenticates to each system, what it logs and where it runs. Anthropic's API, and cloud platforms such as Amazon Bedrock, give you access to Claude models for this kind of build. Everything around the model is yours to design, secure and maintain.
The line is not as sharp as it sounds. Claude is one of the models Agentforce can run on, and both sides now speak MCP. So the real question is less about which model and more about where the agent lives and who maintains it.
How do Agentforce, custom and hybrid agents compare?
Agentforce trades flexibility for speed and built-in controls. A custom agent trades those controls for freedom, and a hybrid tries to keep each where it is strongest.
| Agentforce | Custom agent (for example, on Claude) | Hybrid | |
|---|---|---|---|
| Data access | Native access to CRM records and knowledge; Data 360 or integrations for outside data | Whatever you connect through APIs or MCP servers; Salesforce is one source among many | Agentforce reads CRM data; the custom side reaches other systems, or each calls the other as a tool |
| Security and permission model | Runs as a configured agent user or the signed-in user, inside Salesforce sharing and the Einstein Trust Layer | You design it: integration users, per-user OAuth, secrets, masking and retention terms with the model provider | Two models to align; permissions must be tight on both sides of every connection |
| Where the agent runs | Inside Salesforce, on Salesforce channels such as web, messaging and voice | Your cloud account or application, or an assistant your staff already use | Split across both, joined by MCP or APIs |
| Build effort | Low-code configuration plus actions; effort grows with the number of new actions | Software development: tool code, prompts, hosting, logging and test harness | Highest overall, but each piece can stay small |
| Flexibility | Bounded by Salesforce's subagents, actions and supported channels | Very high: any model feature, workflow shape or interface | High, with Salesforce-facing steps kept inside Agentforce |
| Maintenance | Salesforce maintains the platform; you maintain instructions, knowledge and actions, and track releases | You maintain everything, including model upgrades, dependencies and infrastructure | Two maintenance tracks and the contract between them |
| Licensing model | Salesforce consumption (such as Flex Credits or per-conversation), per-user add-ons or editions, on top of CRM licenses | Model usage billed by tokens processed, plus your own hosting and any tool subscriptions | Both structures; watch for paying twice for the same work |
Licensing structure matters more than list price at this stage. Agentforce costs track agent actions, conversations or users. A custom agent's costs track how much text the model reads and writes, plus the infrastructure you run. Our article on Agentforce cost considerations explains the Salesforce side.
When is Agentforce the better choice?
Agentforce is usually the better choice when the agent serves your customers or staff inside Salesforce, and its actions change Salesforce records. Built-in controls save you from rebuilding security, testing and monitoring yourself.
- Customer-facing service on channels Salesforce already runs for you, with handoff to a person in the same console.
- Work grounded in Salesforce Knowledge and case, account or order records you already maintain.
- Actions that already exist as reliable Flows or Apex, so the agent reuses tested automation.
- Teams whose Salesforce admins will own the agent after launch, without a development team on call.
- Organizations that want audit, masking and testing from one vendor under one contract.
A biotech company we worked with fits this pattern. An Agentforce agent grounded in 19 knowledge articles drafted email replies and summarized cases. It produced send-ready drafts for 30% of question-type cases, and staff kept the final say. The rollout started internal-only on the most common case type.
A telecom-infrastructure contractor is another example. It had spent 60+ hours trying to extract data from inspection forms on its own. The proof of concept paired Salesforce Document AI with an Agentforce agent that answers natural-language questions about project cycle times and delays. The data and users were already in Salesforce.
When is a custom agent the better choice?
A custom agent is usually better when Salesforce is only one of several systems involved, or when the work does not fit Agentforce's shape. You gain freedom and take on the engineering and security work yourself.
- The main inputs live outside Salesforce, such as call transcripts, contracts, data warehouses or internal tools.
- The job is a long, multi-step analysis or document task rather than a conversation with a defined set of actions.
- You need a model feature, interface or deployment location that Agentforce does not offer.
- The output must feed several systems, with Salesforce as one destination.
- You have developers, or a partner, who can own the code, hosting and monitoring for as long as it runs.
Abstrakt Marketing Group, where our team first implemented and scaled Salesforce and today a client, shows this pattern. It uses Claude on Amazon Bedrock to turn call transcripts into structured summaries and score call quality. Grades, transcript excerpts and coaching notes are written back to Salesforce, calibrated against human-scored calls. The capabilities went into production in phases from May through July 2026. The source data was transcripts, not CRM records.
How does a hybrid approach work?
In a hybrid, Agentforce handles the steps that belong inside Salesforce, and a custom agent or assistant handles the rest. They connect through MCP or standard APIs, each under its own permissions.
Our guides to MCP and to Claude with Salesforce cover these patterns in depth:
- Claude inside Agentforce: select a Claude model for an agent or prompt template, keeping traffic within Salesforce's trust boundary.
- Outside assistant into Salesforce: an assistant such as Claude calls Salesforce-hosted MCP servers, which run each request as the signed-in user.
- Agentforce out to other systems: an agent calls tools on MCP servers that other systems publish, instead of custom integrations.
- Agent as a tool: an Agentforce agent is exposed as an MCP tool, so an outside assistant hands it Salesforce work.
- Middleware: a custom service reads Salesforce through its APIs, calls a model, and writes structured results back.
A payments company we worked with used the middleware and assistant patterns with Claude. Four connected workstreams covered recognition drafts, pipeline analysis, deal-evaluation support and a follow-up task pilot. The pilot created Salesforce tasks only with approval before each write and an audit trail. The engagement was delivered in August 2026.
Is Agentforce worth it?
Agentforce is worth it when a well-defined, repeated task already runs through Salesforce and you can measure the result. It is hard to justify when the data is unreliable, the task is rare, or most of the work sits in other systems.
Value depends on data quality, reliable actions and a clear job description more than on the platform. A custom agent faces the same test, plus the cost of building what Agentforce provides out of the box.
To answer the question for your own organization, run a narrow pilot against a baseline. Measure something you already track, such as handling time, drafts accepted without edits, or cases resolved without escalation. Then compare that value with the licensing and the ongoing effort to maintain the agent. The Agentforce readiness checklist helps you find the data and permission gaps before the pilot starts.
What should you look for in an Agentforce implementation partner?
Look for a partner who can explain when not to use Agentforce, and who starts with your data and permissions rather than a demo. Hands-on experience with both Salesforce and model APIs helps, because many projects end up hybrid.
- Production agents, not only proofs of concept, with references you can call.
- Relevant Salesforce certifications, such as Agentforce Specialist, alongside Data 360 and integration skills.
- If a custom or hybrid build is possible, real experience with the model provider's API and its data terms.
- A readiness review of data, knowledge, permissions and conflicting automation before any build.
- A written evaluation plan: test cases, a definition of a correct answer, and a pass threshold.
- Willingness to recommend a Flow or a conventional integration when an agent is not needed.
- Separate estimates for licensing and delivery effort, so you can judge each on its own.
- A handover plan that names who monitors the agent after launch and how your team learns to extend it.
Ask each candidate to walk through an agent they built that went wrong, and what they changed. It shows their testing discipline.
How should you evaluate and govern either kind of agent?
Evaluate both kinds of agent the same way. Use a fixed test set before launch, human review after it, and a named owner who can pause the agent. The tools differ, but the discipline does not.
On Agentforce, Testing Center runs batches of test interactions in a sandbox, and Salesforce audit and feedback data show what agents did. For a custom agent, you build the equivalent yourself. That means a test harness, logs of every tool call, and a way to replay past conversations after you change a prompt or model.
- Build test cases from real history, including requests the agent should refuse or hand off.
- Define what a correct answer looks like before you look at results.
- Start read-only, and require human approval for each write until the agent earns more trust.
- Retest after every change to instructions, knowledge, actions or the underlying model.
- Review handoffs and errors on a fixed schedule, with one owner per agent.
- Keep an inventory of every agent, connection and permission set, and review it with your other access reviews.
Our guide to AI governance for Salesforce sets out the policies to agree before launch. They apply to both kinds of agent.
How do you decide for your first use case?
Answer a few questions about the task, and the platform usually follows. Where the answers point both ways, a hybrid is often the honest answer.
- Where does the data the agent reads live: mostly in Salesforce, or mostly elsewhere?
- Who uses it: customers on Salesforce channels, staff in Salesforce, or staff in another tool?
- What does it change, and in which system?
- Who will maintain it: Salesforce admins or developers?
- Which licensing structure fits your volume: per action, per conversation, per user, or per token?
- How will you know it works, and who reviews the results each week?
Pick one task with steady volume and low risk if the agent errs. Build it on the platform the answers point to, measure it honestly, and widen scope only when the results justify it.

