TL;DR:
- At TDX, Salesforce announced Headless 360, a tool that opens the platform through APIs, MCP, and CLI commands so developers and AI agents can work with Salesforce outside the browser.
- The interface is getting more flexible, but the dependencies, automations, flows, permissions,etc underneath still determine what breaks when something changes.
- Salesforce and Sweep presented together to show how Salesforce IT is modernizing their own Salesforce in place. Rather than rebuild a 20+ year-old org supporting 25,000+ sellers, Salesforce IT used Sweep to refactor safely while the system kept running.
*****
At TDX this year, Salesforce made their new direction official: the platform is becoming more programmable with Headless 360. The new tool opens Salesforce through APIs, MCP tools, and CLI commands, letting developers and AI agents work with Salesforce from outside the browser. The framing was unusually blunt: "No Browser Required."
It's the right direction. Modern teams already work this way across the rest of their stack. Composability gives developers more flexibility, lets customer experiences live wherever they need to live, and meets AI agents in the environments they already work in. Salesforce is moving closer to how software actually gets built today.
But composability changes what risk looks like.
The system underneath doesn't get simpler because the interface gets more flexible. The dependencies still exist. The automations still fire. The fields, flows, permissions, integrations, and business rules still shape what happens when anything changes. Headless reduces friction at the interface layer. It doesn't reduce the need to understand the system underneath it.
If anything, it raises the stakes. More people, more tools, and more agents can now make changes — which means more changes can happen faster than before. The question that sits in front of every meaningful change ("What happens if we change this?") gets harder to answer as more entry points open up.
Which is why the most useful session at TDX centered on what it takes to actually run a complex Salesforce org in this new world.
Salesforce's own org told the story
Salesforce IT runs an internal Salesforce instance called Org62. It's older than most of the people configuring it.
"It's 20+ years old and supports 25,000+ sellers," said Elliott Johnson, Director of Product Management at Salesforce, in the run-up to TDX. "Modernizing a system this size usually implies a full rebuild, but we needed a path forward that didn't require a multi-year timeline."
"We found a way to 'fix the engine while the plane is flying,'" Elliott wrote. "Using Sweep, we've been able to refactor in place and get AI-ready without taking the system offline. Tasks that used to take my team hours now take minutes."
Why refactoring beat rebuilding
Most enterprise teams don't get to start over. It’s simply not an option.
The instinct is appealing — new org, cleaner architecture, no archaeology — but mature systems carry too much business logic, too many dependencies, and too much operational history to replace casually. Some of that history lives in documentation. Most of it lives in metadata, naming conventions, inherited automations, half-remembered Slack threads, or the heads of people who no longer own the system.
So, the Salesforce IT team mapped it.
With Sweep providing the agentic layer over Org62 — surfacing dependencies, automations, integrations, and business logic — the team could see how objects connect before anything moved. "What happens if we change this?" became answerable instead of guessable. Refactoring became a structured process: understand the system, plan the work, then make the change.
That's the shift. Not "let's start clean." Not "let's freeze the system and assess for six months." Just: understand the system well enough to refactor it safely while it keeps running.
What this means for everyone else
The Salesforce-on-Salesforce story is useful precisely because Salesforce IT is operating at the much more extreme end of complexity. If the world's most complex Salesforce org can be modernized in place, the pattern generalizes. Understand the system, plan the change, then ship it — works at any scale.
It also reframes the AI conversation that ran through every TDX session.
The last year leaned hard into vibe coding. Describe the outcome, let AI generate the work, move fast. For prototypes, that approach feels magical. Then the generated work meets a real enterprise org. Flows fail to deploy. Logic misses how the org actually behaves. Small inconsistencies become operational issues. A change that looks reasonable in isolation creates risk because it lacks the full system context around it.
The next phase of AI in enterprise systems is less about whether AI can generate work and more about whether it can generate the right work inside the right constraints. That means querying the system before anything gets built. Scoping the work before it runs. Verifying before deployment, not after something breaks. Keeping humans responsible for architecture, review, and correctness.
This is the move from loose generation to agentic engineering. AI still builds. It just builds against the actual structure of the system, reasons through dependencies, and plans before it executes.
The constraint has moved upstream
Headless 360 makes it easier to build experiences. AI makes it easier to generate changes. Speed is no longer the bottleneck.
The bottleneck is context. What already exists? How does it connect? What depends on it? What could break? Those questions don't go away when the interface becomes more flexible — they get more urgent, because more people and more agents can make more changes faster than before.
The fastes teams will be those who understand their systems well enough to change them safely. That's the work Salesforce IT is doing on Org62. It's the work the rest of the ecosystem is heading toward, whether the next year's announcements call it that or not.
