Every Agentforce rollout starts the same way: read access first, a few topics, a demo that goes well. Then someone asks the obvious next question. Can it actually update the case? Can it process the refund, not just look it up? That’s the moment the project gets real, and it’s also the moment most teams realise they don’t have an answer ready.
I’ve sat in that meeting more than once. The agent works fine in read-only mode because read-only mode forgives almost everything. A bad query returns the wrong record and someone notices on screen. Write access doesn’t forgive. A bad write closes the wrong case, double-refunds a customer, or fires an email to the wrong contact, and by the time anyone notices, it’s already happened.
Why write access changes the risk profile
A human agent who makes a mistake usually makes one mistake. They’re slow, they second-guess themselves, and they ask a supervisor when something feels off. An AI agent with write access and a bug in its reasoning can make the same mistake a hundred times in the time it takes you to notice the first one. That’s the actual argument for guardrails: not that the agent is untrustworthy in some abstract sense, but that its error mode is different in kind from a human’s. Scale is the risk, not intent.
This is why “it worked in the demo” tells you almost nothing about whether it’s safe to give an agent write access. The demo ran one happy path, once, with someone watching. Production runs every path, continuously, with nobody watching the individual transaction.
The guardrails that actually matter
Scope the permission set to the job, not the object
The standard Salesforce instinct is to grant edit access on a case or an account and call it done. Don’t. Build a permission set that matches exactly what the agent’s topic is meant to do: update status on a specific case type, not edit any field on any case. If the agent’s job is to update delivery status on an order, it has no business editing the billing address on that same record, even though both fields sit on the same object. Narrow the permission set until the agent literally cannot do the thing you didn’t intend it to do, rather than trusting it won’t try.
Put validation in the data layer, not the prompt
A system prompt that says “don’t process refunds over $500” is an instruction, not a control. Agents misread instructions, and a cleverly worded customer message can talk an agent out of a soft rule faster than you’d expect. The actual limit belongs in a validation rule, a flow, or an Apex trigger on the object itself, somewhere the agent can’t negotiate with it. Let the agent attempt the action. Let the platform reject it if it breaks the rule. The agent should never be the only thing standing between a customer and a bad outcome.
Build an approval step for anything you can’t undo
Some actions are cheap to reverse: updating a case description, adding a note, re-routing a routine enquiry. Others aren’t: a refund, a contract change, anything that sends an external communication. For the second category, the agent should request the action and a human should approve it before it fires, at least until you’ve got enough production history to trust the pattern. This slows the agent down on the actions that matter and leaves it fast on the ones that don’t, which is the right trade.
Log what it did and why, not just that it did something
Standard field history tells you a value changed. It doesn’t tell you which topic triggered the change, what the customer said that led to it, or what the agent’s reasoning was at the point of action. Without that, every incident review turns into guesswork. Set up logging that captures the triggering input, the action taken, and a short reasoning trace, and keep it somewhere a support team can query quickly. The first time an agent does something wrong in production, you’ll want this a lot faster than you’ll want to build it.
Testing before the switch flips
Testing an agent with write access isn’t the same exercise as testing a flow. A flow does the same thing every time you give it the same input. An agent can take a slightly different path through the same conversation twice, so a single pass of test cases won’t tell you what you need to know. Run the same scenario multiple times with small variations in phrasing and check that the outcome stays within bounds, not that it’s identical. Then run the scenarios you hope never happen: an angry customer trying to talk the agent into an exception, a request that sits right on the edge of what the permission set allows, a malformed input that a human would recognise as odd. If the agent’s write access only gets tested on clean, polite inputs, you’ve tested the demo, not the job.
What skipping this actually costs
I’ve seen teams treat guardrails as the thing you add once the agent is working, not before. That ordering is backwards, and it’s backwards because of how these failures surface. A flow with a bug usually fails loudly and immediately. An agent with a subtly wrong permission set or a missing validation rule can run correctly for weeks and then fail on exactly the input nobody tested for, at a point where it’s already touched hundreds of real records. Retrofitting guardrails after that happens means an incident review, a rollback, and a much harder conversation with whoever owns the business outcome than the one you’d have had by building the guardrails first.
None of this is an argument against giving Agentforce write access. It’s an argument for treating write access as a separate decision from read access, with its own permission design, its own validation layer, its own approval points, and its own test plan. Get that sequencing right and the agent earns broader access on a track record you can actually point to. Skip it, and you’re trusting a demo to predict production, which it never does.