The most revealing thing Salesforce did this year was quietly take a word off some product names. Sales Cloud is Sales Cloud again. Marketing Cloud is Marketing Cloud. That "Agentforce" prefix bolted onto everything twelve months ago has gone. Plenty of people wrote it off as marketing changing names again. As I've reflected since, I wonder it's the clearest signal of the whole week of the direction things are moving in.
You don't stop branding everything with a word unless that word has stopped describing something you sell. Agents aren't a line on the price list any more. They're how the platform gets reached. In public that showed up as AIforce: your Salesforce data, your business logic and your permissions delivered into Claude, into Slack, into whatever you already have open. Patrick Stokes said it from the stage: the value was never in the UI. It was always in the logic underneath.
I spent most of my three days in nonprofit and insurance sessions rather than platform ones, but also in lots of conversations with System Integrators across the ecosystem. The industry angles gave me a look at what customers who'd already built the thing had done and how Salesforce is now positioning it.
Three things worth your attention
AIforce and the Headless Toolkit. It runs on an open architecture of MCPs, APIs, plugins and skills. Three expressions of it shipped first: Claudeforce, a prebuilt MCP server inside Claude with sales skills. Slackforce. And Agentforce Coworker in Lightning (the normal interface of Salesforce CRM).
The detail I'd underline is the permissions model, because there isn't a new one. Agents inherit whatever the user can already see. I think that is a really important decision and it carries a consequence most orgs haven't thought about yet.
The governance layer shipped at the same time as the agents. This got less coverage, but sitting alongside AIforce is a control plane pulling together Data 360, Informatica for data prep, Tableau for semantics, Salesforce Guardian for agent identity and off-policy detection, and MuleSoft Agent Fabric as a cross-provider registry with budget tracking built in. On the admin side you also got Security Center Essentials as a free posture dashboard, a Compliance Agent surfacing privacy risk, and DSAR handling that reaches across Data 360, Archive and Backup.
Nobody builds rogue-agent detection speculatively. Salesforce has watched agent fleets turn into an operational problem in real customer orgs over the past year, and this is the answer to what they saw.
Salesforce gave up on owning the model. Koa, their first purpose-built CRM reasoning model, runs on NVIDIA's Nemotron and was trained on synthetic data. It's in pilot, but the pitch is that it matches or beats the leading models on CRM actions with roughly a third (in theory) of the errors.
At the same time Gemini went GA in the Agentforce reasoning engine and Claude is available through Bedrock. The whole thing is deliberately multi-model now. So Salesforce isn't competing on the model. It's competing on grounding and governance, which puts an uncomfortable amount of weight on whether your data is actually correct.
What this does to payment operations
Think about how your payment process really works. Someone in finance glances at the direct debit collection file on a Tuesday and notices it's light by about 9k. Someone in customer care spots a refund queued against the wrong installment because the name looked odd next to the amount. Neither of those checks is documented anywhere. They happen because a human looks at a screen every week and the screen looks wrong.
Take the screen out and those controls leave with it.
So the question for the next year isn't which agent to deploy first. Go and ask your finance team which checks only exist because somebody eyeballs a report. You'll get a longer list than you expect, and writing it down is the highest-value afternoon an architect can spend right now as we move into this new world.
You're putting probabilistic systems on top of deterministic money
Models guess well. Payments don't allow guessing. A mandate is valid or it isn't. A transaction reconciles to an installment or it doesn't. There's no confidence interval your finance director will sign off on.
I think my position on where the boundary sits is fairly firm. Let agents read payment state freely. Don't let them write to it without a deterministic gate.
Reading is where most of the value is anyway. "Why did this supporter's payment fail, what are their options, what happens if we retry on the 28th" is a question an agent can answer instantly at two in the morning, and today it generates a support ticket. However, writing payment data is a different animal. Creating a refund, changing a mandate, moving a collection date: those go through the same validated, logged path a human would trigger, with the agent calling it rather than improvising something close to it.
Which is why the Headless Experience Layer interested me. Deterministic widgets bound to real data and real business logic, droppable into any interface, is exactly how that can be handled.
Connected data isn't grounded data
Zero-copy federation will happily hand an agent a quarter's worth of unmatched bank statement lines and raw PSP notifications. The agent can see all of it. It still has no idea which payment belongs to which installment or which contact, so it'll answer your supporter with total confidence and get it wrong. That's worse than not answering.
Reconciliation is what turns transaction data into answerable data. In an agentic world that stops being a back-office nicety and becomes the precondition for anything working at all.
The clearest illustration I saw all week came from The Ocean Cleanup. Aurelia Ferraro walked through their donation certificate agent, which assembles a summary PDF of a supporter's giving on request. Small, unglamorous, genuinely useful. It works because every payment is already in Salesforce, matched to the right contact, in the right currency, with FinDock doing that underneath. The agent is the visible bit. The reason it can answer anything is that the ledger was already complete before anyone asked.
Feeding America made the same point from another angle, describing their move to Nonprofit Cloud with sustainer giving running through FinDock. Neither story was about AI. Both explain why the AI worked.
Inherited permissions
Back to that design decision. If agents inherit user permissions, your sharing model has just become your AI exposure model. Most sharing models were built for a world where somebody had to know where to click. Agents don't click. They ask. That over-permissive sharing rule on payment records or bank details or mandates, the one you've been meaning to tidy up since 2022, is now one plain-English question away from anyone with a login.
Audit the sharing model against your payment objects before you switch Coworker or Claudeforce on. Dull work maybe, but much cheaper than the alternative…
Your audit trail has a new job
Guardian giving agents their own identity matters more in payments than almost anywhere else on the platform. When an auditor or a regulator or your CFO asks who initiated a refund, "an agent did it" isn't something anyone can work with. You need agent X, acting for user Y, under policy Z, at 14:32. If your payment records can't carry that lineage today, keep agents off the write path until they can.
Where the payment layer sits in all this
Our argument at FinDock has always been that payments belong inside the system of record as first-class data. Every transaction, mandate, schedule, failure, retry, refund and match living as Salesforce data, under the platform's own permissions and audit trail.
For years you could make that case on productivity alone. Fewer integrations to maintain, and nobody's Tuesday afternoon lost to a spreadsheet.
That case has become even stronger. Once agents are reading and writing against your payment data, the quality of that data sets the ceiling on how much autonomy you can responsibly hand over. An agent is exactly as trustworthy as the ledger beneath it. If payments land in Salesforce late or partially or unmatched, no reasoning model on the market will rescue the answer it gives your supporter or customer.
That thinking sits behind what we're building with membership and donation forms on Experience Cloud, with Claude in the loop. The conversational surface is the easy part. What makes it work is that a properly structured payment lands behind it, correctly attributed and reconciled without anyone touching it.
What I'd actually do next
If you're planning a roadmap and you have your payment volume on Salesforce, I'd roughly do the following: Audit your sharing model against payment objects before the first agent goes live. Get your finance team to write down the checks that currently live in their heads, because those are about to stop happening. Fix reconciliation properly, since grounding is the whole game and there's no shortcut through it. Start agents on read-only servicing questions where the value is high and the blast radius is small. Decide your standard for agent identity and audit lineage on financial records now, while your fleet is small enough that changing your mind is cheap. Watch agentic commerce closely and don't build on it yet, because merchant of record and dispute liability aren't settled and you don't want to find that out in production.
One last thing, from a slide in a session on the Wednesday. A customer had put up a line that read:
"Technology should not make us less human, it should give us more room to be human."
In this world that's pretty specific. It means a fundraising team that doesn't lose Thursday afternoons to matching bank lines, and a finance team spending month-end on judgment instead of data entry. That's genuinely available to you. It arrives only if the matching is already right while nobody's watching it.