The request that triggered the review never gets filed

Salesforce published its new Core, Advanced, and Max editions on September 3, 2026, and every tier of Agentforce Sales, Agentforce Service, and Agentforce Industries now ships with Agentforce capabilities inside the seat. The governance programme most Salesforce estates built for agents depended on a step the new packaging removes.

The step was the purchase request. When a service leader wanted an agent, someone raised a request for the SKU, and the request landed with a platform owner, a security reviewer, and often a data protection contact. That was the moment governance happened. In the new editions the capability is already owned, so the request never gets raised, and the reviewers do not hear about the agent until it is answering customers.

What arrives in the seat without being asked for

Salesforce's announcement lists Core at $195 per user per month, Advanced at $395, and Max at $550. Every tier includes Agentforce, Slack and Slackbot, embedded analytics through Tableau Next, data security features, and a Premier Success Plan, with Flex Credit pools of 500,000, 1 million, and 2.75 million. Core and Advanced include Momentum, which Salesforce describes as capturing data and updating CRM records. Advanced and Max add sales programs, which the post frames as structured playbooks.

Max carries the items that concern us most. It includes the Agentforce Service Rep Assistant with unmetered Coworker access, Agentforce Workforce Engagement, Agentforce IT Service, and a future allocation of Headless 360 capacity. Salesforce says existing Agentforce 1 customers move to Max at no extra cost. An estate that never evaluated an IT service agent can find itself holding one because a sales leader accepted a free upgrade.

Governance was attached to the order form

On most estates the Agentforce intake form existed, and the reason people filled it in was that the licence did not exist yet. The request for budget forced the conversation about which objects the agent could read, which actions it could take, who owned the instructions, and what rollback looked like. Remove the budget request and the form is still on the intranet. Nobody is compelled to open it.

The pattern is familiar from features that shipped inside an existing licence. An admin turned one on in a sandbox, a change set carried it to production, and the security team first heard of it from an auditor. The difference with Agentforce is what gets written. An agent that updates CRM records from captured conversations, which is what Salesforce says Momentum does, writes into the objects that feed the forecast and the regulatory reports. Our piece on governed CRM data in Winter '27 explains why that data layer needs an owner before agents touch it.

Unmetered removes the last accidental control

Below Max, agent usage draws on the Flex Credit pool. On many estates the credit meter was the only governance control that worked without a policy, because a platform owner who sees consumption climb asks who switched something on. Our piece on the total-cost questions inside the new editions reads that meter from the finance side. From the governance seat it is a detection mechanism, and at Max, for the Service Rep Assistant at least, Salesforce removes it.

Unmetered Coworker access means a contact centre can put the assistant in front of every rep on day one with no budget signal reaching anyone. That is what the tier is for. It also means the question of whether the assistant should see a particular case type, or draft responses on a regulated queue, has to be answered by policy, because nothing else will raise it.

The governance question moves from buying to switching on

Most governance frameworks for Salesforce answer the question of who may buy a capability. The new editions make that question moot for anything inside the tier and replace it with one few estates have written down: who may switch a bundled capability on in production, and what has to be true first. Procurement and the CIO's office owned the buying question. The switching-on question belongs with the platform owner, the security lead, and whoever owns the data the agent will write to.

Our sibling piece on the buying boundary argues the tier decision belongs in architecture review. We'd add that the review produces a list, and the list needs an owner per line. For each bundled item the record should say whether it is on or off, who can change that, and which review runs before it changes. Take Agentforce IT Service in a ServiceNow shop. Someone has to decide, in writing, that it stays off, or the first help-desk ticket it answers will be the first anyone knows about it.

Write the switch-on register this month

The concrete step is a register of bundled capabilities, one row per item in the tier you are on or moving to, with a current state, a named owner, and the review that gates a change. Our licensing change checklist covers the licensing side, and the agent readiness check covers what a row needs before it can move from off to on.

Two things the post does not say belong on the same page. It does not mention Data Cloud, and on most estates that is where the agents will read from, so the Data Cloud entitlement per tier is a question for the account team. It also does not describe how the Coworker access at Max is scoped, so ask whether an admin can restrict the assistant by queue or record type before the upgrade lands. Then ask the next platform meeting one question. Which bundled capability is already on in production today, and who decided?