Agentforce Turns Itself On

Salesforce has started switching Agentforce on in orgs that never switched it on themselves. The rollout is happening now, on a rolling basis, and the Winter '27 release notes say the setting that used to control it is being taken out of Setup.

The release note is short and the language is friendly. In Winter '27, the Agentforce platform is enabled by default for every org with Agentforce access, as granted by SKUs, licensing and editions. New orgs are enabled at creation. Existing orgs are auto-enabled. The Agentforce setting is removed from the Agentforce Agents page in Setup so you can build, test and deploy agents with one less step.

One less step is an accurate description. It is also a description of a decision you no longer get to make.

What Actually Changed

The scope is broad. Lightning Experience orgs running Foundations on Enterprise, Performance, Unlimited and Developer Edition are in it, as are orgs on Agentforce 1 Edition. If your contract grants Agentforce access, the platform gets turned on for you.

The timing shifted. Salesforce originally planned to begin enabling existing orgs in August. That slipped, and the rolling enablement started in the first week of September instead. The removal of the Setup toggle is scheduled for later in the Winter '27 window rather than on day one, which means there is a period where the setting still exists and is already switched on.

Salesforce is explicit on the commercial point: the platform is enabled at no additional cost, and there are no changes to billing. That claim is about the platform being available, not about what happens when an agent starts consuming Flex Credits. Enabling a capability and metering a capability are separate events, and only the first one is free.

Enabled Is Not The Same As Running

This is the distinction that decides whether you need to care.

Auto-enablement turns on the Agentforce platform. It does not create agents, activate agents, publish agents to a channel or point anything at your customers. An agent still has to be built in Agentforce Builder and explicitly activated before it does anything. Nobody woke up on Tuesday to find a bot answering their cases.

So the risk here is not runaway automation. It is surface area and inventory drift.

Before this change, an org with Agentforce switched off was, for practical purposes, outside the agent conversation. It appeared in no agent audit because there was nothing to audit. After this change, that same org has an enabled AI platform, a Builder that administrators can reach, and a set of permissions that decide who else can. If you run a fleet of orgs and your security model assumed "we never enabled it there", that assumption expired this week.

Salesforce's own documentation is direct about the posture: agents respect licences, permissions, field-level security and sharing settings, which means an agent inherits exactly the access of the user context it runs in. That is the correct design. It is also the reason Agentforce is not secure by default. It is secure to the degree your sharing model already was, which for most orgs with fifteen years of history is a sentence that should make you open a report.

The Controls You Still Have

Three controls survive, and they are worth knowing before somebody asks you in a change advisory board meeting.

The Einstein setting is the real kill switch. Agentforce runs on top of Einstein generative AI. Turning off the Einstein setting on the Einstein Setup page turns the Agentforce platform off with it. Once the Agentforce toggle is gone from Setup, this is the org-level off switch, and it is a blunt one: it takes other Einstein features down with it. Know that before you reach for it in a hurry.

Agent activation stays manual. Every agent has to be activated or deactivated in Agentforce Builder. That control is untouched, and it is the reason auto-enablement is a governance event rather than an incident.

The Manage AI Agents permission is now the boundary that matters. Administrators with Einstein generative AI already enabled get immediate access to Agentforce Builder. Everyone else needs the Manage AI Agents permission assigned to them. With the platform on across the estate, that permission stops being a formality on a checklist and becomes the line between "three people can build agents here" and "nobody knows who can".

If you do one piece of work off the back of this news, it is pulling the list of users who hold Manage AI Agents in each production org and confirming that list matches somebody's intention.

The Same Week, In Front Of Analysts

The investor webinar we flagged on Monday actually happened on Tuesday morning, and the read-outs are now public.

Bill Patterson, Chief Commercial Officer, and Connor Marsden, President of Sales, ran the session. Roughly forty attendees, roughly forty minutes of questions. The topics were AI momentum, the headless platform strategy, Slackbot, Claudeforce, and evolving pricing and packaging.

Analysts liked it. Cantor Fitzgerald raised its price target from $250 to $300 on Wednesday and kept an Overweight rating, pointing at a 77% gross profit margin, a PEG ratio of 0.39, and an "open platform" story that reduces the incentive for customers to reopen their CRM contracts. TD Cowen's Derrick Wood had moved to $300 from $280 the day before on the back of Claudeforce, calling the Anthropic partnership a major development for the software business generally. Argus and Truist landed on $300 as well. Citizens sat at $315 with a Market Outperform. The shares were around $258 against a 52-week high of $269.11.

Put the two stories side by side. In the same week that Salesforce told analysts its pricing and packaging are evolving, it switched the agent platform on across a large part of its installed base. Those are not connected by any announcement, and there is no evidence they are connected by intent. They are connected by arithmetic. A platform that is on everywhere is a platform that can be metered everywhere, and the Agentic Work Unit is the unit both the investor deck and the Flex Credits rate card are counting.

The Other Default Moving Under You

Auto-enablement is not the only default changing this cycle, and the second one has a date on it.

Salesforce is rerouting Gemini 2.5 Pro, Flash and Flash-Lite requests to their Gemini 3.5 equivalents on October 20, 2026. If your prompts, prompt templates or Einstein Studio configurations were tuned against a 2.5 model, they will be answered by a 3.5 model on that date whether or not you tested. Salesforce's own guidance is to retest in Prompt Builder and Einstein Studio because expected responses can change with the model version.

That is the same pattern as the Agentforce toggle. A thing you configured is being replaced by a thing Salesforce configures, on a schedule Salesforce sets, with a note in the release notes as the notification mechanism.

Meanwhile the Winter '27 upgrade waves keep moving. Salesforce Trust lists production upgrade dates of August 29, September 5, October 3, October 9 and October 10. Roughly ten instances landed on the September 5 wave, and the volume waves are in October. Preview sandboxes opened on August 28. Check your own instance on Trust rather than assuming a wave, because the enforcement list moved twice in the ten days before the first upgrade.

What To Do This Week

Record the current state in every production org. Open Setup, check Einstein Setup and the Agentforce Agents page, and write down whether the platform is already enabled. The rollout is rolling, so the answer will be different across your estate this week and the same next month. A dated record is what turns this from a surprise into a change you tracked.

Export who holds Manage AI Agents. In each org, per user and per permission set. Confirm every name is deliberate. This is the single highest-value hour available to you right now, because it is the control that is left standing after the toggle goes.

Inventory the agents that are actually activated, and the context they run as. Agents inherit the access of the user they run as, so an agent running under a legacy integration user with a wide profile is a data exposure question wearing an AI costume. Spot check three of them against field-level security and sharing before Dreamforce, not after.

Retest anything tuned to Gemini 2.5 before October 20. Prompt templates and Einstein Studio configurations included. Then confirm your Winter '27 upgrade date on Salesforce Trust so the retest lands before the release does, not after it.

The honest read is that this change is defensible. Removing a toggle that almost every customer eventually flips anyway is a reasonable product decision, and Salesforce has kept the two controls that carry actual risk. The part to watch is what "on by default" does to accountability. When enabling something required a click, somebody owned that click. Now nobody does, and the only record of the decision is a release note. Write down the state of your orgs this week, and you will still have an answer when an auditor asks who turned it on.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.