Agentforce Alternatives: Custom vs CRM-Native Agents

Agentforce is a good product for the job it was built for. That job is agents that work on data and workflows inside Salesforce.

If your work lives in Salesforce, start there. If your data sits in a warehouse, an ERP, a ticketing tool, or a pile of documents, Agentforce alternatives are worth a look. One option is a custom agent.

This post is for teams in the second group. I will be fair to the platform, because most of what it does well is real.

What CRM-Native Agents Do Well

A CRM-native agent runs inside the system that already holds your customer records, permissions, and workflows. That gives it real advantages.

• Shared data and permissions. The agent reads the same objects your reps use, under the same sharing rules. You do not build a second access model.
• Existing workflow hooks. Flows, cases, and approvals are already there. The agent can call them.
• Fast first pilot, when the task fits. Support deflection on your own knowledge base, lead follow-up, case summaries, and record updates are the home turf.
• One vendor to call. Billing, security review, and support sit with a company you already trust.
• Trust features. Salesforce documents zero data retention agreements with its LLM partners. Agentforce 3, announced in June 2025, added a Command Center for observability and native support for the Model Context Protocol, so agents can call outside tools.
• A testing tool. The Agentforce Testing Center lets you run batches of test utterances from a CSV file.

HubSpot, Microsoft, ServiceNow, and Zendesk follow the same logic in their own platforms. HubSpot, for example, charges $0.50 per resolved conversation for its Customer Agent. For Microsoft’s side, see Copilot Studio vs custom AI agents.

My rule: if the task is mostly “read and write CRM records and talk to a customer,” buy the native agent first. Prove it fails before you build around it.

Where the Boundary Hurts

The platform edge shows up when the real work does not stay inside the platform.

Common signs:

• The answer needs data from three or four systems. Order status in an ERP, contract terms in a document store, usage in a warehouse, and the account in the CRM.
• The process has steps the platform’s builder cannot express. Long approval chains, rules that change by customer, or branching that needs real code.
• You need an action the platform has no connector for, and the effort to add one is higher than the value.
• You need to choose the model, the prompt structure, or the retrieval method for accuracy or cost reasons.
• You need a hard guarantee that some step never happens without a person approving, and the platform controls do not map to your policy.

None of these is a defect in Agentforce. They are limits of any platform-shaped product. The question is how many of your workflows hit them.

A data point on realism. Salesforce AI Research published CRMArena-Pro in May 2025. In its tests, leading LLM agents reached about 58% success on single-turn CRM tasks and about 35% on multi-turn ones. That is Salesforce’s own benchmark, run on general models, not a score for Agentforce. But it tells you something that applies to every option here, native or custom: multi-step CRM work is hard, and you must test on your own cases.

Data Outside the CRM

Salesforce has an answer for external data. Its Data 360 (formerly Data Cloud) zero copy feature federates queries to warehouses like Snowflake, Databricks, BigQuery, and Redshift, so agents can use that data without copying it in. Agentforce 3 also added an MCP client for outside tools. If your external data already sits in one of those warehouses, this is a real option. Test it before you rule it out.

It gets harder in these cases:

1. The data is not in a warehouse. It is in an ERP, a legacy database, a document share, or a vendor portal.
2. The data is messy. It needs cleaning, joining, or interpretation that is specific to your business.
3. Latency or freshness matters. Live queries to a remote system add delay, and a source outage becomes an agent outage.
4. You do not want that data under another vendor’s governance. Some teams need the data to stay in their own network for contract or regulatory reasons.

A custom agent connects to the sources directly. It can run in your cloud account. It can use a different model for different steps. The price is that you now own the build, the tests, and the on-call.

For the wider build-or-buy question, see build vs buy for AI agents. For the CRM side of revenue work, see AI agents for RevOps and CRM.

Cost Shape

I will not quote today’s list prices as fact, because Salesforce changes them and I cannot verify your contract. I can show you the shape.

When Salesforce introduced flexible pricing on May 15, 2025, it described the earlier $2 per conversation model and a new Flex Credits model. Under Flex Credits, one action uses 20 credits, which the company priced at $0.10, and credits come in packs of 100,000 for $500. Check the current price sheet before you plan. Pricing has shifted before and may shift again.

Here is a hypothetical to show how the shapes differ. Say an agent handles 10,000 conversations a month and averages 4 actions per conversation.

• Per conversation at $2: 10,000 x $2 = $20,000.
• Per action at $0.10: 10,000 x 4 x $0.10 = $4,000.

The point is not the dollars. The point is that your cost depends on what unit you are billed on, and on how many actions your agent takes per task. A chatty, tool-heavy agent costs more on a per-action meter.

For a custom agent, the cost has different parts:

• Model usage (tokens), which scales with volume and context size.
• Hosting and monitoring.
• Build cost, once.
• Maintenance: prompt changes, model upgrades, new connectors, and tests.
• Your people’s time to review and fix.

