Most teams adopting AI for delivery are optimizing for one thing: speed of adoption. Pick a tool, build it into your workflows, and move. It feels fast because you are moving fast. But nobody stops to ask the harder question. What happens when a tool in your new workflow doesn't show up for work?
Or worse: what if the platform you run those tools on is just having a bad day and calls in sick?
We found out yesterday.
Claude is our primary work surface. We run most of our client delivery through it, both Claude Cowork and Claude Code, and it has done a lot to make a messy pile of client workflows feel like one place to work. Then, on a heavy delivery day when we needed Claude to show up, our team got the ominous service outage notice.
Claude was down. And this time, it felt like half our company didn't show up for work.
If you use Claude as often as we do, you know outages aren't uncommon. To their credit, they are shipping at a crazy pace, and it would be even wilder if there was never a disruption! But as we scale the codebase our delivery system runs on, those outages hit harder. We rely on the platform more every month, and that reliance has created a new risk surface.
For an AI-native business like ours, a single work surface like Claude is now, besides our people, the most consequential operational risk we carry.
The real cost isn't downtime. The cost is going backward.
When people picture an AI outage, they picture work stopping. In real life, and as an agency operating in this mode everyday, you don't stop; you fall back to the old way of working.
Once you’ve run at the pace these tools allow, the old way is genuinely painful. The whitepaper that took a morning is back to a week of copy-paste and formatting. The ICP you would normally call up in seconds turns into a hunt through Google Drive. The article you would have shipped by lunch waits. Your clients' expectations don't reset because your tool had a bad day. The turnaround they now count on was set by the fast version of you, and on the slow morning you still owe it. That gap between the speed you built the business around and the speed you can hit without your stack is the cost. You feel it in every deliverable that used to be quick.
And the exposure runs deeper than the tool you work in. There are two layers here, and most teams have a backup for neither.
The first layer is the harness, the surface you actually do the work in (think Claude Cowork, chatGPT, etc). The second is the connectors, the pipes into the systems where the work lands. Webflow. Granola. HubSpot. Your CMS and CRM. Those connectors are not resilient in themselves, and they’re constantly changing. This morning, Webflow would not connect from Claude Cowork at all, while it worked fine from Claude Code and from every other AI tool we tried. Same company, same login, one path broken and the rest fine. A connector failure drops you back to the old way just as fast as a harness failure. You are only as portable as your weakest layer.
How we got back up in fifteen minutes
We recovered fast, and not by luck. We recovered because of how the stack was built.
Everything we do is a skill. A skill is a markdown file with instructions, a saved recipe the AI follows. Brand voice, ideal customer profile, whitepaper generation, each one is its own file. Those skills are grouped by client into plugins. The plugins live in a marketplace, and the whole thing is managed in code in GitHub. Our delivery stack is, in effect, a codebase. It is built on an open standard for defining a skill, not on anything proprietary to a single vendor.
That one design choice is what saved the morning. Because the stack was code and the format was open, we pointed it at a different engine. We took the same GitHub repository into Grok, then into Codex, launched it from the same folder the same way we would in Cowork, and ran the same client skills. There was some translation to get another engine to read a stack we had first shaped for Claude, but the assets themselves moved cleanly. From dark to running took about fifteen minutes.
The swap was natural because we were already multi-tool by choice, not just in a crisis. Claude is home base, but we run Grok and Codex for the workflows they handle better. Different engines are genuinely better at different jobs, so we already reached for the right one per task. The outage just proved that the same portability we used for fit, we could use for survival.
Think portable, single sources of truth
The reason the move worked is not the specific tools. It is that we treat marketing delivery the way an engineer treats a codebase, and one principle carries most of the weight. A single source of truth.
In our world, that means every process, standard, and reference we reuse lives in exactly one place, as a skill. A skill packages the knowledge of a workflow, a brand standard, a data mapping, or a template, with its own inputs and outputs. When a delivery surface needs that knowledge, it references the skill. It does not copy it.
That one rule shuts down the two failures that turn AI adoption into chaos. The first is replication: a dozen versions of the same messaging framework scattered across delivery folders, each drifting a little further from the last, and a token tax paid every time someone hunts for the right file. The second is reinvention: two people rebuilding the same ICP or the same whitepaper process from scratch because neither knew the other had already done it. Single-sourced skills remove both. Improve the skill once and every workflow that calls it improves with it.
The payoff is composability. Skills stack into plugins, plugins are organized by client account, and a workflow gets assembled from single-sourced parts instead of rebuilt by hand. That is what lets us run our execution engine as code. It is also the difference between a pile of disconnected Claude chats each improvising and one organized, efficient, AI-native delivery motion.
Here is what that looks like in practice. Take an ideal customer profile. One approach is to write it up, save the document in the client's delivery folder in Google Drive, and move on. It works until you try to use it. Now someone has to remember where it lives, point the AI at it, and spend tokens loading it every single time. Worse, if your work is scoped to a subfolder, the tool may never look up the tree to find it at all. The ICP is right there and still out of reach.
The better version is to promote that finished ICP into a skill. Once it is a skill, it behaves like an imported library. You call it from anywhere, it loads on demand, and it reads the same every time. That is the difference between a filing cabinet and a system. It is the same property that let us move our entire stack into a new engine overnight. The ICP-as-skill and the fifteen-minute recovery are the same principle at two sizes.
Thinking like an engineer inside a marketing team is what pays off here. Same discipline, applied to a different kind of output.
Your over-reliance on Claude risk won’t go away on its own
It is tempting to treat all of this as temporary. Pick whichever model is winning, wait for it to pull ahead for good, and skip the hassle of staying portable. That bet misreads the moment.
We are not heading into a winner-takes-all world where one model rules them all. The lead changes every few months. The engine that is best at long reasoning today gets passed on coding next quarter, then leapfrogged again. That is exactly why we already run Claude, Grok, and Codex side by side, each for what it does best. Betting your delivery on one model winning permanently is betting against the one thing you can count on right now, which is that things keep changing.
And here is the part that holds even if you disagree. Say one model did win outright and stayed ahead. You still would not want your whole company wired to a single vendor's uptime, pricing, and roadmap. Over-dependency is a weak position even when the thing you depend on is excellent. Great today does not owe you great, available, and affordable tomorrow.
Change is constant right now. That makes a backup plan cheap insurance, and it makes skipping one an expensive mistake to get wrong, because the alternative when it breaks is the painful, slow way of working you already left behind.
What it costs to skip this
If you don't build this way, you are one bad morning away from being dragged back to the old pace. And the trigger is not yours to pull. It belongs to a vendor.
You will have rebuilt your business around a speed you cannot reliably hit. Every asset trapped in one tool or buried in a folder is a dependency you cannot see until it snaps you backward. Teams that skip this keep reinventing the same deliverables, and they keep getting surprised when a company they don't own decides how fast they get to move that week.
Redundancy here is not overhead. It is what protects the pace your client promises now depend on.
Oh, and just in case you need this later: https://status.claude.com/
