Agentforce or Flow? Where deterministic automation still wins

A useful way to start: if you can write the rule down completely, you do not want an agent.

That sounds dismissive of a technology we spend a lot of time implementing. It is not. It is the thing that makes an Agentforce deployment defensible, because the fastest way to discredit agents inside an organisation is to put one in front of work that a validation rule was already doing correctly and for nothing.

#The decision

The last row is the one that changes architectures. It is not a Flow-or-agent question at all. It says that whatever decides to refund, the refund itself executes as a deterministic action with its own guardrails.

#Why "just use the agent" is expensive

Three costs, none of them obvious in a demo.

Consumption. Agentforce is metered per action, with the models published on the Salesforce pricing page. A Flow that runs ten thousand times a day costs nothing per run. An agent doing the same work does not.

Latency and predictability. A reasoning step takes longer than a rule and does not take the same time twice. In a synchronous path a user is waiting in, that is a user-visible regression.

Testability. You can unit test a Flow and get the same answer forever. Evaluating an agent needs a scored regression set and sampling, which is real ongoing effort. Taking on that effort for work that a deterministic rule already handled perfectly is a bad trade, and it is the trade teams make when they treat agents as a replacement rather than an addition.

#Where agents genuinely win

Agentic AI earns its place on three specific things.

Unstructured input, where someone describes a problem in their own words and something has to work out what they mean. Open-ended retrieval, where the answer exists across knowledge, records and history and assembling it is the job. And genuine branching, where the next step depends on what the previous step found in a way you could not have drawn in advance.

Notice that all three are about interpretation. None of them is about executing faster. If a proposal for an agent is really a proposal to do a known thing more quickly, it is a Flow.

#The architecture that actually works

The pattern we build is not either-or. The agent interprets and decides. The actions it can invoke are deterministic, individually permissioned, and frequently Flows that already existed.

That split gives you the useful property: the reasoning is where the ambiguity is, and the irreversible work is behind a gate that behaves identically every time. It also makes the thing debuggable, because when something goes wrong you can tell whether the agent chose the wrong action or the action did the wrong thing, which is a distinction you lose entirely if the agent is doing both.

If your Flow layer is where this lands, the standards question matters more than the agent question. We wrote the decision-recording version of that in Flow or Apex? Write the decision down before you build.

#Placing real requirements

The table is easier to apply against actual requirements than in the abstract. These are the placements we make most often, and the reasoning matters more than the verdict.

The last row is the shape we reach for most. Detection needs interpretation, so an agent does it. What happens next is a rule that must fire identically every time, so a Flow does that. Splitting the two is what makes the behaviour both flexible and auditable.

#Where the boundary genuinely blurs

Two cases resist the table, and pretending otherwise is unhelpful.

The first is a rule that is complete but enormous. Eligibility logic with sixty conditions is fully specified, so by the test it belongs in deterministic automation, and yet nobody can maintain it. The honest answer is that this is a policy problem wearing a technology costume: the rule is not too complex for Flow, it is too complex for the business, and simplifying the policy is the actual fix.

The second is classification. Deciding which of eight categories a request belongs to is interpretation, so it looks like agent work, but if the eight categories are distinguished by a keyword each, a rule does it faster and for nothing. The test here is whether misclassification is obvious to a human reading the input. If two reasonable people would disagree, use an agent. If they would not, use a rule.

#Coexistence is the steady state

Teams often ask when the deterministic layer gets replaced. In practice it does not, and expecting it to is what produces the disappointing version of this technology.

What changes is the interface. Before, a user filled in a form and the rules ran. After, a user describes what they want, something interprets that, and then the same rules run. The rules are still the part that has to be correct, still the part that gets tested, and still the part an auditor will ask about.

This has a practical consequence for how you invest. An org with a messy, undocumented automation layer does not fix that by adding agents on top; it gets a reasoning layer invoking automation nobody understands, which is worse than either problem alone. The order that works is deterministic layer first, agent second.

#The cost of getting the placement wrong

Both errors are expensive, in different directions.

Putting deterministic work in an agent buys you latency, consumption cost and a testing burden in exchange for nothing, and it degrades trust in agents generally, because the first thing people notice is that a form got slower.

Putting agent work in deterministic automation is subtler and more common. It looks like an enormous decision tree that grew branch by branch over two years, that nobody can safely change, and that still fails on inputs nobody anticipated. Every additional branch is evidence the rule could not actually be written down, and the honest response to that evidence is to stop writing branches.

If your Flow has more than a handful of decision elements chasing variations of the same question, that is the signal.

#The question that settles most arguments

When a team is deadlocked on whether something should be an agent, the useful move is to stop debating capability and ask what happens when it is wrong twice in the same week.

If the answer is that somebody notices and corrects it, an agent is a reasonable risk. If the answer involves a refund, a regulator or a headline, the work belongs behind a deterministic gate regardless of how well the demo went, and the agent's job is to bring the request to that gate rather than to pass through it.

#What to expect after adopting Agentforce

Most of your automation stays exactly where it is. In the orgs we have taken through this, the agent adds a new interface onto work the platform was already doing, and the deterministic layer underneath gets more important rather than less, because it is now being invoked by something that reasons.

Teams that expected agents to replace their automation estate generally discovered they had rebuilt a slower, less predictable version of what they already had. Teams that treated agents as a new front door onto a well-built deterministic layer got the outcome they wanted, and they got it faster because the layer was already there.

If you are weighing a specific requirement and cannot place it, the test again is the simplest one available: try to write the rule down. How far you get is the answer.