Tag: Agentic AI

Last updated: 14 October 2026

Update (14 Sep 2026): On 11 Sep 2026 Salesforce announced a new portfolio of named, job-ready Agentforce agents built for specific high-value work: Casey (customer service), Paige (IT and HR service), Carter (shopper agent for e-commerce), Marshall (supply chain orchestration), Piper (inbound lead generation) and Fin (complex customer experience), all generally available now, plus Hunter (outbound sales), in pilot with general availability expected November 2026. The release also adds long-horizon runtime so agents can pursue goals over days or weeks rather than single interactions, AI Skills for teaching agents new tasks (pilot now, GA October 2026), multi-agent orchestration across workflows, and an Agent Optimizer for continuous performance tuning (GA October 2026). This sits on top of the Core, Advanced and Max editions Salesforce introduced in early September.

When Salesforce put its CRM inside Claude in August 2026, the reaction focused on the plugin. The more interesting question is why it was possible at all. The answer is a piece of architecture Salesforce announced four months earlier, and it deserves more attention than it got.

Headless 360 is the reason an external AI agent can read your pipeline, update an opportunity and respect your sharing rules without anyone opening a Salesforce tab.

What Headless 360 actually is

Salesforce’s own definition: “an architectural transformation that exposes every capability Salesforce has built over 25 years directly as an API, a Model Context Protocol (MCP) tool, or a CLI command.”

It was announced on 15 April 2026 at TDX 2026 in San Francisco, under the headline “No Browser Required.”

The framing from the announcement is the clearest statement of intent Salesforce has made about where the platform is going:

In the agentic enterprise, humans aren’t the only ones navigating. Agents are too, and they don’t go to a browser or click through UIs.

The scale involved: 4,000+ existing APIs, 220+ CLI commands, 60+ MCP tools and 30+ prebuilt coding skills, all reachable by an agent that has never rendered a Salesforce page.

One thing it is not, in Salesforce’s own words: “Headless 360 does not replace the Salesforce interface you work in every day.” The panic in some admin communities after the “no browser required” headline was understandable and misplaced.

The four pillars

The metadata pillar is the one that separates this from a generic API integration. An agent hitting a REST endpoint knows the schema. An agent grounded in org metadata knows that your Stage picklist has a value called “Verbal Commit” that means something specific in your business.

The MCP servers Salesforce has shipped

Salesforce’s hosted MCP servers reached general availability on 29 April 2026. The current catalogue:

The separation of reads, mutations and deletes into distinct servers is a deliberate governance decision, and a sensible one. Activating SObject Reads alone lets an agent answer questions without ever being able to change anything.

The Headless 360 MCP server itself

Still in beta as of July 2026, and narrower than the name suggests. It exposes exactly four tools:

• discover – semantic search across a vector index of APIs and skills, returning ranked candidates
• describe – returns the technical contract: APIs, parameters, dependencies and the ordered steps
• dispatch – invokes the skill, routes to the endpoint and enforces user access guards
• dispatch_readonly – the same, restricted to GET operations

Roughly 100 skills at launch, focused on Setup tasks for admins: user management, password operations, permission assignment, Apex trigger management, platform events, Change Data Capture, event relays and named credential configuration. Salesforce says thousands more are in development.

Worth being clear about the beta status. This is a Beta Service under Salesforce’s beta terms, and the skill library is thin relative to the ambition of the announcement.

How your permissions survive the trip

This is the part that determines whether Headless 360 is a governance breakthrough or a security incident waiting to happen.

Salesforce’s clearest statement, from the beta announcement:

If you can’t do it in Salesforce, your agent can’t do it through the MCP server.

Every transaction runs as the authenticated user, scoped through an external client app holding the mcp_api scope. Authentication is per-user OAuth 2.0 with PKCE.

Salesforce describes four enforcement layers on every call:

1. Identity – the agent acts as a specific user, not an anonymous service account
2. Access – sharing rules, field-level security and permission sets apply
3. Invocation scope – only explicitly exposed tools and actions are available
4. Governance – validation rules, triggers, approval chains and governor limits all fire

Patrick Stokes, Salesforce’s president of applications and marketing, put it bluntly when describing the Claude plugin: if you don’t own a record or have permission to see it, the MCP server doesn’t either.

