Part 3 of Built to Last: A Practical Series on the Enterprise Context Layer. Part 1 showed a 60-second account summary that catches what manual prep misses. Part 2 took apart the context layer underneath it. This post covers what that layer opens up beyond Salesforce itself.
Dreamforce runs September 15 through 17 in San Francisco, and if the chatter is right, headless will be one of the headline themes. The word is already showing up in Salesforce conversations well ahead of the keynotes, and it deserves a plain definition before the stage productions get hold of it, because it describes the most useful shift in the platform in years.
What headless actually means
For most of its history, Salesforce came as a front-office platform. The system of record and the way you worked with it were the same product: the records, the screens, the list views, the reports. If you wanted the data, you went to the interface.
Headless separates the two. Salesforce remains the system of record. It holds your accounts, opportunities, cases, the security model, and the audit trail. The head is the intelligence and the interface that work with that data, and the head becomes a choice. An agent can read from Salesforce and act on it without a person navigating screens, and increasingly without the agent being a Salesforce product at all.
Some teams hear that and worry about their CRM investment. The opposite is true. When any intelligence can draw on your Salesforce data, the value concentrates in the quality of that data and the layer that organizes it.
The same foundation, a choice of heads
The account summary in Part 1 came from an agent inside the CRM. It sat in the rep’s workflow and answered for one account at a time. That agent drew on the Data 360 context layer described in Part 2.
That agent did its job, but the context layer doesn’t care which head you run. Connect Claude through MCP and Claude reads the same unified profiles and the same calculated insights. Nothing gets copied, exported, or rebuilt. The identity resolution and the computed measures you invested in for the first use case are simply available to the next head you pick.
So the real question becomes how to choose. Start with the kind of work each head is built for.
Agentforce fits work that is answered and acted on inside Salesforce, by people who live in Salesforce. The Part 1 account summary is the shape of it: an agent next to the record that operates within Salesforce’s permission model and produces something a rep uses in the flow of work. That reach keeps widening, and the newest example is Agentforce Coworker, now in beta, which answers ad hoc questions straight from the Salesforce search bar and hands off to configured agents to act. Salesforce even lists Coworker as available inside Slack, Teams, Claude, and ChatGPT, which tells you they now treat the head as modular.
A frontier model connected over MCP is built for the moment a question turns into a project. Which accounts show declining usage inside 90 days of renewal? Which accounts match the usage and engagement pattern that preceded our last several expansions? Now draft a save plan for each account on that list, ordered by revenue. The model composes the queries, follows one answer with the next question, pulls in context from beyond Salesforce when the analysis needs it, and finishes with a document you can hand to the team. Work that outgrows the flow belongs in a head that sits outside it. Custom builds still win in narrow cases, usually when the work needs to live inside another application entirely.
The kind of work is the biggest factor in the choice, but others show up in real decisions. The next is security and governance. An Agentforce agent runs inside Salesforce’s trust boundary and inherits the permission model your admins already maintain, and for some teams that simplicity settles the question. Another factor is where your people already work. Agentic capability tends to centralize, and teams that have adopted Claude keep extending it with skills and plugins because their users already live there. Neither factor overrides the work, but both belong in the decision.
The guardrails that make it safe
Connecting a frontier model to your CRM raises the right questions immediately. Who can see what through that connection? Which actions is the model allowed to take? How does usage stay observable? A sales rep asking about their own accounts and a model reading the whole book of business are different exposures, and the setup should treat them differently.
The freedom to choose your head only works when those answers are built into the setup. And those three questions are the start of a larger discipline: an AI governance framework, with usage policies, risk tiers, and a single front door for new tools and use cases, so a company can say yes quickly because nothing slips through unseen. That framework is the subject we take up next.
The three parts of Built to Last come down to one argument. A visible win proves the value. The context layer makes the win repeatable. A headless platform means the layer you built serves whatever intelligence comes next. And governance is what lets you keep saying yes as the options multiply. If you’re weighing where different AI tools fit in your stack, we have that conversation every week.