Salesforce TDX 2026 - headless thinking for the Agentic Enterprise era as developers face the shift from determinism to probabilism

When Salesforce co-founder Parker Harris asked earlier this month why anyone should ever log into Salesforce again, it was a comment that caught the eye. It was also unlikely to be the end of the story, of course, as attendees at this week’s TDX developer conference in San Francisco are about to find out.

Meet Headless 360, the follow-through on Harris’ tease. This is based on the first premise that for the past quarter of a century, using Salesforce meant working inside Salesforce. But with today’s push towards the Holy Grail of the Agentic Enterprise, that’s a limiting factor, reckons the firm, going so far as to assert that if a platform requires humans to click through UIs or write code directly to make progress, it is not ready for the Agentic Enterprise. 

As per the launch blah blah, Salesforce Headless 360 provides:

...the capabilities your agents need most, exposed as an API, MCP tool, or CLI command so humans and agents can build, act, and deliver experiences on any surface.   Instead of burying capabilities behind a UI, expose them so the entire platform will be programmable and accessible from anywhere

It also brings three new innovations: 

● New MCP tools and coding skills that give your coding agent full access to your platform.

● A new experience layer that renders rich, native interactions across every surface, from Slack to Voice to WhatsApp.

● New tools that give you control over how agents behave in production, before launch and after.

Developing change

The life of a developer has come a long way since he learned waterfall development, says Joe Inzerillo, President of  Enterprise and AI Technology at Salesforce. That meant big, long planning cycles and detailed specifications before you ever broke ground. It was slow and slow doesn’t fit today:

Now we’ve got to the era of agentics, the speed limit is insane. We’re now going really fast. What used to be weeks is now in some cases hours. We have digital labor and humans doing things.

There’s also a big shift going on that will get a lot of air time over the next two days at TDX, that between determinism and probabilism, he argues:

Typically the vast majority of developers, the vast majority of trailblazers, were developing deterministic experiences. You can put in some input, you can define how you want that input modulated or enhanced, and it got some output, You could do that every day, and one plus one was always equal to two, no matter what you did, no matter what day you did it on. It was incredibly deterministic.

But we start to talk about agents, and agents are not software. Agents are something else. They’re also not human. We have to be careful not to completely anthropomorphize them, but what they are is a much more probabilistic, stochastic system that means that you can’t necessarily put in the exact same input and get the exact same output every time. That requires different tooling, a different development cycle. It’s really important to bear that in mind as we start to think about building deterministic experiences, building probabilistic experiences, and we’re going to be using AI and agents to do both of those things.

Hence, the Headless 360 platform, he says:

This is really leaning into the fact that coding engines have just gotten really, really good. You can sit down and give [one] a detailed list of instructions and have it go to town writing code for you. It used to be that a lot of processes were [restricting] development, or administrative resources. Now the limit is almost your imagination. It’s humans and agents working together to build those deterministic systems like we have in the past, and human and agents working together to build other agents, which is another experience in the mix.

But it’s really important to have the core values and capabilities of Salesforce integrated into all this, he adds:

It’s not just tools it’s actually more of a development environment and a development philosophy that we’re also trying to export to our partners and Trailblazers. If we look at the way that you would typically develop code in a deterministic flow, you generally build, you then evaluate, make sure it’s good, you deploy it, and then you make sure it’s good in production. That’s kind of the cycle.

There’s a bunch of tooling that we have now released that’s either in pilot or going GA right now to help support these functions, building with agents, having agents help you build an agentic experience, and not just our agents, but the whole universe of agents. But when you turn your attention towards building a agentic experience, that. set of tools isn’t sufficient. You need other tools that are really designed for the development of agentic experiences.

New areas

He cites experimentation and control-and-orchestrate as two big areas that are new ground to be covered:

When you think about probabilistic experiences, it’s really hard to know just in the testing phase whether or not this agent is actually getting better or worse when you’re making changes. So part of the way that you have to do that is you test your way into it with A/B experimentation.  So, here’s my agent in production, here’s my agent that I made a tweak on, is that agent better or worse? You really need to see that happen in production, with real traffic and real humans that that agent is talking to, to know that it’s good.

When you’re doing the observe cycle, you also have to control and orchestrate the agents. Ultimately, it’s not going to be a single agent that’s in your organization or serving your enterprise. It’s going to be multiple agents. Understanding how those agents interact is a super-important part of the agentic development life cycle. We can’t just ship these agents and hope they work together. We have to think about how they’re going to talk together. When this agent gets a question that it doesn’t know the answer to, how does it talk to another agent? When people are trying to do a job, what agent should they be going to? How do we want to put that front and center in front of folks?

He concludes:

We need to let people build the way they want to build because everybody’s going to have a slightly different set of requirements. Everybody’s going to have a slightly different set of working, so we want to put out tools that help, that guide people into a life cycle that we know will be successful. But we also want to inter-operate.

My take

Ian Thomas is on the ground at TDX this week and he’ll be reporting back on the vibe from the developer community to this shift in messaging from Salesforce. More to come.