The sentence every admin should read twice

From Salesforce’s own admin blog:

When an agent acts on behalf of a user, it can do anything that user is permitted to do.

That is the whole risk model in one line. Permission inheritance is only a safety feature if the permissions are correct. Every over-provisioned profile in your org – the one that got view-all on a standard object during go-live because it was the fastest fix – has just become an agent-reachable surface.

It was survivable when exploiting it required someone to log in and know where to look. It is materially less survivable when a colleague can ask a question in plain English and an agent will go and find the answer.

This is why a permission-model audit is no longer housekeeping. It is a security control, and it belongs before the pilot rather than after it. Our Agentforce readiness checklist covers exactly what that audit should look for, and our Claudeforce breakdown explains why it became urgent this quarter.

Salesforce also documents a client-side control worth using: MCP clients support tool-level restrictions that require human approval before an agent action executes. Salesforce’s own recommendation is to configure these before allowing configuration changes or data modification, and to test in a sandbox first.

What it actually takes to switch on

Standard MCP servers are inactive by default. Four steps to get an external agent connected:

1. Activate the server. Setup, search for “MCP Servers,” open the Salesforce Servers tab, select the server and click Activate. Copy the API name (drop the platform prefix) and the server URL.

2. Create an External Client App. Setup, External Client App Manager, New External Client App. Then:

• Enable OAuth
• Set the callback URL your client expects
• Add exactly two scopes: “Perform requests at any time” (refresh_token, offline_access) and “Access Salesforce Hosted MCP Servers” (mcp_api)
• Uncheck “Require secret for Web Server Flow” and “Require secret for Refresh Token Flow”
• Check “Require Proof Key for Code Exchange (PKCE)” and “Issue JWT-based access tokens for named users”
• Collect the consumer key and secret from OAuth Settings

3. Connect the client using its MCP add command with the server URL, consumer key and callback port, then authenticate and grant access.

4. Test before you trust it. Salesforce recommends Postman for a smoke test.

Server URLs follow the pattern https://api.salesforce.com/platform/mcp/v1/<SERVER-NAME> for production, with /sandbox/ inserted for sandbox and scratch orgs. API version 67.0 or later is required.

Two gotchas practitioners report that Salesforce’s guide does not mention: PKCE may need enabling globally first under Setup, OAuth and OpenID Connect Settings, and a newly created External Client App can take up to 30 minutes to become usable.

Where the gaps are

Headless 360 is a genuine engineering achievement with three honest weaknesses worth knowing before you plan around it.

Salesforce built the access layer, not the governance layer. There are no quality checks on agent-generated code, no technical-debt assessment, no naming-convention enforcement, no automation-chain validation. Salesforce shipped Testing Center, Custom Scoring Evals, Observability and Session Tracing, which help, but observation is not the same as control. General-purpose code scanners cannot see Salesforce-native concerns such as governor limits, Flow complexity or metadata dependencies.

The builder gap is real. Vernon Keenan’s TDX coverage made the sharpest version of this argument: pro-code developers gained a substantial agentic toolkit while admins and Flow builders got very little, with no visible bridge programme to retool the existing ecosystem. If your Salesforce capability sits mostly with admins rather than developers, Headless 360 does not currently meet you where you are.

Testing headless agents is harder than testing Flows. The debugging habits built around Flow and Apex do not transfer cleanly, which is precisely why Salesforce had to build separate evaluation tooling. Budget for the learning curve.

Bulk operations deserve specific attention. A user with delete rights can, in principle, instruct an agent to delete records at scale. Mitigate with Transaction Security Policies, or by activating SObject Reads rather than SObject All, or by blocking delete tools client-side.

What it costs

Salesforce has published no Headless 360 rate card, and this is the single least documented part of the story.

What is officially stated: MCP access “is included with Enterprise Edition and above – there’s no separate SKU required,” the MCP server “will use your existing API limits,” and “Flex Credits apply when you invoke Agentforce actions, run Data 360 queries, or use Prompt Builder.”

