Agentforce vs Custom AI Agents: When to Configure and When to Build

Short answer: configure Agentforce when the job is a bounded set of actions on data Salesforce already holds. Build a custom agent when the hard part is the reasoning rather than the action, or when the decisive data lives outside the CRM. Most serious deployments end up doing both, with a deliberate seam between them.

What is the actual difference?

• Agentforce is Salesforce's agent layer. It runs on the Atlas Reasoning Engine, is configured rather than coded, and inherits the platform's identity, sharing model, audit trail and governor limits (Agentforce Developer Guide).
• A custom AI agent is software you own: your model choice, your retrieval, your tools, your orchestration, running wherever you want, against whatever systems you have.

The trade is not "easy versus powerful". It is bounded and governed against unbounded and yours. Both are the right answer roughly half the time.

When should you configure Agentforce?

Configure when most of these are true:

• The data that decides the answer is already in Salesforce, or is landing in Data 360.
• The work is CRM-shaped: case deflection and routing, service replies, opportunity hygiene, scheduling, guided sales actions.
• The actions are enumerable. You can list what the agent is allowed to do, and the list is short enough to write on a whiteboard.
• Governance is the hard requirement. Permissions, sharing and audit come free because the agent is inside the platform.
• You have admin capacity. Someone fluent in Flow, permission sets and the data model will get further, faster, than a team of engineers starting cold.

The compounding reason people miss: an agent inside the platform inherits the platform's security model. Rebuilding that in a custom stack is expensive and easy to get subtly wrong.

When should you build a custom agent?

Build when any one of these is true, because each is individually disqualifying for a configure-only approach:

• The decisive data is not in the CRM. Telemetry, ERP, documents, ticketing, a warehouse, a device fleet. If the agent needs to reason over all of it, the CRM is one source among many.
• The reasoning is the product. Multi-step analysis, planning, ranked recommendations with justification, or anything where the answer needs defending rather than executing.
• The workflow is not a CRM workflow. Operations, engineering, supply chain, field diagnostics.
• You need model choice. Different tasks want different models, and you do not want that decision made for you.
• The agent must run where the users are, and the users are not in Salesforce.

What is the one test that settles most cases?

Write the agent's job as a list of actions. If you can, and every action reads or writes something Salesforce already knows, configure. If the hard part is deciding which action, on evidence from several systems, build.

That test is faster than a bake-off and it is honest about the failure modes. Configure-only projects fail when a bounded action list turns out to need unbounded judgement. Build-only projects fail when a team spends a quarter reimplementing sharing rules, audit trails and case management that were already there.

Why is the answer usually both?

Because the two layers want different jobs. Agentforce is a good surface: it sits where service and sales people already work, with the platform's governance around it. A custom agent is a good brain for anything that has to reason across systems. Connect them, and each does what it is good at.

That seam is now a first-class platform concern rather than a hack. Salesforce ships Model Context Protocol interfaces in its own tooling, including a Salesforce DX MCP Server behind the next generation of DevOps Center (Salesforce Help). Agent-to-agent handoffs and MCP action hubs are how a governed CRM agent calls specialist agents without either side swallowing the other.

This is the architecture we build most often at Tekunda. We are a certified Salesforce SI, ISV and PDO and an Anthropic partner, we were first to put Agentforce agent-to-agent orchestration and SWARM architecture into production, and we build headless CRM and MCP action hubs so agents can act across systems from one place. On the connected-device side, our work for ASSA ABLOY cut weekly cases from 3,000 to 350, a 93% reduction across 11,000 devices and up to 2.5 million events per week, in three markets with no added support staff. See how we work.

How do you decide without a six-month bake-off?

1. Write the action list. Ten minutes, on a whiteboard, with the people who do the job today.
2. Mark the data source next to each action. Count how many sit outside Salesforce.
3. Ask what breaks if the agent is wrong. High blast radius pushes toward the governed platform layer.
4. Pilot the smaller half first. Whichever side is bounded, ship that, and let the seam wait until the value is proven.

FAQ

Is Agentforce enough on its own?

For CRM-bounded work on Salesforce data, usually yes. It stops being enough when the decisive evidence lives in systems Salesforce does not own.

Can a custom AI agent work with Agentforce rather than replace it?

Yes, and that is the common pattern. Agentforce holds the governed CRM surface, custom agents handle cross-system reasoning, and they hand off to each other.

Does building custom mean giving up Salesforce governance?

Only if you architect it that way. Keep CRM writes going through platform actions and you keep the sharing model and audit trail intact.

What is the most common mistake in this decision?

Choosing on cost. The two paths converge on total cost more often than people expect; the durable difference is whether the work is bounded.

Where should a first project start?

With one workflow that has a clear owner and a measurable before-number. Agent projects that begin as platform strategy tend not to finish.