Design Headless AI Experiences on Salesforce

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.

Recognize where the real platform value lives

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.

Understand platform enforcement, regardless of entry point

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.

This architectural property underpins every approach outlined in this post. Decompose the platform into six layers to see how it works.

Layer 1: Data model and relationships

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.

Layer 2: Security

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.

Layer 3: Deterministic business logic

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.

Layer 4: The Einstein Trust Layer

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.

Layer 5: AI and LLM reasoning

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.

Layer 6: Experience layer

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.

Evaluate six approaches to AI-powered CRM

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.

Approach A: Custom MCP server with custom front end

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.

Approach B: Salesforce Hosted MCP Server with custom front end

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.

Approach C: Standard Salesforce UI with AI extensions

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.

Approach D: Agentforce with BYOLLM

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.

Approach E: Agentforce back end with custom front end

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.

Approach F: Agentforce fully managed

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.

Compose the right combination for your user populations

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.

Determine when the Trust Layer is required

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: 

• the AI only sees authorized data, 
• PII is masked before reaching the model, 
• responses are filtered for unsolicited advice, 
• and every interaction is logged for examination.

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.

Sequence your adoption based on your starting point

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.

Start composing your architecture

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.

Five principles to guide your composition:

1. Start with the user, not the technology. Map your user populations before selecting approaches.
2. Use the platform as the constant. Do not duplicate business rules in custom front ends.
3. Apply the Trust Layer where it matters, not everywhere. Selective application reduces cost while maintaining regulatory coverage.
4. Consolidate before you expand. Unify governance across AI pilots before adding capabilities.
5. Build for composability; avoid architectures that close off future migration paths. MCP enables migration paths that do not exist with traditional integration patterns.

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.