Most companies pick an AI agent architecture without realising there is a choice. See why the wrong architecture is the primary reason Salesforce AI projects stall at the three-month mark, and how to choose the right one before you build.
Key Takeaways:
- There are three distinct architectures for AI agents in Salesforce: Agentforce (native), Claude agents via MCP (cross-system), and custom AI agents (bespoke)
- Agentforce is the right choice when the use case lives entirely inside Salesforce and a Data 360 foundation is in place
- Claude agents via MCP are the right choice when the AI needs to read from or write to systems outside Salesforce, such as an ERP, data warehouse, or custom application
- Custom AI agents make sense when the workflow is too specific for either standard option, but this applies to the minority of cases
- Choosing the wrong architecture before you build is the primary reason AI agent deployments stall at the three-month mark
The Architecture Decision Nobody Warns You About
Somewhere between the Salesforce demo and the signed contract, a critical decision gets skipped. Not the budget decision. Not the project timeline. The architecture decision: which type of AI agent you are actually building, and whether that type is right for what the business actually needs.
Most companies do not make this choice deliberately. They default to Agentforce because it is Salesforce-native and the AE is confident about it. Or they hear about Claude agents via MCP at a tech conference and want to try it. Or they hand it to a development team who builds something custom because that is what they know.
Each of those paths produces a working AI agent. The problem is that a working agent built on the wrong architecture is still the wrong architecture. You will hit its constraints, usually around month three, when the use case expands and the agent cannot reach the data it suddenly needs.
From our experience, most AI agent projects that stall do so not because the technology failed, but because the architecture did not match what the use case actually required. The good news: this is entirely avoidable if you ask the right questions before you start.
There are three real options. Here is what each one is for.
Option 1: Agentforce: When Your Agents Live Inside Salesforce
Agentforce is Salesforce's native AI agent platform, launched at Dreamforce in October 2025. It is purpose-built to operate within the Salesforce environment: reading from Salesforce records, triggering Salesforce workflows, and responding through Salesforce channels.
When it is the right choice:
- Your use case is entirely contained within Salesforce data: service case deflection, sales qualification, lead routing, contract renewal reminders
- You have a Data 360 (formerly Data Cloud) foundation in place, with clean, unified customer data
- The agent needs to take actions inside Salesforce, such as updating records, creating cases, or triggering approvals, rather than reading from external systems
When it is the wrong choice:
- Your use case requires data from outside Salesforce: inventory from SAP, ticket history from a custom helpdesk, shipment status from a third-party logistics platform
- Your Data 360 layer is not yet built. Agentforce agents draw their intelligence from the unified data layer. Without it, they work from incomplete records.
The most common Agentforce mistake we see: a company deploys an Agentforce service agent before their Salesforce Data Cloud implementation is complete. The agent has access to Contact and Case objects but no unified activity history, no cross-channel interaction data, no accurate account health scores. It gives responses that are technically drawn from Salesforce data, but that data is insufficient for the questions customers are actually asking.
Build the Salesforce Data Cloud implementation first. Then deploy the agent on top of it. That is the sequence that produces a reliable result.
For companies with the right Data 360 foundation, Agentforce implementation services cover service deflection, sales agent workflows, and operational automation natively inside the platform, without needing additional infrastructure outside Salesforce.
Option 2: Claude(or openAI) Agents via MCP: When Your Agents Need to Work Across Systems
MCP stands for Model Context Protocol: an open standard for connecting AI models to external systems. Where Agentforce operates inside Salesforce, a Claude/OpenAI MCP server agent can operate across Salesforce and any other system you connect it to, including ERP platforms, data warehouses, custom applications, and third-party APIs.
This is the option most buyers have not heard of yet. It is also the option that fits a surprisingly large share of real-world use cases.
Here is the thing: most mid-market companies run their operations across more than one system. Their sales pipeline is in Salesforce. Their inventory is in SAP or Oracle. Their finance data is in NetSuite. Their support history might be in a custom-built platform. An AI agent that can only read Salesforce is an agent that can only answer a subset of the questions it will actually be asked.
A Claude/OpenAI MCP server agent can pull context from Salesforce, query the ERP for inventory availability, check the data warehouse for historical purchase patterns, and respond with a complete picture, all within a single agent workflow. The agent does not live "in" any one system. It connects to all of them through defined MCP server connections.
When it is the right choice:
- The use case requires data from multiple systems, not just Salesforce
- You want AI agents that can take actions across systems, not just surface information
- Your team is already investing in Claude or OpenAI infrastructure for other use cases
When it is the wrong choice:
- Your use case is genuinely self-contained within Salesforce. MCP adds integration overhead you do not need.
- Your team has no existing Claude or OpenAI deployment or API familiarity
Option 3: Custom AI Agents: When Neither Standard Path Fits
Custom AI agents are bespoke builds: an AI workflow engineered from scratch for a specific business process that neither Agentforce nor a standard MCP connection can cover natively. Think of a multi-step underwriting qualification agent for a speciality insurance workflow, or a product configuration agent that works across a proprietary CPQ system and a manufacturing database.
This is the right option for fewer companies than it sounds. Custom agents require the most build time, the highest ongoing maintenance cost, and the deepest technical involvement. They produce the most precisely fitted result, but only when the use case genuinely cannot be served by the first two options.
The question to ask: "Can Agentforce or a Claude or OpenAI MCP agent cover 80% of what we need, with some configuration?" If yes, start there. The remaining 20% of edge cases rarely justifies the full custom build. If the answer is genuinely no, because the workflow is too specific, too unusual, or too deeply tied to a proprietary system, then a custom agent is the right answer.
From our experience, custom AI agents are the right call in roughly one in five engagements. The other four out of five resolve to Agentforce or MCP once the use case is properly scoped.
Three Questions to Choose the Right Path
Before your team commits to any AI agent architecture, answer these three questions.
1. Does the use case live entirely inside Salesforce data? If yes: Agentforce is the native path. Check whether your Data 360 layer is ready before building. If no: you need MCP or a custom build.
2. Do you have a Data 360 / Salesforce Data Cloud foundation in place? If yes: Agentforce is a realistic option. If not: building Agentforce on incomplete data produces an unreliable agent. Address the data layer first, or start with a Claude MCP agent that works with the data you already have accessible.
3. How specific is the workflow? If it fits standard Salesforce automation patterns such as case deflection, sales qualification, or lead routing: Agentforce. If it needs to cross systems: MCP. If it is genuinely unique to your business model: custom build.
These questions are not a formula. They are the starting point for an architecture conversation. The right answer depends on your current data infrastructure, your integration landscape, and what you are actually trying to automate. Experienced Salesforce consulting partners will work through this before writing a line of configuration, because rebuilding on the wrong architecture costs more than the design conversation upfront.
Ready to work out which architecture fits your use case? Talk to our Salesforce team and we will scope the right path before you build.
Frequently Asked Questions
1. What is the difference between Agentforce and a Claude/OpenAI MCP server agent?
Agentforce is Salesforce's native AI agent platform. It operates within Salesforce, reads from Salesforce data (particularly Data 360), and takes actions inside Salesforce workflows. A Claude/OpenAI MCP server agent is built using the Model Context Protocol, which allows the agent to connect to multiple systems simultaneously: Salesforce, ERP, data warehouses, and custom applications. The right choice depends on whether your use case lives inside Salesforce or across multiple systems.
2. Does Agentforce require Salesforce Data Cloud?
Yes, in practice. Agentforce agents draw their intelligence from the unified customer data layer in Salesforce Data 360 (formerly Data Cloud). Without a clean, unified data foundation, Agentforce agents work from incomplete or inconsistent records. Most experienced implementation teams build the Data 360 layer before deploying agents on top of it.
3. How long does an Agentforce implementation take?
Timeline varies by complexity and data readiness. For a service deflection agent on an org with a working Data 360 layer, a scoped implementation typically runs 8 to 12 weeks. If the Data 360 setup is included, add 6 to 10 weeks to the front of the project. The most reliable predictor of timeline is data readiness, not agent complexity.
4. What is MCP and why does it matter for Salesforce?
MCP (Model Context Protocol) is an open standard for connecting AI agents to external systems. It allows a Claude or OpenAI agent to read from and write to any connected system, not just Salesforce. For mid-market companies running operations across Salesforce, SAP, NetSuite, or custom platforms, MCP server agents can deliver AI workflows that cross system boundaries in ways Agentforce natively cannot.
5. Which option is right for a mid-market company just starting with AI agents?
For most mid-market companies: start with Agentforce if your use case is contained in Salesforce and your Data 360 foundation is solid. Start with a Claude MCP agent if the workflow crosses systems. Avoid custom builds until you have a clear use case that genuinely cannot be served by the first two options.
