When Salesforce announced Headless 360 at TDX 2026, it changed the question architects should be asking. It’s no longer “should we build a custom experience or stay inside the native Salesforce UI?” It’s how far up the stack you go, from the experience layer into AI reasoning and orchestration, before you step outside the platform’s governance umbrella of security enforcement, compliance controls, business logic, and AI trust controls. That boundary has real consequences.
Choosing where to put the intelligence layer in your CRM is no longer a theoretical exercise. With Headless 360, Salesforce enables architects to decouple the experience layer from Salesforce-native interfaces. This represents the biggest shift in Salesforce architecture in 25 years toward composable experiences and AI-driven interaction models. Virtually everything on the platform is now accessible via an API, Model Context Protocol (MCP) server, or CLI command.
For two decades, there was a tight coupling between the Salesforce platform and its UI. Customization meant building Lightning components. The assumption was that users would interact through the Salesforce UI.
That assumption is evolving. MCP enables any compatible AI agent to connect to Salesforce, query records and execute actions, while interacting with users in natural language. But this is an expansion narrative, not a replacement narrative. The traditional UI and the conversational interface both operate on the same platform, enforce the same rules, and access the same data.
When you click a button in the Salesforce UI to update an opportunity stage, the platform validates permissions, checks field-level security (FLS), applies sharing rules, and fires every trigger and automated flow. When an AI agent makes the same update through an API, the platform runs the identical sequence. There is no lighter security path for programmatic access.
The Salesforce data model is not a simple relational database. It is a graph of business entities with enforced relationships, field types, record types, formula fields, and rollup summaries. Building an equivalent from scratch would take months before you even reached the application layer. Every approach covered in this post operates on this same foundation.
Security operates at multiple levels simultaneously: org-level restrictions, profile-based object and field permissions, sharing rules, role hierarchy, and Shield encryption for data at rest. This enforcement applies at the API level, not the UI level. Whether a request comes from a browser, a REST API call, or an MCP tool, the same permissions apply. In regulated industries, uniform access enforcement is a regulatory requirement regardless of architecture.
Flows, triggers, validation rules, and approval processes fire consistently regardless of access method. If an AI agent calls an MCP tool to update an opportunity stage, every flow and every validation rule fires exactly as if a human made the change in the standard UI. The business logic is not an attribute of the interface. It is an attribute of the platform.
The Einstein Trust Layer is where the architecture decision forks. The first three layers enforce identically across all approaches. The Trust Layer, available through Agentforce, adds four capabilities that are particularly relevant for regulated industries: Personally Identifiable Information (PII) masking before prompts reach the model, prompt injection defense, toxicity and relevance filtering, and audit logging of every interaction.
For financial services institutions, building equivalent governance independently represents years of engineering and ongoing recertification with every model update. This is not a feature to evaluate. For customer-facing and compliance-sensitive deployments, it is a prerequisite.
The reasoning layer is where natural language understanding, tool selection, and response generation occur. It can be delivered through Agentforce with Bring Your Own LLM (BYOLLM) support, or through direct API integration with any provider, bypassing Agentforce entirely. The choice of reasoning layer is independent of the layers below it.
Whether reasoning happens inside Agentforce or inside a custom API route, the same data model, security rules, and business logic govern what the model can access and what actions it can take. The key decision is whether the reasoning layer needs to operate inside the Trust Layer’s governance perimeter. That requirement points to Agentforce. Everything else is a build-versus-buy question.
The experience layer is what the user sees. It can be the standard Salesforce Lightning UI, a Lightning Web Component, a standalone React app, a Slack bot, a mobile app, or no dedicated interface at all. This layer has the least impact on governance and the most impact on adoption. A custom front end and the standard Salesforce UI hit the same APIs, enforce the same permissions, and trigger the same business logic. Select it based on who the user is and what workflow they are performing. The governance lives in the platform, not in the pixels.
Layers 1 through 4 constitute the core Salesforce platform. Industry solutions like Agentforce Financial Services deliver compounding value across all four layers: prebuilt data models, security rules, business logic, and AI governance designed for the regulatory context that data exists in.
Explore the Salesforce Architecture Center for deeper guidance on designing trusted, scalable solutions across these layers.
Understand where the new platform capabilities fit within established Salesforce integration patterns, and what shifts when agents become consumers of your org.
Each approach leverages the bottom three platform layers identically. They differ in where the intelligence layer lives, whether the Trust Layer is included, and how much UI control you retain.
You build a standalone MCP server and a custom React or Next.js front end. Use this when you need total control over the user experience and unlimited tool flexibility. The tradeoff is the highest build effort and ongoing maintenance responsibility.
You replace your custom MCP server with a Salesforce Hosted MCP Server while keeping the same front end. Use this when you want centralized tool management with custom UI control. The tradeoff is that tool definitions are managed by the Salesforce administrator, not your development team. The swap between approaches A and B is a single configuration change, not a rewrite.
You build Lightning Web Components (LWC) inside Salesforce that embed AI chat panels via Apex callouts. Use this when your users already live in Salesforce and you want the fastest, lowest-cost path to AI. The tradeoff is that the UI is constrained by the LWC framework and Salesforce design system.
Salesforce manages the agent framework, the Trust Layer, and the tool routing. You choose the model. Use this when you need Trust Layer governance for compliance-sensitive interactions. The tradeoff is cost: Agentforce licensing plus model inference fees from your LLM provider.
You use Agentforce APIs on the back end but surface results through a custom-built front end. Use this when you need both Trust Layer coverage and full UI control. The tradeoff is the same licensing cost as Approach D plus the build effort of a custom experience layer.
Salesforce controls the model, the routing, the Trust Layer, and the UI. Use this when you want Trust Layer coverage without engineering investment. The tradeoff is the least flexibility in model selection, tool design, and user experience.
A common architectural mistake is treating these approaches as mutually exclusive. Enterprise CRM architecture is compositional. Because the platform enforces role-based access controls, governance, and security consistently across every access method, you can match the interface to the user rather than forcing everyone onto a single path.
Consider a midsize bank. Their 200 relationship managers get AI embedded in the Salesforce UI (Approach C). Their executives get a custom dashboard (Approach A or B). Their customer-facing chatbot runs through Agentforce with Trust Layer coverage (Approach D or E). Their internal analytics team queries CRM data conversationally (Approach C or A).
Four deployments. Four experience layers. One platform. The same data model, security rules, and business logic govern every interaction.
For financial services institutions, the Trust Layer is a prerequisite for certain deployment scenarios.
When AI interacts with customer-identifiable data in contexts that could influence financial decisions, four things must be true:
Approaches A, B, and C satisfy the first requirement through per-user OAuth and Salesforce security controls. The remaining three require either the Trust Layer or building equivalent governance independently. Not every AI interaction requires the Trust Layer. Apply it selectively for customer-facing and compliance-sensitive use cases while using lighter approaches for internal productivity.
The sequencing of your architectural adoption should reflect where your organization is today, not where it aspires to be. These are starting points to recognize, not categories to be assigned.
If you have deep platform investment, start by activating the Trust Layer across your existing AI workflows (Approaches D, E), then explore custom experiences for specific audiences. If you have multiple disconnected AI pilots, governance consolidation is your most urgent priority. If you are under pressure to demonstrate ROI, start with outcomes: one relationship manager recovering 45 minutes per day across 200 relationship managers translates to roughly $2.7M in annual productivity value. Prove it with a focused Approach C pilot. If your environment is heavily customized, your existing automations are the guardrails that make AI safe to deploy. And if you have a substantial existing investment in hyperscaler engineering, the composition framework offers coexistence: AI reasoning on your cloud, workflow execution and data governance on Salesforce, connected through MCP.
Explore the Agentforce Developer Guide to understand how MCP, the Agent API, and prompt templates work together across these approaches.
The future of CRM is not a conversation replacing a click. It is conversations and clicks and dashboards and agents, all operating on a shared, governed platform.
The organizations that get this right will not be the ones that picked the best single approach. They will be the ones that understand the stack deeply enough to compose the right combination for each context.
Get hands-on with Agentforce Basics on Trailhead to start building governed AI experiences on the Salesforce platform.
Get monthly curated content, technical resources, and event updates designed to support your Salesforce Architect journey.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。