If your company pays for a Salesforce edition that includes Agentforce, its agents are now on, and the on/off toggle is going away later in Winter '27. Reasonable, and Salesforce kept the controls that matter: an off switch for the feature, an activate switch per agent, a permission for who may build. But on is not approved. Whether an agent may act under your name is three switches: is the feature on, which agents are active, and who says yes before one sends. The vendor flipped the first. The other two are yours, and a team can check them in an afternoon.
If your company pays for a Salesforce edition that includes Agentforce, its agents are now on, and the on/off toggle is going away later in Winter '27. Reasonable, and Salesforce kept the controls that matter: an off switch for the feature, an activate switch per agent, a permission for who may build. But on is not approved. Whether an agent may act under your name is three switches: is the feature on, which agents are active, and who says yes before one sends. The vendor flipped the first. The other two are yours, and a team can check them in an afternoon.
What happened
Salesforce's Winter '27 release is live. It has been reaching production orgs in waves since September, with the last release weekends in early October, per Salesforce Ben's rundown. One item in the release notes is titled "Agentforce Platform Enabled by Default." In Salesforce's words: "In Winter '27, the Agentforce platform is enabled by default for all orgs with Agentforce access, as granted by SKUs, licensing, and editions. New orgs are enabled at creation, and existing orgs will be auto-enabled." The setting that used to turn it on "will be removed from the Agentforce Agents page in Setup, so you can build, test, and deploy agents with one less step." It comes "at no additional cost and there are no changes to billing." Existing orgs have been switched on "on a rolling basis starting the first week of September," and removing the setting "is planned for later in Winter '27." Salesforce Ben reported the change on August 31.
In three sentences: if your company pays for an edition that includes Agentforce, the agent feature is now on. The toggle is going away. Your bill is the same.
Why on by default is reasonable
A capability nobody can find is a capability nobody uses. A toggle in Setup is where features go to be forgotten: somebody meant to turn it on after the security review, the review slipped, and a year later the thing the company paid for is still off. Any vendor that has shipped a feature behind a switch knows this, and turning the switch on for everyone is the plain answer to it.
Salesforce also kept the controls that matter, and said so in the same note. "We continue to offer these controls to manage access to Agentforce." Turning off the Einstein setting in Setup (Einstein is Salesforce's umbrella name for its AI features; Agentforce sits under it) turns the whole feature off. "Individual Agentforce agents are only available to end users when the agent is active. You can activate or deactivate an agent in Agentforce Builder." And building an agent takes a permission, Manage AI Agents, that an admin hands out on purpose. Those are real controls, retained, in writing.
So the point is not the default. The point is narrower. On is not approved.
Whether an agent may act under your company's name is not one decision. It is three, and they sit on three different switches.
The main switch. Is the agent feature on for your company? Who can turn it off, and is that logged? This is the switch the release note is about. Where the answer lives: the vendor's setup page, and its setup audit trail.
The agent switch. Which agents are active right now? Who activated each one, and what can each one touch: which records, which channels, which customers? Where the answer lives: the agent builder, one agent at a time.
The approval switch. For each agent that writes or sends (an email, a record update, a message to a customer), is there a step where a person says yes, and is that yes in the record? Take an agent that watches for a signal (a signal: something a buyer just did, like coming back to your pricing page) and drafts a follow-up. Does the follow-up go out when the agent decides, or when a person does? Where the answer lives: inside the agent's own rule, and in the log of what it ran.
The first switch is a setting. The second is a list. The third is a design decision, made agent by agent, and no vendor can make it for you, because only you know which of your agents writes to a customer and who at your company should be the one saying yes.
Figure 1. On is one switch. Approved is three lines a person wrote. The arrow is the part that just moved.
The switch that moved
For a long time the main switch was off, so the other two did not matter. No agent could act, so nobody had to know which ones were active or who approved what they sent. The main switch was doing the work of all three.
When a vendor flips the first switch for you, the other two land on your desk, and their default answer is "whatever the agent was configured to do when it was built." That is the fear, stated plainly: an agent someone activated for a test, with a permission to write that it did not need, is now live in a production org, because the setting that was keeping the whole feature quiet is gone. And the fix, in the same breath: not turning the main switch back off. The fix is a list. Open the agent builder, read the active agents, and write one line under each: who owns it, what it can touch, who says yes before it sends. If a line is blank, that agent is running under your name with no owner, and it is the first one to fix. That is an afternoon's work for most teams, and it is the work the default just assigned to you.
This is the same shape as last Monday's piece, The Context Layer Is Not the Decision: of the three layers in any agent-run step (the context, the signal, the decision), the decision is the one to own. It is also the question Chris Hart, Civic's CEO, put to every agent demo from Dreamforce week, Salesforce's conference, in Your Pipeline Runs Across Six Tools: "Who approved the agent's authority, where is that approval recorded, and how do I change or stop it?" The release note answers that for the main switch. The other two are yours to answer.
The three-switch check
Answer for one tool you run. Three switches, a question or two each. The line beneath reads your answers back.
The three-switch check
One tool that runs agents for you. Answer each switch. The line beneath reads your answers back in plain words.
(illustrative; answer for one tool you run)
Three switches, the question each one asks, and where the answer lives (static view).
Switch
The question
Where the answer lives
Main switch
Is the agent feature on for everyone, for some, or off? Is the off logged?
The vendor's setup page and its setup audit trail.
Agent switch
Does every active agent have a named owner: yes, some, or no?
The agent builder, one agent at a time.
Approval switch
Do the agents that write or send wait for a person: all, some, or none?
Inside each agent's own rule, and in the log of what it ran.
Switch 1The main switch
Where the answer lives: the vendor's setup page and its setup audit trail.
Switch 2The agent switch
Where the answer lives: the agent builder, one agent at a time.
Switch 3The approval switch
Where the answer lives: inside each agent's own rule, and in the log of what it ran.
Answer the three switches to read this tool back.
Figure 2. The point is the sentence: it tells you which switch to go and look at. What you see: three switches, a question or two each, and a line beneath that reads your answers back in plain words; without scripts, a three-row table of switch, question and where the answer lives (illustrative; answer for one tool you run).
There is no score, because the sentence is the finding. "The main switch is on for everyone and the off is logged; some active agents have a named owner; none of the agents that send wait for a person" tells you which switch to go and look at, and it is not the first one.
Where Bryn sits
Bryn, Civic's GTM Agent (GTM, the sales and marketing side of the company), is an agent that writes and sends under your name, so the three switches apply to it too. Bryn watches your site and product for buyers, works out who they are, decides if they're worth acting on, and runs the follow-up you approved, within minutes. Every run is logged, so the people who sign off can read it.
The third switch is built into every rule. A rule you set once (when this happens, do that) is what Bryn calls a Play. Each Play carries a mode, Run or Approve. In Approve mode Bryn drafts the step and waits for your yes. The mode lives on the Play itself, so "does this agent wait for a person before it sends" has a written answer, per Play, next to the rule. Pausing a Play is one click, and the pause is logged.
We wrote about why the yes belongs inside the rule in Approve Mode Is Not a Speed Bump, and about what the record looks like when the answer is "do not act" in Show Me a Blocked Action. Bryn is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack. In plain terms: it runs the follow-up through the tools you already use, with the yes written into the rule.
Do this Tuesday
Pick one tool that just turned its agents on for you. Run the three switches. For the main switch, write down who can turn it off. For the agent switch, write the list of active agents with an owner beside each. For the approval switch, write the agents that send or write, and whether a person says yes before they do.
The vendor flipped the first one. That was reasonable. The other two were always yours.
Stop watching signals. Start running them.
BRIEFS ⬩ PUBLIC PREVIEW
Next: a Brief on your own site.
Bryn reads your site and works out which companies are already looking at you, and whether they're worth your time. Then it writes up the first follow-up it would run, in your own colors, inside a minute. It takes a few minutes to read. Then pass it to whoever signs off.
