You are my world, until I'm not
I wired my agents through Claude's Gmail and Calendar connectors one integration at a time until the whole operation was resting on it. Then the connectors started breaking. The management surface offered no diagnostics; the only fix was to disconnect and reconnect, like rebooting a Windows machine. This morning I went to do the reboot and discovered the platform itself was down. The connectors had become disconnectors. And when they do, the client blames the builder, not the provider.

The infatuation
The first time I connected Claude's Gmail integration, it was through the website. I could do things with my email right there in the browser; read messages, pull context, find information. It worked. That was enough to be interesting.
I tried it again later and it was broken. Couldn't figure out why. Claude was no help diagnosing its own problem. I gave up and moved on. The kind of early disappointment that's easy to forgive when the relationship is new.
Then I connected Claude Code to the same connectors, and something shifted. It could read my email. Then it could act on it. I started building agentic workflows to handle email and calendar; the kind of automation that takes a domain which frustrates everyone, human and machine alike, and makes it disappear into the background. Each new workflow made the system more capable. The relationship deepened.
I didn't plan to build my entire operational layer on top of one provider's integration surface. Nobody does. It happens the way falling in love happens; one small commitment at a time, until I look up and realise the whole operation is resting on it.
The first cracks
Then the workflows stopped.
I went into the Claude AI dashboard to fix the connectors and found a management surface that was, to be generous, basic. Almost frighteningly simple. There were no diagnostics, no logs, and no explanation of what had gone wrong or how to repair it. The only option that made any difference was to disconnect the connector entirely and reconnect it. The IT equivalent of pulling the plug out of the wall and putting it back in.
Anyone who has ever owned a Windows computer knows this ritual. It worked. But the fact that "turn it off and on again" was the best available fix for a production integration told me something I wasn't ready to hear.
I made excuses. The way one does. Demand is growing. Inference at scale is hard. Growing pains. It'll stabilise.
The last straw
This morning the email connector broke again. I started the familiar routine; disconnect, reinstall, reconnect, move on.
Except when I went to reconnect, I discovered Claude AI's web interface was down. Not Claude Code; my coding sessions were running fine. But the web feature that manages the connectors, the only surface where they can be configured, was offline.
The agents couldn't reach my email because the connector was broken. I couldn't fix the connector because the management plane was down. And Claude Code, the tool I use every day, was humming along perfectly while being unable to do anything about the integration layer it depends on.
The connectors had become disconnectors. And the reboot trick no longer worked because the power was out.
And here's where the metaphor stops being cute. When that client's process breaks, they don't call Anthropic. They don't know Anthropic exists. They bought my solution. My automation. My promise that this runs smoothly. So when it doesn't, the failure wears my name. Their trust erodes against my reputation, not the provider's.
I'm absorbing the reputational cost of someone else's outage, and I can't do anything about it except wait for the platform to come back and explain that the delay was caused by something outside my control. Which is exactly what every unreliable vendor says.
The pattern nobody's pricing in
Scale this out and the picture gets uncomfortable. MCP servers, tool integrations, connector ecosystems; the integration surface across the industry is expanding every week. Every new connection is sold on the promise of capability. Rarely does anyone mention that each one is also a new dependency on a single provider's uptime.
The whole industry is in the infatuation phase. Building deeper, connecting more, wiring everything through platforms whose reliability is trending in the wrong direction as demand for inference outpaces capacity. The convenience is real. The brittleness compounding underneath it is also real, and nobody is pricing it in.
When one connector goes down, it's an inconvenience. When ten go down simultaneously because they all share the same upstream dependency, it's an architecture problem. We're building toward the second scenario at speed.
Staying, leaving, or opening the relationship
The capability these integrations provide is genuine. I built real workflows on top of them and they worked well, right up until they didn't.
But a mature relationship with platform dependency probably looks different from what most of us have now. Fallback paths for critical workflows. Diversifying the providers behind the operational layer. And accepting that convenience and resilience pull in different directions, with a conscious choice about where each workflow sits.
I don't have a tidy answer. I'm still sitting here, waiting for the connectors to reconnect, writing about it because the alternative is going to sit in the park.
Which, honestly, is starting to sound like the most resilient option of the lot.