For twenty years, Salesforce has been a place where people go to work. You log in, you find the record, you update the field, you run the report. The interface was a screen. The user was a human.
Now, times are changing.
With Salesforce’s Headless 360 architecture and the Model Context Protocol (MCP), the interface is becoming an AI agent. Salesforce is evolving from a CRM your reps click through into infrastructure that your AI tools call directly.
Headless 360 is available now, it is production-ready for early movers, and the companies that understand it first will build a meaningful edge over those who figure it out in 2027.
What Headless 360 Actually Is
Headless 360 is a permissions engine, a data model, a workflow automation layer, a compliance framework, and an API platform. What Headless 360 formalizes is the idea that all of that should be accessible without the browser in the middle.
“Headless” just means the data and logic layer decouples from the presentation layer. “360” refers to the full scope of customer data, process, and analytics that Salesforce manages. Together, the architecture lets AI agents, developer tools, and external applications call Salesforce capabilities directly through APIs, MCP tools, and CLI commands.
The key word here is “directly.” An agent does not need a user to open a tab, find the right object, and enter information. The agent calls the tool, the tool executes against the Salesforce data model, and the result comes back under Salesforce’s own authentication and permission controls.
This matters because the permission and governance infrastructure Salesforce spent decades building does not get bypassed.
MCP Is the Protocol That Makes This Real
Model Context Protocol is an open standard that lets AI systems call tools in a structured, auditable, and permission-aware way. Salesforce has built hosted MCP servers that expose specific capabilities as callable tools: reading records, creating or updating data, invoking Lightning Flows, calling approved Apex code, querying Data 360, and running analytics through Tableau Next.
An AI assistant like Claude connects to a Salesforce Hosted MCP Server through an External Client App, authenticates with OAuth and PKCE, and then calls only the tools that the organization has approved. Field-level security, sharing rules, and object permissions all apply. The agent operates inside your security model, not around it.
For developers and admins, the Salesforce DX MCP Server adds a separate path: natural-language workflows for building LWCs, deploying metadata, running tests, analyzing Aura components, and managing release pipelines without leaving the development tool.
For data teams, the Data 360 MCP Server exposes Data 360 APIs through the same tool-call pattern, letting agents and developers interact with unified customer profiles, identity rules, calculated insights, and segmentation without writing raw API calls by hand.
The Bigger Shift: AI Moves to the Front, Salesforce Moves to the Back
Salesforce has historically competed on the strength of its interface. Better UI, better workflow, better experience. That competition is no longer the only game.
The new competition is about which platforms become trusted infrastructure for AI systems to act on. And on that question, Salesforce has a real argument: decades of customer data, a mature permission model, a workflow engine that understands business process, and now a protocol layer that lets AI agents call all of it safely.
What this opens up is a model where an AI assistant like Claude becomes the primary interface your team uses to interact with customer data. Instead of navigating to an account record, a rep asks a question and gets a summary of risks, last activity, renewal status, and next best action. Instead of a service agent clicking through entitlement rules, an AI agent reads the case, checks the policy, invokes a Flow, and drafts the response.
For CIOs, this is a governance question as much as a capability question. The organizations that get this right will have AI that operates inside sanctioned boundaries with full audit trails. The organizations that get it wrong will have AI tools hitting Salesforce through shadow integrations and custom REST wrappers with no visibility into what is being accessed or changed.
For CROs and RevOps leaders, the opportunity is an AI layer that can actually act on CRM data, not just summarize it. An agent that can update opportunity hygiene, create follow-up tasks, surface at-risk deals, and check quote status does something that a chatbot trained on static data cannot.
For data leaders, it means the unified customer profile in Data 360 becomes something AI can query in real time, not just a reporting asset a human reviews in a dashboard.
What This Requires to Work Well
The technology is ready for pilots, today. The underlying org might be a different story…
MCP exposes whatever Salesforce contains. If your data model is messy, your fields are inconsistent, your automations conflict with each other, and your permission sets are a decade of accumulated exceptions, you will accelerate all of that noise. The agent will reflect the org back at you, clearly and quickly.
Before you connect an AI system to Salesforce, the work that matters most is:
- Governance design. Which tools should be exposed? Read-only queries first. Create and update actions only for trusted use cases. Delete and financial-impact actions last. Not every user should connect every AI client to your org.
- Data quality. If an AI agent is summarizing account health, the account data needs to be current and accurate. Garbage in, garbage out moves faster with an AI in the loop.
- Security configuration. External Client Apps (not Connected Apps) handle MCP client authentication. OAuth scopes, PKCE, refresh token rotation, and permission-set gating all need deliberate configuration. Default is not safe enough for production.
- Use case selection. The teams that succeed start with one narrow, low-risk, high-value workflow. Account briefing before a customer call. Case triage for tier-one service. Opportunity hygiene for a specific pipeline stage. They prove value, measure it, and expand.
A Practical Starting Point
The first 30 days should be a structured pilot.
Week one is inventory and education. Identify three to five workflows where an AI agent having live access to Salesforce data would save meaningful time or reduce errors. Review your current licenses against what each use case actually requires. Agentforce and Flex Credits cover agent-driven actions. Data 360 requires a separately enabled org. Tableau Next MCP requires a Tableau Next entitlement. Get licensing clarity before building.
Week two is selection. Pick one workflow and commit to it. Account briefing is the most common starting point because it is read-only, immediately useful, and easy to measure.
Week three is configuration. Build the External Client App, set up permission-set gating, configure a read-only SObject MCP server, define Named Queries to give the agent a narrow data view, connect one approved AI client, and establish an audit path.
Week four is measurement. Time saved, quality of output, adoption rate, and any incidents or access issues. Use that data to decide whether to expand or refine.
What Plative Does Here
Plative works with companies across the full arc of this: from early-stage readiness assessments through production Agentforce deployments, Data 360 implementations, and MCP governance design.
We run MCP readiness assessments that inventory org security, data model health, automation complexity, and AI use case fit. We run two-to-four week pilots that connect a safe MCP client to one specific workflow with proper access controls. We design the tooling and permission architecture that lets your AI systems scale without creating governance debt.
The goal is to make sure the right Salesforce capabilities are exposed to the right AI agents, with the right controls, in a way that creates real business value.
If you want to understand where your org stands and what a first pilot would look like, start there.