Salesforce Headless 360: What Enterprise Admins Actually Need to Know (2026)
Salesforce Headless 360 turns the entire platform into API-accessible infrastructure for AI agents. Here's what actually shipped at TDX, what's still beta, and what to test first.
TLDR: Salesforce Headless 360, announced at TDX 2026, is an architectural shift that exposes the entire Salesforce platform — CRM, Agentforce, Data Cloud, Slack — as APIs, MCP tools, and CLI commands. AI agents can now operate Salesforce without a browser or a human intermediary. The core @salesforce/mcp package and sf agent CLI commands are generally available as of April 2026; some toolsets remain in beta. For enterprise Salesforce admins and architects, this is not optional reading: it changes how agents interact with your org, what API limits apply, and what governance controls you need to put in place before your dev team starts pointing Claude Code or Cursor at production data.
Why This Matters Now
Salesforce has been building toward an “agent-first” architecture for two years. Headless 360 is where that intent became concrete infrastructure.
Announced at TDX 2026 on April 15, Headless 360 is Salesforce’s answer to a problem that was becoming existential: AI coding agents (Claude Code, Cursor, Codex, Windsurf) and enterprise automation platforms were increasingly working around Salesforce’s UI-first architecture rather than through it. Developers were screen-scraping, building brittle integration layers, or — in the scenario Salesforce explicitly named — replacing CRM workflows with “vibe-coded” alternatives that bypassed the platform entirely.
Headless 360 makes the full platform accessible programmatically: 60+ MCP tools for metadata, data, testing, and DevOps; 30+ preconfigured coding skills for common Salesforce development tasks; Agent Script for deterministic agent behavior; and the Agentforce Experience Layer for deploying agents across surfaces like Slack, Teams, and ChatGPT. The browser is now optional, not required.
For enterprise IT and Salesforce administration teams, the implications split into three areas: what new things are now possible, what governance risks this introduces, and what you should actually test before your developers do.
What Headless 360 Actually Includes
| Component | What It Does | GA Status |
|---|---|---|
@salesforce/mcp server | 60+ MCP tools covering metadata, data, LWC dev, testing, DevOps | GA (April 2026) |
sf agent CLI commands | Manage Agentforce agents from terminal; no UI required | GA (April 2026) |
| Agent Script | DSL for deterministic agent logic; open-sourced | GA |
| Agentforce Experience Layer (AXL) | Deploy agents to Slack, Teams, ChatGPT, Claude, Gemini surfaces | GA |
| Testing Center enhancements | Identify logic gaps and policy violations pre-deployment | GA |
| A/B Testing API | Compare agent versions in production | GA |
| Session Trace OTel API | OpenTelemetry-based session observability | GA |
| Agentforce Mobile SDK | Embed Agentforce in mobile apps | GA |
| Agent Fabric | Centralized governance plane for agent visibility and auditability | GA |
| Some specialized toolsets | Additional MCP tool categories, expanded coding skills | Beta / Developer Preview |
| React native support on platform | Goodbye Lightning-only constraint for UI development | GA |
The split between GA and beta matters for enterprise planning. The core headless access pattern — connecting Claude Code or Cursor to a Salesforce org via the MCP server — is production-ready. Some edge-case MCP tool categories are still in developer preview and should not be used in production workflows yet.
The Three Pillars: Build Any Way, Deploy Anywhere, Trust at Scale
Salesforce frames Headless 360 around three principles. Here is what each means in practice.
Build Any Way
Before Headless 360, building on Salesforce meant working within Lightning Web Components, Salesforce DX, and a set of frameworks that required Salesforce-specific knowledge. Headless 360 breaks that constraint.
The @salesforce/mcp server exposes 60+ tools organized into functional categories: metadata operations (create, update, deploy), data operations (query, insert, update records), LWC development (generate components, lint, test), code analysis, and DevOps (CI/CD pipeline integration). Any AI coding agent that supports MCP — Claude Code, Cursor, Codex, Windsurf — can now connect directly to a Salesforce org and operate it through these tools.
The practical effect: a developer can point Claude Code at a Salesforce org and say “create a custom object with these fields and wire it to this Apex trigger,” and the agent can execute that work entirely through the MCP server, with no browser required. Salesforce is explicitly competing with the “start from scratch in a modern stack” impulse by making its platform accessible in the same way those stacks are accessible.
Earned insight: The dev experience shift here is real, but it surfaces an existing governance gap. In environments where Salesforce DX and connected app permissions are already well-managed, adding MCP access is a straightforward extension of existing controls. In environments where dev orgs are loosely governed — sandbox sprawl, shared credentials, undocumented connected apps — the MCP server becomes a new attack surface before IT has a chance to establish policy. The orgs that will have problems are the ones that already have problems; Headless 360 just makes those problems faster.
Deploy Anywhere: The Agentforce Experience Layer
The Agentforce Experience Layer (AXL) solves a different problem: agent deployment fragmentation. Previously, an Agentforce agent deployed in Salesforce Service Cloud lived in Service Cloud. Getting it into Slack, Teams, or a third-party chat surface required custom development for each channel.
AXL provides a “deploy once, render anywhere” architecture. An agent authored in Agentforce can be published to Slack, Microsoft Teams, WhatsApp, ChatGPT (via GPT action), Claude, and Gemini. The agent’s logic — its topics, actions, and data connections — stays in Salesforce. The rendering layer adapts to each surface.
For enterprise automation teams running hybrid Microsoft + Salesforce environments, this has immediate practical value. A case management agent built in Agentforce can surface directly in Teams channels without a separate integration build. The Google Cloud partnership announced alongside Headless 360 extends this further: Gemini agents can call Agentforce actions via the MCP bridge, and Agentforce agents can invoke Google Cloud AI services, creating true cross-platform agent workflows.
Trust at Scale: Einstein Trust Layer and Agent Fabric
The governance story is where Headless 360 differentiates from a raw API strategy. Two components matter here.
Einstein Trust Layer applies to every Agentforce interaction, regardless of whether it comes from a browser or an API call. It cannot be disabled. Its protections — data masking for PII before prompts reach external LLMs, zero-data retention policies with third-party model providers, field-level security enforcement that matches existing user permissions — apply to headless agent sessions the same way they apply to UI sessions.
One nuance enterprises should verify: data masking for LLM prompts is currently disabled by default for certain agent configurations. If your agents are processing data covered by GDPR, CCPA, or HIPAA, confirm your masking settings before enabling headless agent access to production data.
Agent Fabric is the newer addition: a centralized governance plane that makes all agents running in the Salesforce platform visible, auditable, and manageable from a single location. It surfaces which agents are active, what data they have accessed, and what actions they have taken. For enterprises deploying more than a handful of agents, Agent Fabric is the equivalent of the agent registry in Microsoft Agent 365 — the minimum viable governance layer before agent sprawl becomes unmanageable.
Warning: Standard Salesforce API limits apply to all headless agent interactions. For Enterprise Edition orgs, the default is 100,000 REST API calls per 24-hour rolling window, pooled across all API types. An active LLM agent running complex data queries can exhaust this limit faster than a developer expects — especially in testing, where iterative agent runs generate disproportionate API traffic. Monitor API consumption in the early weeks of any headless integration and consider purchasing additional API call allocations before production rollout.
Agent Script: Determinism for Probabilistic Agents
Agent Script deserves its own section because it addresses the most common enterprise objection to AI agents in production: unpredictability.
LLM-based agents are probabilistic by nature. Given the same input twice, they may take different paths. In a customer service context, that variation might be acceptable. In a finance or legal workflow — where the agent is approving invoices, routing escalations, or extracting contract terms — it is not.
Agent Script is a domain-specific language for defining explicit agent behavior: if this condition, then this action, with these guardrails. It is open-sourced (github.com/salesforce/agentscript) and integrates directly with the Agentforce Testing Center, which can validate Script logic before deployment and flag deviations in production through Session Trace.
The practical implication: for high-stakes workflows, enterprises now have a path to agents that combine LLM intelligence for natural language understanding with deterministic execution paths for the actions that follow. This hybrid architecture — probabilistic interpretation, deterministic action — is where serious enterprise agent deployments are heading.
What to Test This Week
For Salesforce architects and admins evaluating Headless 360, here is a prioritized starting sequence:
1. Connect the MCP server to a sandbox org. The @salesforce/mcp package installs via npm. Connect it to a Developer Edition or sandbox org first — not production. Run a few metadata queries through Claude Code or Cursor to validate the connection and understand what the tool calls look like in Session Trace.
2. Audit your connected app permissions. The MCP server authenticates through a connected app in your org. Review which connected apps currently have broad API access and apply least-privilege scoping before enabling headless agent access.
3. Verify data masking settings. In Setup, check your Einstein Generative AI settings and confirm whether data masking is enabled for agent prompts in your org configuration. If your org processes personal data, this is not optional.
4. Explore Agent Fabric in a sandbox with existing agents. If you have Agentforce agents already deployed, Agent Fabric provides the first comprehensive view of what they are doing. Use it in sandbox to validate that the audit trail matches your expectation of agent behavior.
5. Defer production MCP access until governance is in place. The MCP tools are GA and stable, but “stable” is not the same as “governed.” Treat production MCP access like you would any new privileged API connection — scoped credentials, audit logging enabled, change management process in place.
Tip: If your org is evaluating Microsoft Agent 365 alongside Headless 360, the governance frameworks complement each other. Agent Fabric covers the Salesforce side; Agent 365 covers the broader Microsoft ecosystem including any Salesforce agents surfaced through the Agentforce Experience Layer into Teams or other M365 surfaces. The two tools are designed to interoperate, not compete.
What This Means for the Broader Enterprise Stack
Headless 360 has implications beyond Salesforce teams.
For AIOps and IT operations teams: the Session Trace OTel API means Agentforce sessions can now export telemetry in OpenTelemetry format, which integrates directly with Datadog, Dynatrace, New Relic, and any other OTel-compatible observability platform. This closes a major gap — previously, Agentforce sessions were largely invisible to enterprise monitoring tools.
For CPQ and billing teams: Salesforce has explicitly included Data Cloud and Revenue Cloud in the Headless 360 API surface. Revenue intelligence workflows that currently require human-in-the-loop steps — quote generation, contract term extraction, billing reconciliation — can now be handed to agents that run entirely through the API layer, with Einstein Trust Layer protecting sensitive deal data.
For enterprise automation teams running Workato or MuleSoft integrations: the MCP tools reduce the need for custom integration code for common Salesforce operations. Evaluate which integration patterns in your current stack could be simplified by connecting your automation platform directly to the @salesforce/mcp server.
Bottom Line
Salesforce Headless 360 is a structural change to how the platform works, not a feature release. The fact that the core @salesforce/mcp package is generally available as of April 2026 means this is not a roadmap item to monitor — it is a capability you can evaluate today.
The enterprise opportunity is real: AI agents that can operate Salesforce natively, without browser automation or custom integration layers, represent a meaningful reduction in the cost and fragility of complex CRM workflows. Agent Script’s determinism model addresses the production-readiness concern that has blocked many enterprise agent deployments.
The governance work is non-negotiable. API limits, data masking settings, connected app permissions, and Agent Fabric configuration are not post-GA concerns — they are prerequisites for using the headless surface responsibly. Start with sandbox validation, build your governance baseline, then move to production.
For Salesforce architects evaluating where to invest attention in 2026, Headless 360 is the architecture shift that makes everything else in the Agentforce roadmap coherent. Get familiar with it now.
Related Articles
Discussion