Pretty Close Is Not Good Enough

The short answer. In the debate over deterministic vs probabilistic AI, back office work in Salesforce sits firmly on the deterministic side: auditors need the same input to produce the same output every time. Dreamforce 2026 showed two ways to get there. Either the agent learns a process and executes the same trusted actions every time, or the AI proposes and a person approves before anything is written. Either way, the model stays probabilistic and the write does not.

The clearest statement at Dreamforce 2026 about the limits of AI came from Freeport, the mining company, describing invoice reconciliation:

Your back office transactions need determinism. Pretty close is not good enough when you're processing invoice reconciliations or other things we can do in the back office, right? So we needed the confidence that every time I executed a workflow, we got the same exact repeatable action.

Source: Three Steps From Manual Processes to AI-Driven Operations, Dreamforce 2026

Pretty close is not good enough. Everyone who has had to explain a number to an auditor understands that immediately, and every demo of a probabilistic system should be watched with it in mind.

The same speaker added the part that decides whether any of this gets deployed: "That repeatability and auditability is really important when you're working with your auditors."

Deterministic vs probabilistic: the tension nobody dodged

We expected more hand-waving on this and got less. Siemens CEO Roland Busch put the problem crisply in the main keynote:

This is bringing a probabilistic technology into a deterministic world. Hallucination does not really work on the shop floor, as you can imagine.

Source: Dreamforce Main Keynote 2026, Dreamforce 2026

That is the honest framing. Language models are probabilistic by construction. Enterprise back office work is not. Something has to give, and the interesting question is what.

What actually gives on stage

Watch enough Dreamforce demos in a row and two answers keep appearing.

The first is deterministic execution. In the main keynote's supplier onboarding demo, an agent learns the process in a sandbox and then runs it the same way every time. The presenter's description: "Marshall will package them up, create a library of trusted actions, and that is where AI reasoning becomes deterministic execution." Freeport's answer was the same kind: pre-built agents that follow defined rules.

The second is human approval. In the admin keynote, the build agent produces a brief first, and the presenter is explicit about why:

The brief is here to help you see what the agent understands. What is it going to build? There's some problem statements, solution, some core features, and this is not just a one-way document. You can edit it via conversation, like Kate's going to do here, or you can actually edit it directly and send it to the agent to update it.

Source: Admin Keynote: Bring the Agentic Enterprise to Life, Dreamforce 2026

And the state of the work until you say so:

Now, remember I said there's a project? This stuff's draft. It's not in your org yet. I'm showing you stuff that's not in your org yet. You can modify it before deploying it for the first time, publishing it.

Source: Admin Keynote: Bring the Agentic Enterprise to Life, Dreamforce 2026

Both resolve the tension properly. The model stays probabilistic. The write stays deterministic, either because a learned process runs the same way every time or because a person decided it.

Deterministic execution suits processes that repeat identically, like onboarding a supplier. Most record changes an admin makes are not like that. Each batch is a new judgment, so for those the review step is the route that fits.

Why this matters more for records than for apps

A draft app you can inspect before deploying is good practice. A draft change to four hundred records is the difference between a usable tool and one no admin will allow near production.

The failure mode is specific: an error on one record is visible, and the same error on four hundred records is invisible until a number looks wrong two weeks later. Scale does not just multiply the mistake, it hides it.

That means the review step has to be proportionate to the blast radius. For one record, inline editing is fine. For four hundred, you need to see all four hundred changes, old value beside new, before anything is written.

The three questions worth asking any vendor

1. Can I see every change before it is written, at the size I actually work at? A confirmation dialog saying "update 400 records?" is not a review.
2. Does the write run as me, with my permissions and my validation rules, or as an integration user with broad access?
3. Can I revert the changes I disagree with before anything is written, or is my only safety net a backup and a ticket afterward?

The answers tend to sort tools quickly, and they are more useful than any demo.

Where we come into this

We build for this pattern, so weigh the following accordingly.

In Valorx Wave, the AI builds the view and stages the edit. It never presses Save. You go through every pending change, old value beside new, revert what you disagree with, and save the rest together.

That is not caution for its own sake. It is the only version that gets past the person who has to answer to an auditor, and pretty close is not good enough for them either.

Frequently asked questions

What is the difference between deterministic and probabilistic AI?

Deterministic systems produce the same output from the same input every time. Probabilistic systems, including language models, can produce different outputs from the same input. Enterprise work that auditors review needs deterministic AI behavior at the point of the write, which is why AI is paired with deterministic execution or human approval before anything is saved.

Can AI safely update Salesforce records?

The patterns shown at Dreamforce 2026 keep the write deterministic: either an agent executes a learned process the same way every time, or AI proposes and a person approves before anything is written. For varied bulk changes, the review step is the practical fit.

Why is determinism important for back office automation?

Because auditors need the same input to produce the same output every time. As a Freeport speaker put it at Dreamforce 2026, pretty close is not good enough when processing invoice reconciliations.

What should a review step show for a bulk change?

Every pending change at the size you actually work at, old value beside new, before anything is written. A dialog confirming a record count is not a review.

Sources

Quotes are verbatim from the session captions, with punctuation and capitalization added for readability, and link to the Salesforce+ recordings. Speakers are identified by the company or role given in the session. The main keynote quote is attributed to Roland Busch, who is named in the session listing.

1. Three Steps From Manual Processes to AI-Driven Operations, Dreamforce 2026, Salesforce+
2. Dreamforce Main Keynote 2026, Dreamforce 2026, Salesforce+
3. Admin Keynote: Bring the Agentic Enterprise to Life, Dreamforce 2026, Salesforce+