Parker Harris stood on the TDX 2026 keynote stage on April 15 and asked a question that would have been heretical five years ago. Why should you ever log into Salesforce again? It landed as a rhetorical question. It arrived as a roadmap.

Over the next 48 hours, Salesforce shipped more than 100 new tools and skills, open-sourced a new programming language, unified three marketplaces into one, and declared that every layer of the platform is now programmable from any surface. This is not a feature release. This is the first real architectural pivot the platform has made in a decade.

The framing from Jayesh Govindarjan, EVP at Salesforce, was telling. He described the platform as four layers: a system of context (Data 360), a system of work (Customer 360 apps), a system of agency (Agentforce), and a system of engagement (Slack and other surfaces). Headless 360 opens every one of those layers to programmable endpoints. Agents and coding tools can now reach into any of them without a browser in sight.

For architects who have spent careers designing around Lightning, Apex triggers, Flow, and the Setup menu, this is a signal to reset your mental model. The browser UI is not going away. But it is no longer where your most valuable workloads will live.

Here is the shift in one sentence. Salesforce used to be a system humans logged into. It is becoming a system agents program against.

Salesforce organized Headless 360 around three pillars. Each one represents a different architectural concern. Understanding the pillars separately matters because they will arrive in your org on different timelines and with different cost profiles.

The pillars track the lifecycle of an agentic workload. You build it with coding tools and MCP. You deploy it across surfaces without writing platform-specific glue. And you trust it in production with deterministic guardrails and evaluation tooling.

Why the Pillar Order Matters

Most coverage has focused on Pillar 1 because MCP tools and vibe coding are the shiny part. I would argue Pillar 3 is where the real architectural value lives. The industry has been shipping impressive demos for two years. The hard part has always been getting probabilistic systems to behave like enterprise systems. Reliability, auditability, rollback, and regression testing.

Agent Script and Testing Center are the tools architects have been quietly asking for. Agent Script gives you a versionable, auditable definition of an agent’s behavior as a state machine. Testing Center gives you a regression suite. These are not glamorous announcements. They are the announcements that make production agent deployment possible without hoping nothing breaks.

If you have been building on Salesforce for years, you might be wondering what is structurally different about MCP tools versus what you already have with SFDX, the Metadata API, or REST composite endpoints. Fair question. Here is the honest breakdown.

The Headless 360 Architecture in One Picture

Think of the platform as four stacked layers, each now independently callable through MCP:

In the old model, these layers were tightly coupled to Lightning as the primary UI. In the Headless 360 model, any surface can call any layer. The architectural decision is no longer just “where does the data live?” but “which layer handles reasoning, which handles action, and which handles presentation?”

Agent Script was quietly the most important announcement at TDX 2026, and most of the press missed it. Salesforce open-sourced a new programming language designed for a very specific architectural problem. How do you combine the flexibility of LLM reasoning with the predictability enterprise systems require?

The answer, per Agent Script, is hybrid reasoning. In a single Agent Script file, you declare which steps of the agent’s flow must execute deterministically (explicit business logic, variable assignments, conditional transitions) and which steps can reason freely using LLM capabilities. The whole thing compiles to a state machine that is versionable, testable, and auditable.

The syntax uses two modes. The arrow (->) or colon signals procedural logic that runs top to bottom. The pipe (|) signals prompt text that assembles into a single instruction block for the LLM. The runtime walks the script, executes deterministic steps, and sends only the relevant prompt fragments to the model at each decision point.

AGENT SCRIPT// Deterministic: always check order status first
lookup_order(orderId) -> order

if order.status == "shipped":
  | Help the customer with tracking. Their tracking number is {order.tracking}.
else:
  | Apologize and explain the order is still processing. Offer to escalate.

// LLM decides tone and phrasing, but the path is fixed

This is not a return to rigid chatbot scripting. It is a bet that the winning architecture for enterprise AI is not “smarter models” but “better control planes around the models.” You keep LLM reasoning for the parts that genuinely need it (interpretation, phrasing, context handling) and you hard-code the parts where drift is unacceptable.

Every big announcement has gaps. Headless 360 has a few that deserve attention before you build architectural dependencies on these capabilities.

The Apex Limits Still Apply (For Now)

Your agents running against production workloads still hit the same governor limits Apex has always had. The 10-second synchronous CPU limit. The 100 SOQL queries per transaction. The 150 DML operations. Salesforce flagged upcoming changes to the security model and async limits “engineered for agents” at TDX, but nothing has shipped yet. Until it does, architects running production agent workloads need to design around existing limits and expect hard conversations with AEs about per-org ceilings.

The Builder Gap Is Real

This is the conversation Salesforce did not have on stage. Headless 360, MCP tools, Agent Script, native React, ADLC skills, Hosted MCP Servers. This is a pro-code menu. The vibe coding framing makes it feel accessible, but the underlying skillset is software engineering. When Salesforce says “agents will write Agent Script for you,” that is true. But someone still has to prompt, evaluate, debug, test, and deploy what the agent produces. That someone needs to understand structured type systems, API architectures, CI/CD pipelines, and LLM behavior.

The traditional Trailblazer community was built on clicks-not-code. These announcements do not include a visible bridge program for admins who need to cross from declarative to agentic. If you lead a team of Salesforce admins, the reskilling conversation starts now.

You do not need to rewrite your org tomorrow. You do need a clear plan for absorbing Headless 360 into your architecture without breaking what already works. Here is the phased approach that matches how this will actually roll out.

For architects evaluating this right now, the question is not “should we adopt Headless 360?” The question is which workloads benefit from going headless first, which stay in Lightning, and how to keep the two models from fighting each other. The orgs that win the next three years will answer that question before their competitors do.