What is not stated: any per-API-call or per-MCP-call price. When CIO asked how API and MCP interactions under Headless 360 are currently billed, Salesforce declined to comment. Salesforce’s CRO said publicly that the company will work with customers “to find the right ways in a fair way to monetize those new interactions.”

The practical read: assume existing API-limit accounting plus Flex Credits on downstream agent work, and get whatever you are told in writing before you scale. Our Agentforce pricing breakdown covers the credit rate card in detail.

How this connects to the rest of the platform

Headless 360 sits inside the wider architecture Salesforce now describes as five systems: Agentforce as the system of agency, Slack as the system of engagement, Tableau as the system of insight, Customer 360 as the system of record, and Data 360 as the system of context.

Two clarifications worth making because commentary keeps blurring them:

Agentforce and MCP are complementary, not competing. Agentforce is where you choose the model and build the agent. MCP is what exposes skills and knowledge to an agent, wherever that agent lives.

Salesforce has not published a link between Headless 360 and the Atlas Reasoning Engine. No primary source connects the two, and Salesforce’s Atlas documentation does not mention Headless 360. The honest framing is that Headless 360 is the access and invocation layer while Atlas is the reasoning layer inside Agentforce. How, or whether, Atlas plans over Headless 360 skills is not documented.

There is also a naming inconsistency worth noting. The Claudeforce press release attributes the plugin’s foundation to AIforce, described as “Salesforce’s enterprise harness that connects business data and workflows to agents through MCP servers, APIs, and CLI tools” – which is Headless 360’s description in substance, under a different name. Salesforce has not published a statement equating them.

What to do about it

If you are an admin: audit your permission model before anything else. Profiles and permission sets with broader access than anyone remembers granting are now the highest-priority item on your list. Then activate the narrowest server that does the job – SObject Reads before SObject All.

If you are a developer: start with the Salesforce DX MCP Server locally and the hosted servers in a scratch org. The Trailhead module and the developer workshop are both current and worth the hour.

If you own the platform: the questions to get answered before a production rollout are what gets logged, what gets retained, where, and how consumption will be billed as volume grows.

If you are a partner or SI: the governance layer between Salesforce’s access layer and a production deployment is not built. That gap is billable work – permission architecture, MCP scoping, agent testing strategy and consumption forecasting. Firms with offshore delivery capacity to staff it have more addressable scope than they did a quarter ago.

Need help with this? Talk to our Salesforce Data Cloud consulting team.

Frequently asked questions

What is Salesforce Headless 360?

Headless 360 is a Salesforce architecture that exposes the platform’s capabilities as APIs, Model Context Protocol tools and CLI commands, so AI agents can use Salesforce data, workflows and governance rules without a user interface. It was announced on 15 April 2026 at TDX 2026.

Does Headless 360 replace the Salesforce UI?

No. Salesforce states directly that Headless 360 does not replace the Salesforce interface, which is not going away. It adds a second way in for agents.

How does Headless 360 handle permissions?

Every call runs as the authenticated user via OAuth 2.0 with PKCE. Sharing rules, field-level security, permission sets, validation rules, triggers, approval chains and governor limits all apply. Salesforce’s summary is that if you cannot do it in Salesforce, your agent cannot do it through the MCP server.

What MCP servers does Salesforce offer?

SObject All, SObject Reads, SObject Mutations, SObject Deletes, Data 360, Tableau Next and Marketing Engagement are generally available. The Headless 360 MCP server is in beta. A Slackbot MCP Client is generally available and requires Enterprise Edition or above.

What does Headless 360 cost?

Salesforce has published no separate rate card. MCP access is included on Enterprise Edition and above, calls use existing API limits, and Flex Credits apply when an Agentforce action, Data 360 query or prompt runs. Salesforce declined to comment when asked how API and MCP interactions are currently billed.

Is Headless 360 what powers Salesforce in Claude?

Reporting on the Claudeforce launch says the plugin is built on Headless 360. Salesforce’s own press release attributes it to “AIforce,” described in almost identical terms. The two are very likely the same substrate under different names, but Salesforce has not published a statement equating them.

Sources