A fair comparison covers all of those, over 12 to 24 months, for the same workflow and volume. Platforms look cheaper at low volume and in the first quarter. Custom builds can look cheaper at high volume and over a longer period, but only if you count the maintenance honestly. For a worksheet, see AI agent development cost.

Control, Logs, and Testing

This is where I see the largest practical gap, and it is about what you can inspect.

Ask both sides the same questions:

Question	CRM-native agent	Custom agent
Can I see every prompt, tool call, and result?	Depends on the platform’s logs and the tier	Yes, if you build the logging
Can I replay a failed case?	Limited to what the platform exposes	Yes, if you store inputs and versions
Can I run my own regression tests on every change?	Platform test tools, such as the Testing Center	Your own eval suite in CI
Can I pin the model version?	Platform decides	You decide
Can I enforce hard limits in code?	Within platform controls	Anywhere in your tool layer
Who is on call when it breaks?	Vendor for the platform, you for your config	You

Neither column is better in every row. A platform gives you tested, shared infrastructure. A custom build gives you full visibility and also full responsibility.

Whichever you pick, require three things:

1. A test set from your real cases. At least 50 to 100 past tickets or tasks with known good outcomes.
2. A pass bar before launch, such as a target resolution rate and a zero-tolerance list (never issue a refund over a limit, never state a price).
3. Full action logs you can read and export.

See the glossary entry on agent evaluation for how these tests work.

Lock-In and Exit

Lock-in is not only about contracts. It is about where your logic lives.

With a CRM-native agent, your prompts, topics, actions, and data mappings live in the vendor’s builder. If you leave, you rebuild them. Your data stays in your CRM, which is good. Your agent logic does not travel.

With a custom agent, your logic is in your code. You can swap the CRM, the model, or the host. But you also carry the risk of a build that only one engineer understands.

Ways to reduce lock-in either way:

• Keep business rules in plain documents and tests, not only inside prompts.
• Keep an exportable copy of your test set and your action definitions.
• Use open standards where they exist, such as MCP for tool connections.
• Keep tool actions thin: a small function per action, with the logic in a service you own.
• Write the exit terms down before signing. See AI agent ownership and exit rights.

A hybrid is often the right answer. Let the CRM-native agent handle the in-CRM work. Let a custom agent handle the cross-system work and expose it to the CRM as one tool. That way each side does what it is good at.

Decision Table

Your situation	Lean toward	Why
Task lives inside Salesforce objects and flows	CRM-native	Same data, same permissions, fastest start
Data is already in a warehouse Salesforce federates	CRM-native, then test	Zero copy may cover it
Answer needs 3+ systems, including ones with no connector	Custom	Direct connections, your logic
Strict rules on where data can go	Custom, in your cloud	You control the boundary
Need to pick or pin the model, or swap it later	Custom	Model choice is yours
Small team, no engineers to maintain code	CRM-native	Less to own
High volume, stable workflow, per-unit pricing hurts	Custom, after a cost model	Unit costs can favor custom
Mixed: some in-CRM, some cross-system	Hybrid	Native for CRM, custom as a tool

Five questions to settle it:

1. Where does the data for this workflow live today?
2. How many systems does one task touch?
3. What happens if the agent is wrong, and who must approve?
4. What does 12 months cost on each path, at my real volume?
5. If I leave in two years, what do I take with me?

Bottom Line

CRM-native agents win when the work stays in the CRM. Custom agents win when it does not.

Do not decide on features lists. Decide on where the data lives, how many systems a task touches, and what you can test and exit.

Next step: pick one workflow, write down its data sources, and count the systems. One system, start native. Three or more, price out a custom or hybrid build.

FAQ

What are the alternatives to Agentforce? There are three groups. Other CRM-native agents, such as HubSpot’s Customer Agent or Microsoft’s agent tools. Workflow and agent platforms that connect to many systems. And custom agents built on a model API and your own code. The right group depends on where your data lives and how many systems a task touches.

When is a CRM-native agent enough? When the task reads and writes CRM records, uses your knowledge base, and follows workflows that already exist in the platform. Support answers from your own articles, lead follow-up, and case summaries are common fits. If you can test it on real cases and it passes, there is no reason to build.

What if data sits outside the CRM? First check whether the platform can reach it. Salesforce Data 360 can federate queries to major warehouses, and Agentforce 3 supports MCP tools. If your data is in an ERP, legacy system, or documents with no connector, a custom or hybrid agent usually fits better.

How do costs compare? Platforms charge by unit, such as conversations or actions, and are cheaper at low volume. Custom agents have a build cost, model and hosting costs, and maintenance. Compare 12 to 24 months at your real volume. Check current vendor prices, since they change.

How do I avoid lock-in? Keep business rules and test sets outside the vendor’s builder, use open standards like MCP for tool connections, keep actions thin, and write exit terms into the contract. A hybrid design also helps, because the cross-system logic stays in code you own.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect