Agentforce Works Because the CRM Was Already Governed

Salesforce announced Agentforce 360 at Dreamforce (opens in a new tab) in October 2025, and the demo is genuinely good. An agent picks up a case, checks the account, drafts a response, updates the record and hands the exception to a person.

The reason that works is not the model. It is that the CRM already had an object model, a permission model, and an automation engine. The agent did not have to be given a world to act in. It was dropped into one that had been governed for years.

That is the lesson worth taking, and it is the reason most agent projects outside a system of record stall.

The substrate argument

Salesforce agents act on Salesforce objects. An account is a row. A case is a row with a status. A permission set determines which rows a user can read and which fields they can change. Behind that sits a workflow engine that has been running business rules since before anyone said "agent."

Put an agent in that environment and most of the hard questions are already answered:

• Scope. The agent acts as an identity with a permission set, not as a user with a prompt.
• Effects. The allowable actions are create, read, update and delete on defined objects. There is a bounded menu.
• Audit. Field history and record history exist, because the platform had to answer "who changed this" before agents existed.
• Recovery. You can see the record, and often revert it.

None of that came from the agent. All of it is a precondition for the agent being useful rather than dangerous.

An agent is only as governable as the system it acts in.

This is why the enterprise agent market looks the way it does. The vendors with a system of record are selling agents that work in the demo, and the vendors without one are selling orchestration layers that assume you already built the substrate. Both are telling the truth about their own product.

Where the trick does not transfer

Most work in a large organization does not happen in a CRM. It happens in documents, in email, in a case management system from 2009, and in spreadsheets that a deputy director maintains by hand.

Try to move the Agentforce pattern there and the substrate is missing. There is no object model, so the agent has to infer structure from text. There is no permission model at the document level, so the agent's scope is whatever the file share allowed, which is usually too much. There is no field history, so the audit trail is whatever the agent's own log captured.

The failure is not that the model is worse. The failure is that the agent is the first thing in that environment to take action at machine speed, and nothing around it was built to constrain action.

Two consequences follow, and they are worth stating plainly.

First, agents over unstructured documents need a scope control that the document store does not provide. That has to be built, and it is the actual engineering work in most agent programs.

Second, "the agent read the policy" is not a control. If the corpus is the permission model, then anyone who can write to the corpus can widen the agent's behavior. That is a data governance problem before it is an AI problem, which is the argument I made about agentic governance offerings.

What a federal program should copy

Federal work has systems of record, just not the ones the demos use. The financial system, the contract writing system, the case management platform, the personnel system. Those have object models and permission models, and they have audit requirements that predate agents by decades.

The pattern to copy is narrow scope plus bounded effects plus inherited audit.

1. Start where the permission model already exists. An agent inside the ERP is boring and deployable. An agent over the shared drive is exciting and unauditable.
2. Give the agent its own identity. Not a service account borrowed from a person. Its own principal, its own permission set, its own review cycle.
3. Make the action menu explicit. A short list of operations the agent may perform, each mapped to a gate. Reads are free. Writes are reviewed. Sends need a person.
4. Do not let the agent be the only record. The system of record keeps its history, and your own log keeps the intent, the arguments and the approval. When they disagree, you have found a defect.

That last point is where most programs underinvest. The platform's field history tells you what changed. It does not tell you what the agent was asked to do, what it read, or who approved it. Those are different questions, and only one of them is answered by the CRM.

The ceiling is the point

Agentforce is a good product with a clear boundary, and the boundary is the thing to understand before you buy anything similar.

It works where work has already been modeled. Most federal work has not been modeled, because modeling it was never worth the cost while a person was doing it. Agents change that math, but they do not change the order of operations. You model the work, you define the permissions, you instrument the record, and then you let something act.

The vendors selling agents without a substrate are selling you the last step first. The ones with a substrate are selling you a working product inside a fence. Choose the fence deliberately, and know where it ends.