The centre of an Agentforce operating model is change rights. If nobody has written down which subagents are on, which actions may change external state, who edits instructions and who can stop the agent, the agent drifts a little in production with every complaint. A proof of concept checks one workflow once; the operating model holds that boundary every week. What the PoC must leave behind is covered in Agentforce from PoC to production.
Four change rights
Since April 2026 Salesforce calls agent topics subagents, with no change of function. The official subagent documentation defines a subagent as one job the agent does. Actions are its tools, and instructions the criteria it decides by. Give the four rights over this bundle to one team, especially the integrator that built the agent, and production becomes an extension of the build.
Scope, meaning which subagents stay on, belongs to the business owner. Refund handling and internal policy search in one agent mix the causes of failure, so each new subagent is approved again with its actions, its test set and the team that receives handovers.
Tools, meaning which actions only read and which change external state, belong to the platform and security teams together. An action that changes state gets its own approval, even when a business team asks to “just add one line”.
Behaviour is set by instructions: refusal and handover conditions, the sentence that forbids answering without a source. The business owner drafts them; the platform team tests and deploys them. Let an integrator or a team lead edit that text in the production console, and the boundary tested yesterday is gone today.
The stop right, deactivating an agent or a subagent when quality drops, requests are misrouted or access drifts, belongs to the operations owner, who writes the stop criterion before the pilot. No number fits every organisation. What counts is a criterion written in advance and one person who can trigger it.
The minimum deliverable is a one-page change contract.
| Change | Approves | Executes | Test | Return path |
|---|---|---|---|---|
| Add a subagent | Business owner | Platform team | Sandbox, full test set | Deactivate the subagent |
| Add or change an action | Platform and security | Platform team or integrator | Sandbox, failure cases included | Remove the action |
| Edit instructions | Business owner | Platform team | Same test set, rerun | Reactivate the previous version |
| Emergency stop | Operations owner | Operations owner | Test before restart | Agreed handover path |
On the L’Occitane Group Service Cloud delivery for Japan and France (2023-2024), changes from headquarters and from the APAC teams went through one validation circuit. An agent needs that rule even more, because one line of instructions moves allowed work, forbidden work and handover conditions at once.
Authoring access is an operating decision
Agent authoring tools make writing an agent fast: a canvas, a script view, simulations. If authoring access is not assigned on purpose, several people build subagents with overlapping scopes, and after an incident nobody can say which scope failed. The platform owner decides who may create and edit agents in sandbox and in production, keeps a named list and reviews it at each release.
Editing instructions and changing a business rule are different rights. Instructions are text the model interprets. A rule that must always hold, such as a refund limit or an identity check, lives in a permission, a validation rule, a deterministic script step or a human approval. Written only in instructions, it can pass a test and fail in the next conversation.
An integrator can build and automate tests. Scope, ownership of knowledge articles and data, and approval of production changes stay in-house. A saved configuration file does not make a change reversible. That takes a previous version that passed the tests and a named person allowed to reactivate it.
Observability numbers are a weekly agenda
Agentforce Observability separates deep analysis of unresolved interactions and session traces (Agent Optimization) from effect metrics such as handover rate and abandonment (Agent Analytics). These numbers become an operating model when they sit on a weekly agenda and every item ends in one of five outcomes:
- observe only, this week;
- edit the instructions;
- restrict an action;
- deactivate a subagent;
- send it to a data or access review.
“Improve the score” is not on the list, because it does not say who changes what.
Set the meeting to the refresh cadence. The same documentation gives about 30 minutes for the Session Tracing data model, 45-60 minutes for analytics metrics, a day for Moments and quality scores, and a week for tags. A quality score read in the morning may still describe yesterday’s conversations when the instructions are edited that afternoon. Data accumulates only once tracing is on, and without analytics access for the operations team, the dashboard stays the build partner’s screen.
Incidents take another path. Agent Health Monitoring evaluates silent failures such as error spikes or high latency every 10 minutes and alerts in near real time. Those alerts go to the operations owner’s stop right; improvements go to the weekly meeting. When misrouting repeats, look for subagents with overlapping names or classification descriptions before adding instructions.
Changes ship only after sandbox testing
The most expensive habit in operations is editing production instructions in reaction to a complaint. Agentforce Testing Center evaluates response accuracy, subagent recognition, action execution and instruction adherence, among others, and warns that tests can change CRM data, so it belongs in a sandbox.
A production change passes four checks again in the sandbox: the right subagent, only allowed actions, no guessing when information is missing, refusal of requests outside the user’s access. The test set behind those checks (normal requests, missing information, ambiguous wording, forbidden requests, requests outside access, action failures) is an operating asset, rerun at every change. Without it, a green result only records that one complaint was calmed down.
When an action reads new objects or calls a new external system, the purpose of the personal data processing and the scope of subcontracting move with it, so write a re-review by the data protection officer into the change contract. And do not extend to a second department before the first workflow is stable. One agent’s success does not stand in for another department’s approval.
What to check
- Is there one page that gives, for adding a subagent, adding an action, editing instructions and an emergency stop, the approver, the executor, the test environment and the return path?
- Can you name everyone who can edit instructions in production?
- Is any must-hold rule written only in instructions?
- Does every weekly agenda item end in one of the five outcomes?
- Was the stop criterion written before the pilot, and is the person who triggers it named?