There’s a moment at every big tech conference when the crowd shifts in their seats.
At a preview to Salesforce TDX this year, Parker Harris asked out loud: “Why should you ever log into Salesforce again?”
A lot of devs leaned forward. A lot of admins and architects sat back. And that was reinforced in the TDX Keynote which was billed as Headless 360
That’s the split we need to talk about.
Table of contents
What the keynote actually said
Salesforce Headless 360 is real, and it’s significant. Everything on the platform — every workflow, every business rule, every data object — is now exposed as an API, an MCP tool, or a CLI command. Sixty-plus new MCP tools. Thirty-plus preconfigured coding skills. Your coding agent gets live access to your entire Org, directly inside Claude Code, Cursor, or Codex, without ever opening a browser.
The message was direct: if your platform requires humans to click through UIs, it is not ready for the agentic enterprise.
For devs in the room, this was Christmas morning.
For admins and architects, it felt like the tree had just been set on fire.
Here’s the thing about that reaction
The fear is understandable. But it’s built on a misreading of what was announced.
Parker Harris wasn’t saying Salesforce Flows are dead. He wasn’t saying declarative configuration no longer matters. He was saying agents need to reach that configuration. They need to call the workflows your admin built, not bypass them.
Think about that for a moment.
Your approval chains. Your escalation logic. And now your entitlement rules and SLA timers that legal spent three months approving. An AI coding agent connected to a raw database doesn’t know any of that exists. But an agent running inside Salesforce inherits it all. That is the whole point.
The platform isn’t moving away from what admins built. It’s making that work accessible to a new class of worker — the agent.
What this means if you’re an admin
The honest answer is: your role is changing. But it was already changing.
Admins who have thrived in the last five years weren’t just clicking through Setup. They were translating business problems into platform solutions. They understood process. It was them knew where data lived and why. They made decisions that developers couldn’t make, because developers didn’t know the business.
That skill doesn’t become less valuable when agents arrive. It becomes more valuable.
The agent has to be told what good looks like. It needs a process to follow, a boundary it won’t cross, a scoring definition for what counts as a successful outcome. Agent Script, Testing Center, Custom Scoring Evals — every one of those new tools Salesforce announced at TDX requires someone to define the logic. Someone who understands the business deeply enough to say: this is right, this is wrong, this is the edge case that will trip you up.
That’s not a developer job. That’s your job.
The admin of 2026 isn’t configuring Salesforce for humans. They’re configuring it for agents and humans. The surface changes. The expertise doesn’t.
What this means if you’re an architect
You have been quietly positioning for this moment for years. You just didn’t know it.
Salesforce used to be a Ford Focus. Reliable, accessible, most people could drive it. Now it’s an Aston Martin GTE race car. Extraordinary capability. But it needs a full race team with the right skills and the right tools — and someone has to design how all the parts work together.
That’s you.
Architects who built clean data models, documented their Org, understood dependencies between objects, flows, and integrations — they created the context that agents now need to function. In our work with hundreds of Salesforce customers, the organisations with chaos in their metadata have agents that behave unpredictably. The ones with well-documented, well-structured Orgs deploy agents that actually do what they’re supposed to. It’s not magic. It’s architecture.
Context engineering is the phrase you’re about to hear everywhere. The idea is simple: an agent is only as good as the context you give it. The data it can reach, the constraints it operates within, the business logic it can call. Architects design that context. They always have. The label is new. The discipline isn’t.
The technical debt that many Salesforce Orgs have accumulated — undocumented automations, overlapping flows, objects nobody can explain — is now an agent liability. Agents inherit everything. The good and the bad. Cleaning that up isn’t a background task anymore. It’s a prerequisite for going agentic, and it’s an architect’s job.
Agent Fabric — Salesforce’s new governed control plane for multi-agent, multi-vendor deployments — requires someone who thinks in systems. Who can map dependencies, anticipate failure modes, and design for trust across a landscape that now includes multiple AI models, multiple vendors, and multiple surfaces. That’s not a developer problem. That’s an architecture problem.
The Agentforce Experience Layer requires someone who understands that the business logic lives in one place but needs to render in Slack, on mobile, inside ChatGPT, inside Teams. Build once, render everywhere. Architects decide what “once” means and how it holds together under pressure.
If anything, the TDX keynote was an architect’s manifesto dressed up as a developer announcement.
What this means if you’re a developer
You got the keynote you wanted. Enjoy it. And then do the work that actually makes it matter.
A coding agent that can reach your entire Org is extraordinarily powerful. It’s also extraordinarily capable of making a mess. Natural Language DevOps cutting cycle times by 40% sounds great until you’ve watched an agent deploy something to production that violated a sharing rule nobody remembered was there.
The developers who will win in the agentic enterprise are the ones who understand the platform underneath the code. Who know that a customer has an open escalation, a renewal in 30 days, a breached SLA, and a relationship owner with a connection to their CFO. That context took years to build. It lives in Salesforce. Your job is to make sure the agent uses it correctly.
That means working with architects. Working with admins. Not treating them as the people who live in the UI while you live in the terminal.
The conversation is the interface now. And conversations involve more than one person.
What this means if you’re a business analyst
Of all the personas in the room at TDX, the BA may have felt most invisible. The keynote didn’t mention you once. That’s a mistake — and not yours.
Here’s the reality. Every agent needs a job to do. Someone has to define that job clearly enough that a probabilistic system can execute it reliably. What triggers the agent? What does success look like? And what are the exceptions? What happens when a customer falls outside the standard process? Where does a human need to step in?
Those are not engineering questions. They are analysis questions. And nobody is better placed to answer them than a BA who understands both the business need and how it has been (or should be) modelled in the platform.
The work BAs have always done — process mapping, requirements definition, user story writing, acceptance criteria — is now the scaffolding that agents run on. If the process is vague, the agent is unpredictable. If the requirements are ambiguous, the agent will make its own interpretation. Usually the wrong one.
Salesforce’s new Custom Scoring Evals require someone to define what “good” looks like for each use case. A customer service agent that declines an out-of-policy refund while clearly explaining the alternatives scores well. One that confuses the customer and escalates unnecessarily does not. Writing those scoring definitions is applied business analysis.
Agent Script — the new tool that lets you define exactly which parts of agent behaviour must follow explicit business logic — requires someone to have captured that business logic in the first place. That was the BA’s job before agents. It still is.
There’s a new title emerging in forward-thinking organisations: AI Process Designer. Or Agent Workflow Analyst. The name will settle eventually. But the role is recognisably BA-shaped. If you’re a BA today, that’s the direction to move in. Map processes for agents, not just for humans. Write requirements that a machine can act on. Define the edge cases before the agent finds them at 2am on a Sunday.
The keynote didn’t see you. But the agentic enterprise needs you more than ever.
The career paths, plainly stated
Admins move toward agent design, process governance, and quality assurance for automated workflows. The skills you already have — deep business knowledge, platform configuration, user empathy — are the foundation. Add evaluation design, agent behaviour definition, and change management for AI. You’re not being replaced. You’re being promoted.
Architects move toward context engineering, agent orchestration, and AI governance. Your existing strengths in system design, data modelling, and dependency mapping are exactly what the agentic enterprise needs. The title might say “AI Architect” or “Agent Platform Lead.” The work is still architecture. But the stakes for clean, documented Orgs just went up significantly.
Business analysts move toward AI process design and agent requirements. Map processes for machines as well as people. Write scoring definitions. Define exception handling. Own the logic that sits between what the business wants and what the agent does. This is high-value work and it is chronically undersupplied.
Developers move toward agentic development, platform-native AI integration, and DevOps for AI systems. Your new tools are extraordinary. Your obligation is to use them in ways that don’t break what other people built, and to build things that other people — including agents — can actually use.
The thing nobody said on stage
Parker Harris’s question — “Why should you ever log into Salesforce again?” — was aimed at the future. Not the present.
Right now, agents drift. They hallucinate. They hit edge cases nobody designed for. Session Tracing exists because you need to know why an agent did what it did. A/B Testing exists because you’re going to have multiple versions of agent behaviour and need data to decide which one stays.
The agentic enterprise is not a solved problem. It’s a direction. Salesforce just gave you the tools to move in it.
The question isn’t whether admins, architects, business analysts, or developers have a role in that future.
The question is: which ones will be ready when it arrives?
Ian Gotts is Chairman of Elements.cloud and an advisor to ISVs in the Salesforce ecosystem.
