Headless 360 vs Agentforce: An Architect's Decision Matrix
Half the people at TDX used "Headless 360" and "Agentforce" interchangeably. They are not the same thing. One is the foundation your house sits on. The other is the house. Confusing them is how you end up renovating the roof when the problem is the plumbing.
I have been building Salesforce orgs for 14 years. I watched the TDX 2026 keynote with the same question most architects had: what is the actual relationship between these two things, and what breaks if I get it wrong?
Here is the breakdown.
What Headless 360 Actually Is
Salesforce announced Headless 360 on April 15, 2026 at TrailblazerDX in San Francisco. The core idea: every capability on the Salesforce platform is now exposed as an API, MCP tool, or CLI command. Agents and coding tools can access the full platform without ever opening a browser.
This includes your data, your workflows, your business logic, your sharing model, and your security controls. All of it is callable by machines.
Headless 360 is organized around four layers that Salesforce's EVP Jayesh Govindarjan described to VentureBeat:
- System of Context (Data 360): Your unified customer data, now accessible via API
- System of Work (Customer 360 apps): Sales Cloud, Service Cloud, Nonprofit Cloud, all callable
- System of Agency (Agentforce): Where agents are built and orchestrated
- System of Engagement (Slack): Where humans interact with agent output
Headless 360 is the plumbing that connects all four layers. It is infrastructure.
What Agentforce Actually Is
Agentforce is the application layer. It is where you configure an AI agent, define its behavior through AgentScript, set its guardrails, assign it a topic scope, and deploy it to a surface (Slack, a website, a mobile app, or a voice channel).
Think of it this way: Agentforce is the agent. Headless 360 is what the agent operates on.
Before Headless 360, Agentforce agents could do specific tasks within the Salesforce UI. After Headless 360, Agentforce agents (and any external agent built with Claude Code, Cursor, or Codex) can access the entire platform without the UI.
The Decision Matrix
When you are making architecture decisions, the question is not "Headless 360 or Agentforce." The question is which layer your problem lives in.
| Decision | Use This | Why |
|---|---|---|
| "I need an agent to handle customer service cases" | Agentforce | You are building an agent application |
| "I need Claude Code to read my org metadata and generate Flows" | Headless 360 (MCP tools) | You are giving an external tool API access to your platform |
| "I need to expose Salesforce data to a non-Salesforce agent" | Headless 360 (APIs) | You are connecting infrastructure to an external system |
| "I need to control what an agent can and cannot do" | Agentforce (AgentScript + Agent Fabric) | You are governing agent behavior |
| "I need my agent to work in Slack, not the Salesforce UI" | Both | Agentforce builds the agent. Headless 360 + Experience Layer renders it in Slack |
Where Confusion Causes Real Damage
The risk I see in the field is organizations treating Agentforce as the whole story and skipping the infrastructure conversation.
If your data governance is not ready for API-scale operations, deploying an Agentforce agent will amplify every data quality problem you already have. The agent inherits your validation rules, your permission model, and your sharing rules. If those are not built for machine-speed consumption, the agent will create problems faster than humans can fix them.
The inverse is also true: building Headless 360 API integrations without Agentforce's governance layer (AgentScript, Agent Fabric, Session Tracing) means running agents without guardrails. That is how orgs end up with unauthorized data modifications and no audit trail.
What to Do Right Now
Before you activate either capability, audit your org for agentic readiness. Check these four areas:
- Are your validation rules designed to return structured API errors, not just UI messages?
- Is your integration user following least-privilege Permission Set assignments?
- Do you have a documented rollback plan for bulk agent-created records?
- Is your data governance machine-readable (consistent picklist values, standardized field formats)?
If the answer to any of these is no, start there. The infrastructure conversation (Headless 360) and the application conversation (Agentforce) both depend on the same foundation: clean data, tight permissions, and documented governance.
Key Takeaways
- Headless 360 is infrastructure. Agentforce is the application. They are complementary, not interchangeable. TDX shipped 60+ MCP tools and 30+ coding skills across both layers.
- Headless 360 exposes your entire platform via APIs, MCP tools, and CLI commands. Agentforce is where agents are built, governed, and deployed. The four-layer architecture (Data 360, Customer 360, Agentforce, Slack) connects through Headless 360.
- Architecture decisions should start at the infrastructure layer (is your data agent-ready?) before moving to the application layer (which agent should I build?). In 14 years of implementations, I have never seen an org fail because the agent was wrong. I have seen orgs fail because the data was wrong.
- Pricing for Headless 360 has not been disclosed. Do not build architectural dependencies on features that may require additional SKUs. The free Developer Edition trial (110 requests/month, 1.5M tokens) expires after May 2026.
- Start with the AI Readiness Scorecard to identify gaps before activation. The scorecard evaluates 15 weighted questions across 5 categories to produce a 0-100 baseline.
