ChatGPT
Claude
Google AI
Copilot
On 26 August 2026, alongside Q2 FY27 earnings, Salesforce and Anthropic announced Claudeforce, an expanded partnership whose headline deliverable is Salesforce in Claude, a Claude plugin shipping with 37 prebuilt sales skills.
The coverage has mostly been about strategy: is Salesforce disintermediating its own user interface, and does pricing power move to whoever owns the model. Real questions, and we are not going to pretend to settle them here.
The question we get asked is narrower: what does this mean for the org I am responsible for on Monday. This is that read, with one constraint stated up front. Everything anyone can honestly say about Claudeforce today comes from a press release and a few days of reporting, so this piece separates what those sources state from what we think it implies, and where they are silent it says so.
What was actually announced
Three things, worth keeping separate because they sit at very different stages of maturity.
Salesforce in Claude. A plugin that puts CRM context and actions inside Claude, launching with 37 prebuilt sales skills: meeting preparation, deal health review, pipeline review and similar. The pitch is that a seller reasons over live revenue data and takes governed action without opening the Salesforce UI.
AIforce. The layer underneath, described as Salesforce's enterprise harness: business data and workflows exposed to any agent through MCP servers, APIs and CLI tools. The genuinely structural piece. Whether it is new infrastructure or a name over capabilities that already existed is not clear from the announcement, and the ambiguity matters to anyone estimating against it.
Claude inside Salesforce and Slack. Claude becomes the reasoning model for parts of Agentforce, available inside the Salesforce Trust Boundary via Amazon Bedrock. On the Slack side, Claude powers Slackbot by default.
The part that should change your week
Buried under the strategy commentary is one design decision that lands squarely on admins and architects.
Access is inherited. Salesforce's Patrick Stokes put it plainly: if you do not own a record, the MCP server does not either, so you cannot read or write it through Claude. There is no separate permissions model to build, and authentication is configured centrally rather than per user.
That is the right design. It is also the whole ballgame:
Your sharing model just became your AI security boundary. Whatever an over-permissioned user can see today, they can now ask a very capable model to read, summarise and act on, quickly, in bulk, and with no field-level friction.
Not a flaw, then, but the design working as specified. Its assumptions are worth stating out loud: that your permission sets reflect what people should see, that your role hierarchy is deliberate, and that nobody is carrying broad access granted for a data load in 2023 and never removed. In most orgs we are brought into, at least one is false.
We wrote about how that happens in permission set debt before any of this was announced. The argument has not changed, only the cost of being wrong, and the same is true of the wider security and permissions practice most orgs know they owe.
What is known, what is not, and what turns on it
The first column is what the announcement and the reporting on it actually say. The second is what nobody has published, at least not anywhere we could open and read. The third is why each gap matters.
| Question | What the sources state | What is not published | Why the gap matters |
|---|---|---|---|
| Availability | Pilot with selected customers now, open beta stated as expected September 2026 | Which editions, clouds and regions, and whether the date holds | Decides whether this is a plan item or a note in the minutes |
| Access model | Inherited from the signed-in user's Salesforce permissions, configured centrally | How field-level security, sharing rules and restriction rules behave in practice | Decides how much of an access review is enough before you enable anything |
| Commercials | Salesforce bills consumption, Anthropic bills inference, on separately agreed terms | Any rate, unit or minimum, and what an existing licence already covers | The only unknown large enough to change the adopt decision outright |
| Additional skills | 37 sales skills at launch, more to follow, with the published timings differing | Which business functions, and on whose calendar | Decides whether anyone outside sales belongs in the room yet |
| Agentforce | Claude becomes the reasoning model for parts of it, inside the Trust Boundary via Bedrock | Whether existing builds need any change, and what uptake asks of a customer | Decides whether a live rollout pauses. On what is published, it does not |
| Audit and retention | Nothing we could verify from the sources we were able to open | What is logged, where conversations are held, and for how long | The first question security asks, and the usual reason a pilot stalls |
Two of those carry more weight than the rest. The commercial one, because it is the only row where the answer could be large enough to change whether you adopt at all, and the least likely to be resolved in public: terms agreed customer by customer are, by construction, not something you can research your way to. The audit and retention one, because it is the question security asks first, and arriving at that conversation holding an announcement rather than an answer is how a pilot gets stopped by somebody who was never against it.
The rest can wait. Dates move and skills lists grow, and neither changes what you should be doing meanwhile.
The second-order problem: nobody owns the meter
Reporting describes two commercial relationships rather than one: Salesforce charging for the new usage through its consumption pricing, and the customer contracting separately with Anthropic for the Claude inference. No pricing has been published, and terms are subject to individual customer agreements.
Set aside whether that is expensive. The operational problem is simpler: consumption-based spend with no named owner is how organisations get surprised. Seat licensing is predictable and procurement owns it. Two metered services, driven by how enthusiastically your sellers use a chat interface, is a different kind of line item. The demand is generated conversationally and a conversation has no natural stopping point, so the intended outcome and the billing risk are the same behaviour.
Stokes was candid, telling VentureBeat that you cannot buy this on one piece of paper at the moment. That is the honest answer at this stage of a partnership, and a plain description of a problem that lands on your side of the line. Anyone who has been through an Agentforce pricing exercise knows how quickly a consumption model turns into a governance question.
If you take one administrative action from this announcement, make it naming that owner now.
What it does not mean
A few corrections we have already had to make in client conversations this week.
It does not retire Agentforce. Claude becomes the reasoning model under parts of it. If you are mid-rollout, keep going. The scoping, grounding and escalation work in the grounding checklist is unaffected: a better model does not remove the need to decide what an agent may not attempt.
It does not make your data model irrelevant. An agent reasoning over your pipeline is reasoning over the fields your team actually fills in. If close dates are fiction and stage definitions are contested, Claude will produce a confident, well-written summary of fiction. Same data model problem as last month.
It does not mean the UI is going away. That is the strategic argument, not a delivery fact. Nothing announced retires a screen anyone uses today.
It does not mean you have to move quickly. Pilot access is not on general release and nothing degrades while you wait. The only item here with a real clock attached is the access review, and that was overdue before anybody said the word Claudeforce.
Reading an announcement before it resolves
Most of the cost of an announcement like this is paid by the organisations that reorganise a roadmap around a paragraph, then reorganise it back. There is a repeatable way to read one that does not require waiting for the dust to settle.
Separate the noun from the verb. A press release names things. A shipped capability does something, for a named user, in a named edition. Ask what a person would have to do tomorrow to use it. Where you cannot answer, you are holding a name, and names get revised.
Check the tense. Is available, will be available and is expected are three different commitments that turn up in the same paragraph. The third is a plan, and a plan held jointly by two companies with two release calendars moves more than one held by a single vendor.
Count the parties. Two vendors, two contracts and two meters give a capability more places to slip. That is arithmetic about coordination rather than criticism of the design, and it is why the commercial row above will be the slowest to fill in.
Ask what the announcement makes false. The most useful question and the least asked. If you read one, feel excited, and cannot name a single thing on your roadmap that is now wrong, it has not actually reached you.
On that last test this one does have an answer, and it is the access model. Everything else could slip a quarter without changing what you should do.
The questions to put to Salesforce or a partner
Take these to an account team rather than a search engine, and treat "we will come back to you" as information about maturity rather than a failure of the conversation.
Commercial. What is the unit of consumption on the Salesforce side, and what triggers it. Does our current contract cover any of it. Is there a minimum, and what happens at renewal.
Access. How do field-level security, sharing rules and restriction rules behave through this path, demonstrated rather than described. What happens with a record a user can view but not edit, or when a permission is revoked mid-conversation.
Audit. What is logged, where, and for how long. Can we see which records an individual reached in a given week, and does that log land somewhere security already monitors.
Retention. Where do conversations live, under whose policy, and for how long.
Scope. Which editions and regions. How many of the 37 skills map to how we actually sell. What does it take to switch this off for a subset of users.
Clear answers on the commercial and audit questions make the pilot a small decision. No answers is not a reason to refuse, it is a reason to keep the cohort small and the review date close.
Four things worth doing before the beta
- Run an access review, properly. Not a tidy-up, an actual answer to "who can see what, and why". Start with the count of users who can view or modify data broadly. That number is your blast radius, and it is worth knowing whether or not any of this ships.
- Name the consumption owner. One person, accountable for both meters and for the budget conversation. Before pilot access, not after.
- Pick a narrow pilot cohort with clean data. One sales team whose pipeline hygiene you would show a customer. Testing an AI interface on your messiest region teaches you only that the region is messy.
- Keep a live list of what you cannot answer. Field-level security behaviour, audit trail, retention, editions, price. Cross an item off only when Salesforce has answered it for your org. A written list of unknowns is a better planning artefact than a confident summary.
Our honest position
We are not going to be contrarian about this for its own sake. A permission-inheriting, centrally authenticated bridge between a frontier model and enterprise data is the right shape for the problem, and a better shape than most of what has shipped in this category.
It is also, today, mostly a shape. The parts that would let anyone plan properly, price, editions, audit, retention, and the access model under real sharing rules, are not published.
For the optimistic reading to hold, four things have to be true at once: the September date holds, the pricing lands somewhere an ordinary sales organisation can absorb, the inherited permission model behaves under field-level security and restriction rules the way the summary implies, and the audit trail satisfies a security function that had no say in the announcement. Any one could go the other way, and none is knowable from here.
What does not depend on any of that is the burden the design moves. When access is inherited, the quality of your access model is the quality of your AI governance. Orgs that kept theirs clean are in a strong position whatever happens next. Orgs that did not now have a reason to fix it that a board will fund.
It is not glamorous, it has been outstanding for years, and it just became easier to get approved.
Sources: Salesforce investor relations, 26 August 2026 · Salesforce Ben · VentureBeat
Published 28 August 2026, last reviewed 29 August 2026. Availability, pricing, model behaviour and feature scope above reflect only the three sources linked here, as they read on that date. Where those sources were silent we have said so rather than filled the gap, and where two differed we have said that too. Any of it may have changed by the time you read this, so confirm with Salesforce before you commit budget, a roadmap position, or a security sign-off on the strength of this piece.
