Salesforce Just Shipped the Hands. Nobody Shipped the Brain.

On August 26, Salesforce and Anthropic announced Claudeforce. The centerpiece is a plugin for Claude CoWork that drops live CRM data into the model with 37 prebuilt sales skills, so a seller can query, update, and act on records without ever opening Salesforce. Their president of applications compared it to what Claude Code did for developers, except aimed at knowledge workers.

I read it twice. Not because it was surprising, but because it described, almost line for line, the system I have been running against my own deals for the better part of a year.

That is worth saying out loud, because when a 27-year-old enterprise platform and a frontier lab independently arrive at the same architecture you built in a spare bedroom, one of two things is true. Either you got lucky, or the architecture is simply correct. I think it is the second one. And I think their version is missing the piece that actually makes it compound.

What they got right

Strip the branding off Claudeforce and you get three moves.

The UI stops being the product. Salesforce's position is that its value was never the screens. It was the data, the metadata, and the years of encoded workflow buried underneath. So they exposed all of it through MCP servers and let the model be the front end. The interface layer, the thing they spent nearly three decades perfecting, got demoted to one of several possible views.

Skills carry the judgment. Before Claude touches a record, it reasons over its available skills to see whether specific guidance exists for the task at hand. Their description of skills as human-like instructions is exactly right. A skill is not code. It is the written-down version of how a competent operator handles a recurring situation, in a form a model can read and follow.

Permissions ride along with the tool call. The MCP server inherits the user's existing access. If you cannot see the record, neither can the agent acting on your behalf. Nothing new to stand up, nothing to re-audit.

That is the same three-layer shape I run. The model is the hands. The MCP server is the reach. The skills are the standard operating procedure. When I underwrite a property, I do not open an app. I say the address out loud, a skill pulls comps and flood data and market intelligence through MCP, runs the deterministic math, and hands back a one-pager with strategy comparisons and buy-box fit. The app still exists. I just rarely need to look at it.

There is a detail in the launch coverage I did not expect to see. The showpiece of their demo was an executive asking the model to generate a dashboard, which it coded on the fly against live Salesforce data, and a Salesforce leader noting that at a recent internal summit every single sales executive presenting a business review showed up with a command-center view of their business that they had built themselves inside CoWork.

I have one of those. It reads my scheduled and published posts, my blog rows, and my newsletter numbers out of three separate systems every time it opens. I built it in CoWork months ago, for the same reason they did: I got tired of looking at four dashboards to answer one question.

So the news is not that this works. The news is that the largest CRM on earth has now conceded, publicly, that it works well enough to bet the company's interface on.

The part they left out

Here is the sentence from the launch materials that stuck with me. They describe a frontier model without company context as "a genius who's never seen your deals."

Correct diagnosis. Wrong cure.

Their answer is retrieval. Point the genius at the database, give it 37 skills, and let it look things up faster than a human can click. That solves the context problem for the length of one conversation. Then the conversation ends, and the genius forgets everything except what got written back to a record field.

Think about what that actually loses. A seller runs a morning briefing, works six opportunities, learns three things about why deals in a particular segment keep stalling, and closes the tab. Tomorrow the same genius starts over. It will happily re-derive the same insight for the next four hundred mornings and never once notice it is repeating itself. Execution without accumulation.

That gap is not a Salesforce failure. It is a category gap. Almost every agentic business tool shipping right now is built as hands with excellent reach and no memory of its own reasoning.

I got a small, humbling demonstration of it this month. That command center I mentioned went dark for nine days. A configuration list quietly emptied during an unrelated update, so every connector call was rejected before it left the page, and every panel rendered a dash. The tool itself never noticed. It has no notion of what it looked like yesterday, so it could not tell that showing nothing was new. I found it because I went looking. Hands do not know when they have stopped working. That is not a bug in the hands. It is the argument for a brain.

Why I built a ledger instead of more tools

The thing I spent the most time on in forVEX is not the underwriting engine or the rehab estimator. Those are the visible parts. The part that matters is that every lane emits a structured event at the moment of action.

Marketing drafts a flyer for a property, that emits. A rehab scope changes, that emits. A deal moves from offer to under contract, or dies, that emits. A competitor's listing turns out to have quietly withdrawn rather than closed, that emits. All of it lands in a single ledger with three stable contracts underneath: the event schema, the entity and ID model, and the signature of the emit tool itself. Fix those three, and every lane you add later inherits them for free.

The reason for that discipline is not tidiness. It is that a ledger is the only thing that lets a system reason across lanes instead of answering one question per prompt. Once marketing activity, rehab variance, and disposition outcomes are all shapes in the same table, you can ask questions no individual tool can answer. Which acquisition channels produce the deals that actually close on schedule. Whether my rehab estimates run hot in a specific submarket. What the pattern is in the ones I lost.

That is a different job from execution, so it gets a different surface. The model is the hands. The ledger holds the truth. forVEX Edge is the reflection layer that sits on top and reads across all of it, and it is the only piece that gets smarter the longer the operation runs.

The test I did not plan to run

In July, OpenAI shipped ChatGPT Work, an agent mode built for roughly the same job. So within about six weeks, the two largest labs both put a working agent surface in front of knowledge workers.

I run on both now. Not out of loyalty to either one, and not as an experiment I designed. It happened because the pieces that matter were never sitting inside a chat window in the first place. The ledger is my database. The MCP servers are my connections to my own systems. The skills are markdown files describing how I do things. Point a different set of hands at that stack and the work still comes out.

That is the whole thesis, and I did not really believe it until I watched it happen. If the intelligence lives in the surface, switching surfaces costs you everything you have accumulated. If it lives in your ledger, switching surfaces costs you an afternoon.

Which reframes what Claudeforce actually is. It is not a moat. It is a very good pair of hands, rented, and there is now a second pair available from someone else. The interesting question stopped being which one you use. It is what either of them is standing on.

What this means if you are not Salesforce

If you run ten to fifteen deals a year instead of ten thousand opportunities, none of the enterprise economics apply to you. But the architecture does, and you can actually build it, which is the part nobody says clearly enough.

The order matters. Most people start by collecting tools. Start with the ledger instead. Decide what an event looks like in your business, decide how you identify a property and a deal and a person, and write those two decisions down before you build anything on top. Then add skills, one per recurring situation, written the way you would explain it to a new hire. Connect the systems you already pay for through MCP so the agent works against real data rather than a description of it. Then, and only then, worry about the interface, because at that point you can generate whatever view you need on demand, in whichever surface you happen to be standing in that quarter.

Two corrections

I do not think Salesforce is wrong. I think they are early to the right answer and stopped one layer short of it.

The first correction was that the interface was never the product. That one is finished, and they conceded it in public, which took some nerve for a company that spent 27 years building the best one in the business.

The second correction is still coming, and it is that the tool calls were never the product either. Skills and MCP servers will be table stakes inside of two years. Everybody will have them, bundled, prebuilt, thirty-seven at a time. What will not be commodity is the accumulated record of what your operation actually did and what came of it, because that is the one thing nobody can ship you.

The operators who win the next stretch will be the ones whose systems remember what happened last quarter, not the ones with the most skills installed.

I have been building toward that for a while. It is good to have company.