One Question Reveals Whether Your Salesforce Partner Can Build AI That Actually Scales
Jul 27, 20265 mins read
Every partner evaluation checklist covers certifications, methodology, and post-go-live support. None of them surfaces the architectural difference that determines whether your AI program outlasts the pilot.
The Salesforce partner evaluation market is not short of frameworks. Certifications, tier status, industry experience, delivery methodology, post-go-live support model, change management capability: the criteria are well-documented, and most of them are legitimate. They separate partners who know the platform from partners who are still learning it on your budget.
What they don’t do is separate the partners who can build enterprise AI that works at pilot scale from the ones who can build enterprise AI that works at production scale. That distinction doesn’t show up in AppExchange reviews or certification counts. It shows up in one specific architectural conversation, and most partner evaluations never have it.
The Question
Ask every Salesforce partner you evaluate: “How do you separate the reasoning layer from the execution layer in an agentic deployment, and how does your governance model survive that separation?”
Then stop talking and listen carefully.
A partner with a real answer will describe an architecture, not a product. They will tell you which Salesforce capabilities get exposed at the execution layer, through which governance controls, under which permission model, and they will tell you that these decisions are made before any AI system is selected or configured. They will explain how the governance structure remains intact regardless of which reasoning capability they deploy on top of it.
A partner without a real answer will describe Agentforce. They will talk about agent topics, agent actions, prompt templates, and consumption planning. They may mention guardrails. They will not describe a structural separation between the system that reasons and the system that executes... because they have not built one. What they have built is a single-layer architecture in which the agent both reasons and acts as one undifferentiated function.
That architecture produces impressive demos. It does not produce durable enterprise AI programs.
Why the Separation is the Structural Test
The reasoning layer and the execution layer have fundamentally different requirements, and confusing them is the most reliable architectural mistake in enterprise AI deployment today.
The reasoning layer, whether that is Agentforce, a custom large language model, Claude, Copilot, or any combination of AI systems your organization deploys, needs flexibility. It needs to interpret ambiguous inputs, adapt to novel scenarios, incorporate new capabilities as the AI market evolves. Constraining the reasoning layer with governance requirements limits exactly the capability that makes AI valuable.
The execution layer (the Salesforce permissions structure, approval chains, audit trails, business logic, data governance controls) needs to be airtight. It is the layer that your compliance team, your legal team, and your security team care about. It cannot be flexible in the same way. It must behave predictably regardless of what the reasoning layer asks it to do.
When those two layers are collapsed into one, governance becomes a constraint on AI capability rather than an independent property of the system. Every new agent capability requires a governance re-evaluation. Every governance requirement eliminates AI options you have not yet considered. The architecture that was supposed to accelerate your AI program becomes the thing that prevents it from scaling.
The organizations that are building AI programs with genuine operational durability have recognized this. They are not choosing between capability and governance. They have built the architecture that makes that choice unnecessary: an execution layer with governed, stable Salesforce interfaces, and a reasoning layer free to evolve as AI capabilities do.
What the Bridge Between Them Looks Like
The technical mechanism that enables the separation to work is Model Context Protocol (MCP) an open standard that defines precisely how AI systems in the reasoning layer communicate with external tools and data sources in the execution layer. For Salesforce-invested organizations, MCP is what allows any AI system to call a Salesforce workflow, trigger an approval, update a record, or read governed data while the full Salesforce permission model, security controls, and audit trail remain completely intact.
The significance of MCP being an open standard rather than a proprietary integration mechanism is not incidental. It means the organization’s governance decisions and AI vendor decisions are structurally decoupled. You can evaluate and deploy the best available reasoning capability for any use case without rebuilding your governance architecture around that evaluation. Your Salesforce execution layer does not change when your AI strategy changes. That is the architectural freedom the separation provides, and it is what a partner who has built this correctly will be able to explain with specificity.
A partner who cannot explain exactly how MCP operates as the governed bridge between their AI deployment and your Salesforce environment (not in general terms, but with precision about permission structure, audit continuity, and execution boundaries) has not built the separation. They have built a tighter integration. Tighter integrations work until they don’t.
The Evaluation Becomes Simple
Most Salesforce partner evaluations ask the right questions and still produce the wrong answer, because the evaluation criteria are optimized for the deployment problem rather than the architecture problem. Certifications tell you whether the partner knows the platform. Methodology tells you whether they can manage a project. Case studies tell you whether they have done this before.
None of them tells you whether the partner has thought seriously about what happens when your AI program needs to grow: when the pilot agent proliferates into a dozen use cases across business units, when your organization needs to swap reasoning models, when governance requirements evolve alongside regulatory pressure.
The question about layer separation tells you that. The answer reveals whether the partner is building you an AI deployment or an AI architecture. Only one of those compounds.