AIforce Replaces the UI. It Doesn't Replace the Build.

AIforce was the headline out of Dreamforce ‘26 on Tuesday, and the position underneath it is the most honest thing a CRM vendor has taken in two years: stop navigating screens, start describing what you want, and let the interface be generated around the answer. Marc Benioff called it “an interface revolution.” That is a position this blog has taken for months, so there is no contrarian take available here. The interesting part is what shipped alongside it, and the asymmetry between the two halves.

Because Salesforce shipped both halves of the AI-and-your-CRM story this week. Only one of them got a runtime.

What AIforce Actually Is

In Salesforce’s own words, AIforce is “a live interface layer that brings the full power of Salesforce to wherever people and agents work” — agents that “reason and take action across all the data, workflows, and logic inside Salesforce.” Practically, it is three delivery surfaces plus a toolkit. Claudeforce moved to open beta, bundling Salesforce in Claude with 37 prebuilt sales skills and a development plugin carrying 40+ more. Slackforce went live with Surfaces, Slackbot, Slack CRM and Slack Code. Agentforce Coworker landed inside Lightning and is, per Salesforce, “instantly available” with “the push of a button.”

Underneath sits the Headless Toolkit, which “exposes every element of the Salesforce platform, giving builders and developers MCPs, APIs, plug-ins, skills, and developer tools to create customized AI experiences.” Benioff’s framing for the whole thing: “We are combining model intelligence with all the context that customers have built into Salesforce to create an intelligent, dynamic, composable system.”

The specific claim worth sitting with is that users can build their own UI “simply by describing them, inside platforms like Slack, Claude, and Coworker.” Not choose a layout. Not configure a Lightning page. Describe it, and get it. That is a real product statement, and it retires a decade of arguments about whether business software should be navigated or conversed with.

Koa, and the Model Becoming a Component

The same day, Salesforce announced Koa, its “first CRM reasoning model for Agentforce,” post-trained from NVIDIA Nemotron 3 Super on synthetic data derived from what Salesforce calls 27 years of CRM intelligence. No customer data was used in training. On Salesforce’s own CRM benchmark — worth naming, since a vendor benchmark is a vendor benchmark — Koa “matches or exceeds leading model performance on CRM actions with three times fewer errors.” Select pilot now, general availability expected winter 2026 in U.S. regions.

Benioff’s line was that “the knowledge is put inside the model itself” and that it “runs entirely inside your trust boundary.” Jensen Huang’s was that open Nemotron models let Salesforce “turn decades of enterprise expertise into specialized AI.”

Read the two announcements together and a pattern from the last three weeks completes itself. Salesforce made Claude its default reasoning model in Agentforce in late August, then built its own domain model three weeks later, and shipped both. That is not indecision — it is a company treating the model as a sourcing decision rather than a strategy. The frontier model is now a part you specify, the way you specify a database. We covered the front end of that shift when the Salesforce–Anthropic partnership landed; Koa is the back end of the same idea.

The Half That Didn’t Get a Runtime

Now the asymmetry. The interface half of AIforce is a hosted, managed, licensed layer with Salesforce’s infrastructure behind it. The development half shipped as something you install.

Salesforce’s own documentation for the Agentforce plugins and skills describes a salesforce-development plugin for Claude Code that lets a developer “build, modify, debug, and deploy agents with Agent Script without extra setup,” alongside a skills library organised around the Agentforce Development Lifecycle — generate, observe, test. Installation is a one-line plugin install. It is a genuinely good piece of work and I would use it.

It is also a plugin on somebody’s laptop, authenticated as that somebody, with no shared record of what it did. That is not a criticism of the plugin; local developer tooling is supposed to be local. It is an observation about scope. Salesforce gave the interface a runtime — hosted, multi-user, inside a trust boundary — and gave development a CLI. The gap between those two answers is where the operational questions live, and they are the same questions whether you rent the harness or run it: where does it execute, who else can execute at the same time, and what exists afterward that you can read.

What Describing a UI Doesn’t Reach

There is a second boundary, and it is a layer boundary rather than a governance one. Generating a view on demand and changing the thing being viewed are different operations.

If your AI can render any interface over your objects, that solves a real and expensive problem — the report nobody can build, the screen that shows six tabs of stuff one role never uses. It does not create the field that does not exist yet. It does not write the roll-up Salesforce will not give you, encode routing that matches your actual territory rules, or ship deduplication logic your business recognises rather than the platform’s defaults. Those are metadata and code. They require a deploy, tests, and a sandbox, and no amount of interface generation reaches them.

That distinction is not a knock on AIforce — it is the difference between presentation and schema, and Salesforce never claimed otherwise. But it is why “describe what you want” splits into two products depending on which layer the thing you want lives in. Write access to an org through MCP is a different proposition from read access, and that difference is precisely the deploy.

Where the Describing Should Run

This is the part Sentinel exists for, and the honest scope note first: Sentinel is not affiliated with Salesforce, Anthropic or NVIDIA, and it does not compete with AIforce on interfaces. It handles the other layer — your AI developing in your org.

The shape is unglamorous on purpose. Your AI connects over MCP to a machine that is yours, not to a session on a laptop. It can read, write code, and deploy. Every action lands in one log with who, what and when. Snapshots are taken before deploys. Salesforce changes go sandbox-first with tests required. One write key at a time per org, unlimited read keys, so three people’s AI sessions can work the same org without quietly overwriting each other — the full version of that argument explains why the machine matters more than it sounds like it should, and how the safety layer works covers the deploy path.

None of that stops your AI from building something you regret. It is not supposed to. It means that when something regrettable ships, you can see exactly what changed and put it back — visible and recoverable, not restricted. Anyone selling you an AI that cannot break anything has either restricted it into uselessness or is not being straight with you.

The Week’s Actual Takeaway

Dreamforce settled the interface question in public, and settled it the right way: describing beats navigating. What it left open is the boring operational half — where the describing runs when it changes your org rather than reads it, and what is left over afterward that a person can audit.

Salesforce answered that for interfaces with a hosted layer, and answered it for development with a plugin install. If your team is about to start typing changes into an org, that second answer is the one worth thinking about before the first change ships, not after. The practical starting point is still connecting Claude to your Salesforce org properly, and what it means for your AI to be your CRM developer is the longer version of why that connection is the interesting one.

If you want your AI building in your org this quarter with a log you can read and a rollback you can trust, let’s talk about your org specifically. Pricing is flat per Sentinel and is covered on a short demo call. Book a Demo Call and we’ll walk through what your first build would be.