TL;DR | The Highlights
- There isn’t one way to build an AI agent against Salesforce. There are two, and the choice isn’t about which is better. It comes down to who the user is and whether the work is event-driven or conversational.
- Agentforce is the Salesforce-native option, built for client-facing and event-driven work. An AI platform such as Claude, connected through a Salesforce-hosted MCP server, puts the AI in the reasoning seat for internal, conversational work.
- The dividing line can run straight through a single use case. The same need might be served one way on demand, and the other way when it has to fire automatically.
- Client inquiry resolution: a very common use case most people picture when they hear AI agent, splits cleanly across both models, as an example. And the financial services industry changes what a good answer is.
- To establish the trust required for a more autonomous configuration, begin with the minimum level of autonomy that provides actual value, using a “suggest-and-review” approach.
While the transition to autonomous agents applies to almost any industry where a customer exists across many records, we are focusing on financial services today. If you work in this sector, you’ve probably been told you need an AI agent. The harder question, and the one that actually decides whether it works, is which kind you should build.
Because there isn’t one, but two ways to do this. And the choice between them isn’t about which is better. It comes down to who the user is, and whether the interaction is event-driven or conversational.
Let’s get into it.
There Isn’t One Way to Build an AI Agent. There Are Two.
Agentforce is a Salesforce-native agent. It lives inside the org, and it’s the right tool for two situations: client-facing surfaces, like a self-service agent on an Experience Cloud site or in-app messaging, and event-driven automation, where something happens in the org and a Flow triggers the agent with no human in the loop. The agent is part of Salesforce.
An AI platform such as Claude, connected through a Salesforce-hosted MCP server, works the other way around. It puts the AI in the reasoning seat, with Salesforce connected as a tool it can read from and act within. This is the right fit for internal users, including relationship managers, operations, and compliance staff, working conversationally from Slack, the platform’s own interface, or a custom surface. Here, the agent is the preferred AI platform. Salesforce is something it reaches into.
That’s the line running through nearly every use case. Event-driven and client-facing lean Agentforce. User-initiated and internal leans an AI platform plus MCP.
What people miss is that the line can be cut within a single use case. The same need can be served by an AI platform plus MCP when a user asks for it on demand, and by Agentforce when it has to fire automatically. We’ll see exactly that play out below.
In the AI Platform Plus MCP Model, What Matters Is Who Authored the Write
When an AI platform writes to Salesforce through MCP, the work sorts into three tiers. The thing that separates them is who authored the write:
- Tier one: “Read only” → The AI observes and never writes. No custom code, fast to stand up, and the natural place to begin. Most read-and-synthesize work lives here.
- Tier two: “Existing automation as tools” → The AI triggers automation a human already built and reviewed, like a Flow or an Apex class, exposed as a tool with a fixed input contract. The human authored the logic and its guardrails. The AI only supplies the inputs and triggers the run.
- Tier three: “AI-authored write” → The AI decides the object, fields, and values at the moment of writing. This handles changes nobody could have listed in advance, which is what makes it both the most flexible tier and the one that carries the most risk.
One safeguard sits underneath all three: every tier runs as the connected user and enforces that user’s permissions on every call. Field-level security, sharing rules, and validation rules all run regardless of tier. If the connected user can’t see a field, neither can the AI.
One caution: these tiers (who authored a write) are a different scale from the levels of autonomy below (how much the agent does on its own). They don’t line up, so consider them independently.
The Use Case Everyone Pictures Is the One Financial Services Complicates Most
Customers ask questions about accounts, products, statements, fees, transactions, and processes. Volume is high, repetition is high, and the inquiries that need a human are mixed in with the ones that don’t. This is the use case most prospects picture when they hear AI agent, and it’s the one most often demoed as a knowledge-search chatbot.
In financial services, that generic pattern doesn’t survive contact with compliance. Five things change:
- The answer often depends on customer context, not just a knowledge article. Even a simple question about a fee or a rate can resolve differently depending on the customer’s situation. In a wealth context, “what’s the fee on the Growth Portfolio?” turns on account type, relationship tier, and breakpoint eligibility. In lending or payments, the equivalent turns on the customer’s product, risk band, or negotiated terms. The knowledge article is one input. The answer is computed.
- Some questions can never be answered. Advice-seeking intent, like “should I move my RRSP to a TFSA?” in wealth, or “should I refinance now?” in lending, needs a dedicated topic that returns an educational handoff, not a knowledge search, no matter what the knowledge base contains.
- Compliance attaches to the response, not just the case. Forward-looking statements, performance projections, comparisons, and guarantees can turn an accurate answer into a violation. Response-side guardrails are required, which is a big enough subject that it gets its own article next.
- Case creation needs structure. When the agent escalates, it has to capture intent (complaint, service request, transaction error, KYC update for example), route to the right team, and set the right SLA. Some of those SLAs carry regulatory deadlines.
- Identity and entitlement are rarely one person to one account. Before any account-aware topic triggers, the agent has to resolve who is actually asking and what they’re entitled to see, and the shape of that varies by sub-sector: a wealth household with joint, trust, and power-of-attorney access; a commercial-banking customer with a parent company, subsidiaries, and authorized signers; or a customer of a B2B fintech with many users at different permission levels. Whatever the shape, resolve it wrong and you’ve leaked information across an entitlement boundary.
This is why there’s no generic AI build to hand you. The right approach has to fit your engagement model, and most (if not every) financial services organization has a particularly distinct one, as does any business where one customer shows up across many records and sources; from SaaS to manufacturing to professional services. It starts with mapping the actual use case, not reaching for a one-size-fits-all agent.
For Client Inquiry Resolution, the Surface Decides the Build
Client inquiry resolution splits cleanly across both models.
The client-facing self-service version is Agentforce. You don’t put an AI platform connector in front of retail customers, and the surface is client-facing and partly event-driven, which is Agentforce’s home ground.
The internal version is an AI platform plus MCP. A service rep researching a customer and drafting a response from Slack is doing tier-one read work: pulling account context, history, and entitlements, with an optional tier-two call to a vetted case-creation Flow when an inquiry has to be escalated. For that assist scenario, an AI platform plus MCP is a lighter build than configuring an Agentforce agent, and synthesis across scattered records is exactly where it’s strongest.
Start at the Lowest Level of Autonomy That Delivers Value
How much autonomy you give the agent is a function of risk tolerance and earned trust. Start at the lowest level that delivers value, then graduate from there.
- Level one: Suggest.
The agent drafts a response from knowledge plus customer context, and surfaces what data it used, what it deliberately did not say, and any compliance flags it caught. A human reviews and sends. The mark of a good level-one agent in financial services is that it shows its work. Reviewers see the inputs, the guardrails that fired, and the omissions, not just a finished draft. - Level two: Execute with approval.
The agent responds directly for a defined whitelist of low-risk inquiry types: statement requests, basic product information, transaction history within entitlement, fee or rate information with customer-specific values applied. Anything outside the whitelist drafts and routes to a human. The whitelist is the product. Defining what the agent is allowed to handle on its own is half the engagement, and it gets compliance involved early. - Level three: Autonomous with monitoring.
The agent owns the full inquiry lifecycle within a defined policy envelope, including multi-turn clarification and follow-up. Humans monitor through sampling-based QA, exception alerts, and aggregate KPI drift. At this level the agent is running a regulated business process, so it needs the same supervisory infrastructure as a human rep: review queues, retention, and audit trails, not just a chat log.
Level three is genuinely a stretch goal for most firms today. Level one and level two are where the defensible value lives.
The Build Almost Chooses Itself
Notice what the whole decision keeps coming back to. Not which AI is smartest, but who initiates the interaction, where it lives, and how much you’re ready to let it do on its own. Get those three right, and the approach to building almost chooses itself.
That leaves one question we’ve set aside: once an agent is drafting or sending responses in a regulated environment, what keeps it inside the lines? That’s compliance guardrails, and it’s big enough to deserve its own piece. It’s where we’re headed next.
In the meantime, if you’re weighing which of these builds fits the use case in front of you, that’s the mapping we do before a single agent gets configured. Let’s chat.
Let's chat!