• Salesforce Headless 360 – product page
• Introducing Salesforce Headless 360. No Browser Required. – Salesforce, 15 April 2026
• Headless 360 MCP Server reference – Salesforce Developers
• Connect Claude with Salesforce Hosted MCP Servers – Salesforce Developers
• Introduction to Salesforce Headless 360 for Admins – Salesforce Admins

If you are looking at the non Salesforce route, the same permission and data questions come up in what your ERP and CRM must provide before you build a Claude commerce agent.

Ashapura Softech is a certified Salesforce implementation partner. If you want your org’s permission model audited before you expose it to agents, book a CRM health check. See also our Salesforce DevOps services and Salesforce cloud services.

Agentforce readiness decides whether an AI agent works in production or stalls in a pilot. This checklist covers the five pillars to check before you switch one on.

Last updated: 6 October 2026

Update (14 Sep 2026): On 11 Sep 2026 Salesforce announced a new portfolio of named, job-ready Agentforce agents built for specific high-value work: Casey (customer service), Paige (IT and HR service), Carter (shopper agent for e-commerce), Marshall (supply chain orchestration), Piper (inbound lead generation) and Fin (complex customer experience), all generally available now, plus Hunter (outbound sales), in pilot with general availability expected November 2026.

The release also adds long-horizon runtime so agents can pursue goals over days or weeks rather than single interactions, AI Skills for teaching agents new tasks (pilot now, GA October 2026), multi-agent orchestration across workflows, and an Agent Optimizer for continuous performance tuning (GA October 2026).

This sits on top of the Core, Advanced and Max editions Salesforce introduced in early September.

Most Agentforce pilots do not fail because the model is not good enough. They fail because the org underneath it was never built for something that reads everything, believes what it reads, and acts on it in seconds.

This is the assessment we run before any agentic rollout. It takes about a week for a mid-sized org, it is mostly reporting rather than development, and it will tell you whether you are eight weeks from a pilot or eight months.

Why readiness got harder in 2026

Two things changed this year, and both raise the cost of a messy org.

Salesforce shipped Headless 360 in April, exposing the platform as APIs and MCP tools that external agents can call without a browser. Then in August, Claudeforce put a Salesforce plugin inside Claude with 37 prebuilt sales skills.

Both inherit each user’s existing Salesforce permissions. Salesforce presents that as the security story, and it is a good one – but read the sentence from Salesforce’s own admin blog carefully:

When an agent acts on behalf of a user, it can do anything that user is permitted to do.

Permission inheritance is only a safety feature if the permissions are correct. That is the whole readiness argument in one line.

Pillar 1: Data quality

An agent cannot tell the difference between a stale record and a current one. It will read your pipeline exactly as it stands and produce a confident, fluent, wrong answer.

Run these five reports before anything else. All are standard reporting, none require development.

If 30% of your open opportunities have a close date in the past, a forecast narrative generated from that pipeline does active harm. It reads as authoritative, and someone will act on it.

The fix is rarely a data cleanse. It is usually a validation rule and a process change, because the same conditions will regenerate within two quarters otherwise. Clean once, then enforce.

The field that lies

Every org has fields that are mandatory in process but optional in the schema. A rep is told to fill in Competitor and Loss Reason, nobody enforces it, and 60% are blank.

A human reading the record knows to discount the field. An agent asked “why are we losing to competitor X” will answer from the 40% that is populated and present it as the picture. Selection bias, delivered with total confidence.

List every field your business treats as required and check whether the schema agrees. Where it does not, either enforce it or stop treating the field as a source of truth.

Pillar 2: Permissions

This is the pillar that moved from housekeeping to security control, and it is where we find the most serious findings in almost every assessment.

What to pull:

• Every profile and permission set with View All or Modify All on a standard object
• Every profile with Export Reports
• Sharing rules granting broader access than the role hierarchy implies
• Integration users with elevated permissions and no owner
• Users with permissions inherited from a role they no longer hold

What you will find, in our experience of running this: at least one profile that got View All on a standard object during the original go-live because it was the fastest way to unblock a deadline, and which nobody has revisited since.

That was survivable when exploiting it required logging in and knowing exactly where to look. It is much less survivable when any user with that profile can ask a plain-English question and have an agent go and find the answer across every record they technically can see.

The remediation sequence:

