On 26 August 2026, Salesforce and Anthropic announced Claudeforce. The first product out of it is Salesforce in Claude, a plugin carrying 37 prebuilt sales skills. It is with pilot customers now, with an open beta planned for September. Sales skills ship first. Service, marketing, commerce and the rest are listed as coming soon.
The mechanics matter more than the branding. Salesforce exposes its data, workflows, business logic and permissions over MCP, and the agent calls them directly. No integration project. An admin connects it once and the whole team has it.
Two details in that architecture deserve your attention more than anything in the press release.
The first: the agent inherits the user's existing permissions. If a rep cannot see a record today, the agent cannot see it either. Salesforce is presenting this as the reason there is nothing new to stand up and nothing to re-audit.
The second: the agent treats what is on the record as the state of the business. It reasons over your fields, your activity history, your stage values. It does not know which of them are maintained and which have been decorative since 2021.
Put those two together and you get the actual readiness question. Not "can we connect this." You can. It is a plugin. The question is what happens when a reasoning engine takes your CRM literally, at speed, in front of your sales leadership.
Your permission model is about to be read out loud
Inheriting permissions is genuinely the right design. It is also the part that will embarrass most companies, because inheritance is only as good as the thing being inherited.
In a CRM that has been running for six years, the access model is rarely a model. It is sediment. A rep gets a permission set for a two-week pilot in 2023 and keeps it. Sales ops grants View All on an object to unblock a report and never revokes it. A departed admin's profile is cloned nine times because cloning was faster than thinking about it. Role hierarchy gets flattened during a reorg and never re-tightened.
None of that is visible day to day, because humans do not go looking for records they were not told about. Nobody browses. They open what the email or the list view puts in front of them.
An agent does browse. Ask it to build an account plan and it pulls everything that user is technically entitled to see, including the things nobody realised they were entitled to see. That is not a security breach. Every one of those reads is authorised. It is just the first time your access model has been fully exercised rather than partially used.
The uncomfortable version of this: the fastest way to discover that your permission model is broken is to give it to something that reads at machine speed and has no social instinct for what it probably should not open.
Your data hygiene stops being a reporting problem
Bad CRM data has always been survivable because humans compensate. A rep looks at a close date three months in the past and knows to ignore it. They see an empty next step and know that Slack thread is where the real conversation lives. They see a stage of Negotiation and know the deal actually died in June and nobody bothered to close it out. All of that correction happens silently, in the rep's head, and never touches the record.
An agent has no such instinct. It reads the close date as the close date.
Ask a reasoning agent what needs attention today and it answers from the fields. If your pipeline carries eleven opportunities with stale close dates, that is what surfaces. If your next steps are blank on the deals that matter most, the agent reports blanks. If activity logging is inconsistent by team, the deal health assessment will be inconsistent by team, and it will not tell you that. It will just be quieter and more confident about the reps who log everything.
This is the part worth sitting with. A broken report looks broken. Someone squints at it and says the numbers are wrong. A wrong answer from an agent arrives fluent, structured, and sourced from your own system of record. Nobody squints at that. They act on it.
The failure gets quieter exactly when the stakes get higher.
Six things to check before an agent reads your CRM
None of these are new work. They are the audit you have been postponing, with a new deadline attached.
1. Field decay. Which fields on your core objects are actually maintained, and which are populated by a workflow nobody remembers writing? Every unmaintained field is now a fact the agent may cite. Inventory them, then either fix them or get them off the object.
2. Stale records. Opportunities past their close date, open leads with no activity in ninety days, accounts with no owner. Today these distort a forecast. Next quarter they become the input to somebody's daily action plan.
3. Permission sprawl. Pull every permission set and profile and ask who granted it, when, and whether the reason still exists. Pay attention to View All and Modify All. Pay more attention to sharing rules written during a reorg.
4. Duplicate and conflicting records. Two accounts for the same company has always been annoying. An agent asked about that company will pick one, and will not necessarily mention that it picked.
5. Sync integrity between CRM, MAP and CDP. This is the one most teams have never checked. Partial writes from throttled API calls, schema drift filling fields with NULLs, integration users quietly failing on a subset of records. If your systems disagree, the agent will confidently report whichever side it reached.
6. Activity capture consistency. The skills lean on call, email and meeting history. If half your team uses the native logging and half lives in a separate tool, the agent's read on your pipeline is structurally biased toward the compliant half.
Marketing has a few months of runway. Use them.
Marketing skills are on the roadmap, not in the product. September's beta is sales.
That gap is the most useful thing about this announcement for a marketing ops team, because the readiness work is identical and you get to do it without a live agent narrating your gaps to a CRO. Campaign hierarchy, attribution fields, lead status definitions that mean the same thing to every team, consent and subscription state that agrees across CRM and MAP: all of it will eventually be readable by something that takes it at face value.
The teams that will look competent when marketing skills arrive are the ones that spent this window auditing rather than watching demos.
The honest summary
Connecting the agent is a one-time admin action. Deserving it is a data and access problem, and that problem is exactly as old as your instance.
Salesforce is right that there is no new permissions model to build. That is not the same as saying your existing one is good. Inheriting a mess inherits the mess.
If you have not audited your CRM access model and data quality in the last year, do it before September rather than after. It is a cheaper way to find out.
We run stack audits for growth-stage B2B SaaS teams: permission model, data quality, and the sync integrity between your CRM, MAP and CDP. You get a written findings document and a prioritised fix list, whether or not you ever connect an agent to any of it.
Related: Account audit