The pitch and the punchline
This week, Salesforce spent its Dreamforce keynote telling the world the CRM's interface is dead. The flagship announcement is AIforce, and the headline is literally "AI replaces the UI." The pitch: you don't have to come to Salesforce to get work done anymore. Salesforce comes to you — in Claude, in Slack, in Amazon, in whatever AI interface you already live in.
Under the hood it's a data layer with a doorbell: Claudeforce, a prebuilt MCP server living inside Claude with 37 sales skills; Koa, Salesforce's first CRM reasoning model. The CEO put the whole thing in one sentence on stage: "Using AI models alone leads to too many errors to handle work reliably. True enterprise AI can only be realized by running AI on top of existing software that has accurate corporate data and business rules."
Read that twice. The biggest CRM on earth just stood up and said the model is not the moat — the data layer and the business rules are.
Then, hours later, in the middle of the same conference, the data layer died.
The login service that ate its own servers
Salesforce went down. Hundreds of instances across six countries — the US, UK, Germany, France, India, Japan. The root cause, from their own status page: "requests are stalling while waiting on a response from an internal login service, which is using up available server resources."
Not a fancy AI model. Not an agent. A login service. It ate its own server capacity and took the whole platform down with it.
The detail that actually made me stop reading: "scheduled jobs not running as expected." The automation. The nightly data loads. The agentic workflows. All dead — because they all ran on a platform whose login service couldn't answer the door.
So the sequence is this: on stage, Salesforce tells the world "don't come to Salesforce, Salesforce comes to you — AI replaces the UI." Then its login service eats itself, and every scheduled job dies with it.
The system of record the entire "agentic enterprise" is supposed to reason over just demonstrated — on its own stage, during its own pitch — that it is a single point of failure.
Why this is my problem, not theirs
I run sales ops. My CRM is HubSpot, not Salesforce. A reasonable person reads this and thinks, not my vendor, not my problem.
But HubSpot made the identical bet a day earlier. At UNBOUND this week, the headline was "Agent Hub: put agents to work across your customer journey" — and the line that should scare you is verbatim: "when agents run inside the same platform as your customer data, they do not have to start cold."
Same assumption. Same architecture. Same single point of failure. The only difference is that Salesforce's login service went down first.
And here's the part I keep avoiding. I'm about two and a half months into this role, and I've spent the whole time building the "verified layer" — the comp oracle, the lead-provenance checks, the context that makes agents useful. All of it lives inside the vendor. When HubSpot has its own bad login-service afternoon — and it's "when," not "if" — my comp oracle stops computing, my provenance flags stop flagging, my agents stop having data.
I spent a month making my data verifiable. I never once asked whether I could reach it.
Verified for what, if you can't reach it?
The distinction I landed on is uncomfortable because it's obvious in hindsight:
- Knowledge answers "what's true?" — and it's free. A model regenerates it on demand.
- Verified data answers "is this number attributable and correct?" — I've been writing about this for a month.
- Available verified data answers "can I reach the verified number when I need it?" — and the answer, right now, is no. It lives inside the vendor.
A verified number you can't reach during a forecast call is functionally identical to a wrong number. Salesforce just spent a week proving the data layer is the moat — and then its own login service proved the second half of the sentence: it has to be a layer you can reach when it matters.
The part that stings
Here's the thing that actually bothers me. I've been building the answer for a year — for the wrong projects.
GTBrain, my second brain, is a self-hosted fact layer: Express, Postgres, markdown, on a box I own. IndianCoffeeBeans runs on Supabase I own. I built an entire "own your data" philosophy for my side projects, and then I walked into my day job and let the data my paycheck depends on live inside a vendor's login service.
The verified middle layer I've been writing about all month is rented. Salesforce just sent me the bill.
The move: treat the CRM as a cache
So here's what I'm actually doing about it. Not a data warehouse. Not Fivetran. Not a CDP.
A nightly sync. The six or eight CRM objects that actually matter — deals, contacts, activities, lead provenance, comp inputs, forecast stages — into a Postgres box I own. Read-only, with a synced_at timestamp on every row. Then point the oracles and the forecasts at the fact layer first, with the CRM as a read-through cache.
The test is brutal and simple: run the comp oracle while HubSpot is in maintenance mode. If it still returns the same number, the fact layer works.
This isn't vendor paranoia. It's Salesforce's own product strategy, inverted. They said the data layer is the moat. Fine. I'll own the data layer.
The CRM was never the source of truth. It was always a cache. I just never noticed until the cache went down.
The actual lesson
Every layer you rent is a layer that can fail — and "AI replaces the UI" doesn't remove the failure; it concentrates it. The moment you route your agents through a vendor's data layer, that vendor's availability becomes your availability, and their single point of failure becomes yours.
The moat isn't "verified data." It's "verified data you control the availability of." Knowledge is free. Expression gets marked. Verification is the hard part — and verification without availability is a museum piece.
I don't need Snowflake to own six tables. I need a cron job and a box I already run.
So: what's the one number your forecast depends on, and can you still reach it when the login service dies?