1. Inventory the over-provisioned profiles
2. Find out who actually uses the access, from login and report-export history
3. Move genuine needs into a narrow permission set
4. Remove the blanket grant
5. Retest the affected workflows before you go near an agent

Budget three to four weeks for a mid-sized org. This is the item that most often turns an “eight week” pilot into a quarter, and skipping it is not an option once agents are reading on a user’s behalf.

Pillar 3: Business logic

When work starts in Claude or Slack and finishes in Salesforce, your page layouts stop being where behaviour is governed.

Anything you enforced through interface design – a field that only appears at a certain stage, a button that only some users see, a required field on a specific record type – has to be re-enforced somewhere an agent will encounter it. That means validation rules, flows and the sharing model.

The audit:

• List every business rule currently enforced only by a page layout or a Lightning component
• Check each one has an equivalent validation rule or flow
• Identify flows that assume a human is present – screen flows, confirmation prompts, anything waiting on input
• Find automations that fire on field update and could loop when an agent writes at speed

That last one matters more than it sounds. Automation chains built for human-paced data entry behave differently when something writes forty records in a minute. Governor limits do fire on agent traffic, which is a protection, but hitting them mid-workflow produces partial states nobody designed for.

If your business logic lives in a mix of Apex, flows and process builders accumulated over years, this is the right moment to consolidate it. That is Salesforce DevOps work – version control, a release process, a test suite – and it is the difference between a platform an agent can be trusted with and one it cannot.

Pillar 4: Process

Two questions decide whether a pilot produces a budget line or an anecdote.

Which single workflow are you piloting? Not which platform. One skill, with a measurable before-and-after. Meeting prep and pipeline review are the strongest candidates because both have a time cost you can measure this week without instrumentation.

How will you know it worked? Establish the baseline before you turn anything on:

• Minutes per rep per week on the task today, from a sample of five reps over one week
• The same measurement after four weeks of agent use
• An accuracy check by a sales manager on a sample of twenty outputs
• Whether reps still do the task manually as well, which is the failure mode nobody reports

Resist enabling everything at once. A pilot proving one workflow converts into a budget. A pilot enabling 37 skills produces enthusiasm that evaporates at the next quarterly review. The same principle applies to Sales Cloud ROI work: one workflow, one baseline, one number.

Pillar 5: Measurement and governance

Adoption metrics change meaning. If sellers begin their day in Claude or Slack, Salesforce login counts stop being a proxy for usage. Decide now what replaces them, or you will spend Q1 arguing about a metric that no longer measures anything.

Training changes shape. You are teaching prompting and verification rather than navigation. The most important skill you can build in a sales team is the habit of checking an agent’s output against the record before acting on it. That habit is easy to build in week one and nearly impossible to retrofit after someone has been burned.

Consumption needs an owner. Agentforce meters on Flex Credits, and credits expire at the order end date with no rollover. Somebody has to watch the burn rate monthly. Our Agentforce pricing breakdown covers the rate card and where budgets typically go wrong.

The regulated-industry additions

If you are in financial services, healthcare or life sciences, three more items apply, and they should start before procurement rather than after.

Get the data flow diagram for each deployment path. A single request may touch the model provider, Amazon Bedrock and Salesforce. Ask where data rests and where it is processed at each hop. Salesforce’s Trust Boundary answers this for the Agentforce path by running inference inside its own virtual private cloud. It does not obviously answer it for an external plugin path.

Ask what is logged and retained, and for how long. Then check that answer against your own retention policy rather than assuming they align.

Reuse your existing review template. If you have integrated an EHR or a core banking system, you already have the muscle for this. Teams running Salesforce Health Cloud under HIPAA will recognise most of the questions.

The checklist, condensed

Print this. It is the whole assessment on one page.

Data

• Duplicate account and contact rate measured
• Open opportunities with past close dates measured
• Open opportunities with no 30-day activity measured
• Empty next-step fields measured
• Process-required but schema-optional fields listed
• Validation rules added so the same problems do not regenerate

Permissions

• All View All and Modify All grants inventoried
• Report-export permissions reviewed
• Sharing rules checked against the role hierarchy
• Integration users audited and given owners
• Over-provisioned access narrowed into permission sets
• Affected workflows retested after remediation

