IS LIVE
Book a Demo
All Posts
· Laine · 6 min read

MCP for CRM Development: The Week It Grew Up

MCP went stateless and gained enterprise SSO this week — wins for MCP for CRM development, and a reminder of the accountability the spec leaves to you.

AIMCPCRMSentinel
Dark abstract graphic representing the Model Context Protocol connecting AI to a CRM, with a green accent glow

This was the week MCP for CRM development stopped looking like a rough draft. The Model Context Protocol — the open standard that lets an AI like Claude actually talk to your business systems — shipped two changes that matter to anyone who wants an AI to build things inside their CRM: it’s going stateless, and it finally has an enterprise login story. Both are real progress. Neither closes the gap that actually matters once your AI is connected and typing changes into your org. Here’s the week through the Sentinel lens.

MCP is going stateless (release candidate July 28)

On July 20, TechCrunch reported that MCP is breaking with its stateful past. Today, an MCP server has to remember a session ID for every client that connects — fine on one machine, a headache the moment you run the service across a fleet behind a load balancer. Arcade’s Nate Barbettini put the problem plainly: “Now every one of those machines has to know about a session ID that some other machine handed out. It’s not impossible, but it’s a serious pain.”

The fix, landing in a release candidate slated for July 28, makes MCP behave more like an ordinary website: the server stops holding per-session memory, so any machine can answer any request. That’s a boring-sounding change with a big consequence. It removes one of the last operational reasons large companies hesitated to ship first-party MCP integrations, which means more of your tools are about to speak MCP natively.

For our world, the takeaway is simple. The pipe that connects your AI to your systems is getting sturdier and cheaper to run at scale. That’s the on-ramp. It says nothing about what your AI does once it’s on the road.

Enterprise auth showed up — at the door, not the wheel

The second change matters more for buyers. This month MCP’s Enterprise-Managed Authorization extension reached stable status, InfoQ reported. In plain terms: instead of every user clicking through a consent screen at every server, your identity provider handles it once. Log in through Okta — the first identity provider to integrate — and you reach every approved MCP server through a single sign-on. Anthropic, Microsoft, and VS Code are among the early backers, alongside connected servers like Asana, Atlassian, Canva, Figma, Linear, and Supabase.

Read the fine print, though, and one line does all the work. The extension grants connection-level control only — not runtime authorization for individual actions. Or, as the write-up summarizes it: organizations can centrally manage which servers users can reach, but must still implement separate controls for what agents do after connecting.

That sentence is the whole story. Enterprise SSO decides whether your AI is allowed through the door. It does not watch what the AI does once inside, and it cannot undo a bad change. Connection is being solved. Accountability is not.

Meanwhile, the money says agents are already in production

If the protocol news feels abstract, the spending doesn’t. Earlier this month Salesforce committed $1 billion over five years in Switzerland to scale its Agentforce platform, framing it as a national push toward the “agentic enterprise.” The receipts it cited weren’t demos: one virtual-healthcare provider’s agent now handles more than 300,000 customer messages a month, deflecting roughly half of them without a human.

You can argue about the numbers, but not the direction. Autonomous agents are moving from pilot to production, and the vendors are betting real capital that businesses will let AI act on their behalf. That makes the gap above urgent rather than academic. The more your AI is trusted to do, the more it matters that someone can see what it did and reverse it if it’s wrong.

There’s a quieter lesson in the framing, too. Agentforce is an agent working inside a CRM, doing tasks the vendor shipped. That’s a different job from an AI developing your CRM — writing the automation, deploying the field, changing the logic. The industry is pouring money into the first job. The second one is still wide open, and it’s the one that needs the most oversight.

The gap the standards don’t close: accountable development

Stack this week up and a pattern appears. MCP standardized how an AI connects (stateless transport) and, now, who is allowed to connect (enterprise auth). Both are connection problems. Neither is a development problem.

When an AI stops answering questions and starts writing code — deploying an Apex class, editing a workflow, changing a field on 40,000 records — you need three things no auth standard provides: a record of exactly what changed, a snapshot to roll back to, and a rule that two people’s AIs can’t overwrite each other mid-deploy. That is not authentication. That is the runtime layer, and it is precisely where Sentinel’s safety model lives: every action logged, a snapshot taken before each deploy, and one write key at a time per org so simultaneous writes never collide.

We’ve argued before that AI CRM changes belong on a server, not a laptop. This week is the rest of the industry backing into the same conclusion from the authentication side. Standardizing the door is genuine progress. It just makes the question of what happens past the door louder.

What it means if you want AI building in your CRM

If you’re a business owner or operator watching this from outside the spec threads, here’s the practical read. The connection layer is being commoditized — good news for you, because it means connecting an AI like Claude to Salesforce keeps getting easier and more standardized. But “connected” is table stakes. The thing worth paying for is the layer that turns a connected AI into an accountable AI CRM developer: visible, recoverable, and safe for more than one person to use at once.

That’s the whole idea behind Sentinel. Each client gets a dedicated server with key-based MCP access, a full audit log of who changed what and when, and snapshots taken before every deploy — freedom to build with the visibility to undo. Pricing is public and flat: $500/month per Sentinel, plus a one-time $2,500 onboarding on your first one. No per-conversation metering, no six-figure data platform underneath.

The protocol grew up this week. The next question — the one the standards hand back to you — is whether you can see and reverse everything your AI builds. If you want that answer built in from day one, start your Sentinel.

Ready to see what AI can do for your business?

Start a Conversation