Claudeforce: First Standard AI Product

Claudeforce — The First Attempt at a Generally Available Standard Product on the Headless 360 Architecture

Salesforce and Anthropic have introduced Claudeforce. The visible part is a plugin with 37 prebuilt sales skills that lets sales staff query pipeline data, update it and trigger actions without opening Salesforce. It is running with pilot customers, and an open beta has been announced.

Architecturally, none of this is new. Headless 360 has been exposing the platform’s data, workflows and actions to arbitrary agents for months. What is new is that a vendor has built the first standard product on top of it — something you install rather than assemble.

That is precisely what makes it interesting. Not as a product, but as the first tangible example of an architecture that other vendors and in-house developments will connect to. The client is interchangeable: the platform accepts any agent that speaks the protocol. Anyone who understands the pattern here will understand the ones that follow.

What a Skill Does — and What It Does Not

The 37 skills do not sit in Salesforce. They are text instructions on the side of the chat client, describing how a task is carried out.

The decisive point: an instruction describes a sequence, it does not enforce it. A model reading it can skip steps or reorder them, and it does nothing at all if nobody asks. For preparation, research and data hygiene, that is entirely sufficient. For an approval process with four-eyes review and a deadline, it is not.

Anything binding must therefore be modelled in the system of record, independently of which client someone enters through. Salesforce rightly describes that actions are routed through the platform so that business rules apply. That holds for rules actually modelled there. Governance is not inherited because an agent connects. It is inherited because someone built it beforehand.

From this follows a second decision, and it is not a technical one: which operations you expose to the agent determines what can be bypassed. Expose generic write access and the approval becomes effectively optional. Expose only complete process steps and the step becomes the smallest reachable unit.

The quotation process makes this concrete. Write the phase logic into the skill and you have a sequence that holds as long as everyone asks politely. Model it on the record and in the approval processes and you have a sequence in which the unauthorised status transition does not exist as a callable operation in the first place.

Why This Is More Than Another Chat Window

Connecting a chat window to a CRM is nothing new. We have built it many times in projects, and so have others. Anyone looking for the real progress in this announcement will not find it in the connection.

It lies in the interface. Chat assistants have not failed, but they were limited — at a very specific point. Running text is a worse format for sales data than any list view. Anyone comparing twelve opportunities wants to see them, not have them read out. This is where the usefulness of these assistants has been breaking down.

What changes: the client generates the interface at runtime. Not a configured template, but a view built freshly for the question asked — table, comparison, timeline, breakdown by region. By now with persistence and data connectivity, so a view once generated can remain in place and refresh with current data.

This breaks with what we have been doing in projects for years. We design layouts, list views and dashboards, specify them up front, lock them down and maintain them for years. Every question nobody anticipated becomes a change request. A view generated at runtime does not know this cycle.

One point of context, because it gets lost in the coverage: this capability is not unique to one vendor. The major assistants all generate interfaces on request by now, with differences in maturity and polish. What is new is the combination — a generated interface on permission-governed business data, preconfigured rather than self-built. That is a packaging achievement, and packaging achievements get copied.

Where the Standard for User Experience Is Being Set

This raises a question many companies considered settled. Anyone who built their own AI front end over the past two years built it against an expectation that is now being set elsewhere.

Users today bring a bundle with them: upload documents, research the web, read images, create and share their own skills, a memory of their own work, connectors to third-party systems — and a visually prepared answer. This bundle is technically reproducible; open-source solutions cover most of it.

What cannot be reproduced is the cadence. The bar shifts every few weeks, set by a handful of vendors. Whoever builds it themselves does not have a project but a product with a roadmap obligation — for a layer that offers nothing to differentiate on. The gap does not open up while building. It opens up while catching up.

The effort belongs one level down.

A Side Effect That Also Concerns the Vendor

This observation does not stop at the customer. Salesforce has an agentic chat interface of its own, and measured against the experience users bring from their everyday assistants, it shows the same gap as any self-built solution. At first glance it looks contradictory to let a third-party front end sit so prominently in front of your own platform.

One plausible reading — no more than that, since nobody outside knows the motives — is that relevance can be restored through a partnership in weeks, but not through your own roadmap. Commercially the route is covered either way, because consumption against the platform is billed even when the interface belongs to someone else.

This does not make the vendor’s own front end obsolete. It remains necessary where the agent has to be visible inside the application, where it runs event-driven without a user waiting, and where external users without their own licence are involved. The question is not “either or” but: where does the agent need to be visible?

For planning purposes this changes little — and that is the point. Both routes draw on the same rules, actions and approvals. Whoever has modelled those cleanly does not have to choose.

Which User Groups Come Within Reach

Only against this background does the practical effect become visible. People who never open the CRM interface rarely do so because they do not need the data, but because the interface was not built for their question. Field sales, sales and service management, adjacent departments.

With a welcome side effect on data quality: maintenance happens where people are already working. Although every one of these users still needs identity, permission and a licence. The circle opens up technically; commercially it remains to be clarified.

Whether generated views hold up in users’ hands over months, we do not yet know. It is too early for that. What we do know is the counter-check: the previous approach was limited at exactly this point.

The Boundary

The client can build any view, but only on what the platform offers in data and operations.

For cross-functional questions in industrial business, that is a hard edge. The question about the status of a customer order does not end in the CRM. It leads to availability, delivery reliability and invoicing status — into the ERP. A quotation touching technical feasibility does the same.

There are two routes, and both are process decisions. Either you deliberately move more process steps onto the platform, in which case the agent’s radius grows with it. Or you accept the boundary and orchestrate across system borders elsewhere, where classic integration tooling still has the advantage in strongly heterogeneous landscapes.

What does not work is ignoring the boundary and hoping the model will bridge it. It can only call what is there.

What This Means for Planning

Packaging is explicitly not final, and costs accrue with two vendors under structurally different pricing models. A business case cannot currently be calculated cleanly. That argues for small, controlled entry points rather than broad rollout.

More important is the structural consequence. The interface layer is becoming a commodity. The skill layer above it is quickly built and just as quickly replaced. What remains is the process model underneath: which rules are modelled as binding, which actions are exposed, and how much process sits on the platform at all.

That work is independent of whichever client connects next. And it decides how far the whole thing carries.