Business logic

• Rules enforced only by page layouts identified
• Equivalent validation rules or flows in place
• Human-dependent flows flagged
• Automation loops on rapid writes tested
• Business logic under version control

Process

• One pilot workflow chosen
• Baseline measured before enabling anything
• Accuracy review assigned to a named manager
• Success threshold agreed in advance

Measurement

• Replacement adoption metric agreed
• Prompting and verification training planned
• Consumption owner named
• Monthly credit burn review scheduled

Regulated industries

• Data flow diagram obtained for each deployment path
• Logging and retention confirmed against your own policy
• Security review completed pre-purchase

How long this actually takes

For a mid-sized org with a Salesforce implementation more than three years old:

Roughly eight to ten weeks from start to a pilot with a defensible number attached. Orgs that have kept their permission model tight can do it in five.

The permission remediation is the long pole, and it is also the item most likely to be skipped under deadline pressure. Do not skip it. It is the one whose failure mode is a data exposure rather than a disappointing demo.
Once your org is ready, the next question is where to start. Our guide to Salesforce Agentforce use cases shows what companies have put live in sales, service, marketing, commerce and the contact center.

This checklist matters even if you never build a custom agent. Agentforce Coworker, the AI assistant in the Salesforce search bar, has been switched on automatically in many orgs since August 2026, and it answers questions from whatever your sharing rules allow. See our Agentforce Coworker guide for eligibility, cost and the opt out setting.

Readiness also depends on the release you are on. Our guide to the Salesforce Winter ’27 release lists the 15 changes to test before GA, including Flow Test Mode and new Agentforce quality scoring.

Frequently asked questions

What is an Agentforce readiness assessment?

A structured review of whether a Salesforce org can support AI agents safely and usefully. It covers data quality, permission architecture, business logic placement, pilot design and consumption governance. It is mostly reporting and analysis rather than development work.

How clean does CRM data need to be for Agentforce?

Cleaner than most orgs are. As practical thresholds: duplicates under 2%, open opportunities with past close dates under 5%, and open opportunities with no 30-day activity under 15%. Beyond those levels, agent output degrades in ways that are hard to spot because it still reads fluently.

Why does the permission model matter more with AI agents?

Because agents inherit each user’s existing Salesforce permissions. Salesforce’s own admin guidance states that an agent acting on a user’s behalf can do anything that user is permitted to do. Over-provisioned access that was survivable when it required manual effort becomes reachable through a plain-English question.

How long does it take to get ready for Agentforce?

Eight to ten weeks for a typical mid-sized org, of which permission remediation is three to four. Orgs with a well-maintained permission model can be ready in about five weeks.

Should we pilot every Agentforce skill at once?

No. Pick one workflow with a measurable time cost, baseline it before you enable anything, and have a sales manager review a sample of outputs for accuracy. One proven workflow converts into budget. Thirty-seven enabled at once produces anecdotes.

What changes for Salesforce admins when agents arrive?

The interface stops being the control surface. Anything enforced through page layouts or component visibility has to move into validation rules, flows and the sharing model. That is more admin work, not less, and it is harder to skip.

Sources

• Introduction to Salesforce Headless 360 for Admins – Salesforce Admins
• Salesforce and Anthropic Announce Claudeforce – Salesforce, 26 August 2026
• Anthropic and Salesforce expanded partnership – Anthropic, 14 October 2025
• Flex Credits billable usage types – Salesforce Help

Ashapura Softech is a certified Salesforce implementation partner. Once the readiness gaps are clear the next step is vetting the vendor, and our list of nine questions to ask an Agentforce partner covers what to put in front of them. We run this assessment as a fixed-scope CRM health check covering data quality, permission architecture and automation debt – book one here. See also our CRM software development and Salesforce cloud services, or the delivery work in our case studies.

Editions note, September 2026: Agentforce now ships inside every tier of Salesforce’s new Core, Advanced and Max editions rather than as an add on, which changes what a readiness conversation has to cover. See what replaced Enterprise and Unlimited.

Related reading: readiness is not only an org question, it is a systems question. See the ERP and CRM readiness checklist for Claude Commerce Agents, including which platforms have connectors today.