Reading Time: 5 minutes
A client asked me a version of this question a few months back: why can’t their AI agent just update an opportunity, check an entitlement, and kick off a case escalation all at once, without anyone having to open a browser?
At the time, the honest answer was “you can get close, but you’re going to fight the platform the whole way, because Salesforce was built for a human clicking through screens, not a bot calling an API.” That answer changed earlier this year. Salesforce announced Headless 360, and it’s the most direct admission I’ve seen from them that the UI is no longer the platform’s primary interface. APIs, CLI, and MCP tools are.
I want to explain what’s actually different and how to implement it without creating a governance mess. There’s a lot of vendor language floating around this launch. I’m going to skip most of it and focus on what you’d need to know to sit down and build something.
What’s Headless 360 changes
Headless 360 isn’t one feature. It’s Salesforce exposing everything it built over 27 years, most of it previously accessible only through Lightning pages, now available via programmatic access instead. Concretely: a new Salesforce MCP server (@salesforce/mcp), 60+ MCP tools grouped into toolsets, 30+ prebuilt coding skills, and an expanded set of REST and GraphQL endpoints under the Connect API.
The MCP toolsets are worth knowing by name because they map directly to what an agent can and can’t touch:
Toolset | What it does |
|---|---|
metadata | Deploy and retrieve metadata between a project and an org |
data | Run SOQL against a live org |
testing | Execute Apex tests and agent evaluation tests |
lwc | Scaffold Lightning Web Components and generate Jest tests |
code-analysis | Static analysis through Salesforce Code Analyzer |
devops | CI/CD pipeline access via DevOps Center |
aura | Migration guidance for orgs still running Aura components |
Point Claude Code, Cursor, Windsurf, or whatever coding agent your team uses at the Salesforce MCP server, and it can query the org, deploy a class, run the tests, and read back results, all without a browser tab open. That’s the part demos always show. The part that matters more and gets skipped in demos is how access is scoped and audited once you’re not the one clicking “Save.”
Salesforce is describing the underlying architecture as five systems:
- System of Context: Data 360 plus MuleSoft and Informatica, unifying data where it lives instead of copying it around
- System of Work: The accumulated automation, object model, and permission logic
- System of Agency: Agentforce’s runtime, which brokers requests from any external agent
- System of Engagement: Workflows surfaced in Slack and similar tools
- System of Insight: Tableau wired into execution rather than sitting off to the side as a dashboard
The detail I want to highlight for architects specifically is that field-level security, sharing rules, and permission sets are automatically inherited by any caller of the MCP server. You don’t rebuild your trust model per agent. You extend the one you already have, assuming it was sound to begin with, which for a lot of orgs is a separate conversation.
Authentication and access, the part nobody puts in the keynote
If you’re actually using the system, the authentication story matters more than the toolset list. Two things I’d insist on before an agent touches anything beyond a scratch org:
- Use Named Credentials so authentication details stay out of your code and, just as important, out of the agent’s context window. You do not want a service account’s secret sitting in a prompt history.
- Scope the Connected App tightly. It’s tempting to grant broad scope during a proof of concept and forget to narrow it before go-live. Don’t do that.
On the data side, everything routes through the Einstein Trust Layer regardless of which door you came in through: browser, API, or MCP. That means PII masking before anything reaches an external LLM, zero-data-retention terms with model providers, and grounding checked against the org’s actual permissions at query time. It’s explicitly not something you can switch off, which I think is the right call given how easy it would be to misconfigure otherwise.
On limits: standard Enterprise Edition orgs still cap around 100,000 API calls in a rolling 24-hour window, 100 SOQL queries per transaction, 150 DML statements per transaction, and the usual 10-second sync / 60-second async CPU ceiling. An agent making dozens of tool calls per conversation turn will burn through these differently than a human clicking through screens ever did. Load test your implementation before you find out about it in production.
How to implement Headless 360
- Map what’s UI-locked before you touch anything else. Anywhere business logic lives inside a screen flow or a page layout’s controlling logic rather than in Apex or a callable Flow, that’s your first refactor target. Headless 360 rewards a clean split between logic and presentation, and most orgs older than a few years have some of both tangled together.
- Stand up MCP in a sandbox first. Connect an agent to a non-production org, scope the toolset narrowly (start with data and metadata, add more once you trust the guardrails), and put it under the kind of load an agent actually generates: bursty, repetitive, occasionally weird queries. That traffic pattern isn’t the same as human click-through behavior, and your rate-limit math needs to account for it.
- Route deployments through DevOps Center’s MCP, but keep the change management. Natural-language deploy commands are convenient. They still need approvals, rollback plans, and environment gating, same as any pipeline. “It’s just a prompt” is not an exemption from your release process.
- Write evaluations before you write the agent. Testing Center and Custom Scoring Evals exist so you can define correct behavior up front, the same discipline as writing test cases before code, instead of discovering the failure mode from an angry customer.
- Rebuild your cost model. Salesforce is moving Agentforce toward consumption-based pricing rather than pure per-seat licensing. If your business case still assumes headcount-driven cost, it’s already out of date. Instead, budget against expected agent call volume.
Business impact and where this is headed
There’s a bigger story behind the release than a feature list. Enterprise software valuations have taken a real hit, driven partly by the fear that a company could just vibe-code a CRM replacement with an LLM instead of paying for one.
Headless 360 is Salesforce’s counterargument: 27 years of business logic, object models, and trust boundaries aren’t something a general-purpose agent can recreate from a blank prompt, so the smart move is to make that logic agent-accessible rather than hiding it behind a UI nobody wants to build from scratch either way.
The early number that stuck with me: Engine, a B2B travel management company, built a customer service agent that now handles half its cases autonomously and did it in 12 days, rather than the months a comparable build used to take. I’d expect variations of that story to become the standard pitch over the next few quarters, and, more usefully for delivery teams, the standard client expectation they’ll be measured against.
Where the product goes next is probably deeper MCP coverage across Marketing Cloud, Commerce, and the Industries clouds; some kind of formal standard for agent-to-agent handoffs, rather than everyone building bespoke orchestration; and the Trust Layer extending to cover more third-party models as adoption spreads beyond Anthropic and OpenAI.
Mphasis Silverline works with organizations to develop and build the architecture they need to take full advantage of solutions like Headless 360. We can help your team navigate the interconnected ecosystem of operational systems, enterprise data, integrations, models, and agents that can make these implementations so complex, offering expert guidance rooted in industry knowledge. To learn how we can assist with your specific business case, use the chatbot on your screen to connect with a member of our team.
