Agentforce, the Model Context Protocol and what it all means in practice: a plain English guide for charities connecting AI assistants to Salesforce.
A question we hear most weeks now, from fundraising directors and operations leads alike: “our team already uses an artificial intelligence assistant, can it talk to our Salesforce?”
The short answer is yes, and 2026 is the year that stopped being a science project. The longer answer is worth ten minutes of your time, because how you connect matters far more than whether you can. Here is the plain English version.
Route one: agents that live inside Salesforce
The first route is Salesforce’s own: Agentforce, the platform for building artificial intelligence agents that live where your data lives. An Agentforce agent works inside your org, uses the permissions and security model you already run, and acts on records directly: summarising a donor’s history, drafting a follow-up, updating a case.
The strength of this route is that closeness. Nothing leaves the platform, governance is Salesforce governance, and the agent can act rather than just answer. The trade-off is that it is a Salesforce product decision, licensed and configured as part of your org.
Route two: your assistant, connected in
The second route is newer and explains the sudden change in what is possible. Your team’s existing assistant, such as Claude or ChatGPT, can now connect directly to Salesforce through the Model Context Protocol (MCP), an open standard published by Anthropic, the maker of Claude, in late 2024. Think of it as a universal connector between artificial intelligence assistants and business systems: one standard plug instead of a custom integration for every pairing.
Salesforce announced support for the standard in June 2025 and its hosted Model Context Protocol servers, piloted through 2025, reached general availability in spring 2026, included with Enterprise Edition and above at no extra cost. In practice, this means a fundraiser can ask their assistant “which of our regular givers lapsed in the last quarter and what do we know about why”, and get an answer drawn live from your Salesforce, without an export, a spreadsheet or a developer.
One design decision in Salesforce’s implementation deserves highlighting, because it carries most of the security weight: every request runs with the identity of the person asking. The assistant sees what that person can see, and nothing more. Your existing Salesforce permissions, sharing rules and audit trail all apply. Get those right and the assistant inherits them; get them wrong and the assistant inherits that too.
“The assistant sees what the person asking can see, and nothing more.”
Route three: the plumbing
The third route is the oldest: integration tools such as MuleSoft and the platform’s application programming interfaces (APIs), moving data between Salesforce and other systems. This is not new and not specific to artificial intelligence, but it is often the unglamorous prerequisite, because an assistant can only reach the data that has actually made it into Salesforce. If your event platform, payment provider or case management tool holds data your customer relationship management (CRM) system never sees, no protocol fixes that.
Before you connect anything
The technology is now the easy part. These five checks are the hard part, and they are all within your control:
Review permissions first. The connected assistant is only as safe as the sloppiest permission set in your org. If people can see more than their role needs, fix that before connecting anything, not after.
Start in a sandbox. Salesforce lets you enable these connections in a test environment. Prove the value and the guardrails there before anyone touches production supporter data.
Have a written artificial intelligence policy. Which tools are approved, what data may never leave your systems, who authorises new connections. As we noted in our look at the Charity Digital Skills Report 2026, only 36% of small charities have one, and connecting an assistant to your CRM without one is the wrong order.
Mind the data quality. An assistant answering from duplicated, stale records gives wrong answers fluently. The same data foundation that makes supporter communications work makes connected assistants trustworthy.
Keep a human on anything outbound. Answers and summaries for staff are the right starting point. Anything that reaches a supporter, a participant or a funder should have a person approving it while you build confidence.
How we know this works
We are not writing from the brochure. Cirrico runs artificial intelligence tooling connected to our own systems, governed by a written security position covering permissions, approved tools and data boundaries, and we felt the difference within weeks: less time hunting for context, faster preparation, better answers. We also felt where the guardrails matter, which is why the checklist above comes before the enthusiasm.
If your charity is weighing up any of the three routes, or being pitched all of them at once, book a discovery call. We will help you work out which connection serves your mission, and which permissions review needs to happen first.