Why Consultants and Coaches Shouldn't Promise Clients a Specific AI Model

Don't name a specific AI model in your client proposals. The Fable 5 incident made that clear in under 72 hours.

On 9 June 2026, Anthropic launched Claude Fable 5, a public-access version of their Mythos 5 architecture. It was positioned as a significant step up in reasoning capability. Three days later, on 12 June, a US export-control directive pulled it from global access. Gone.

Any consultant or coach who had written "we'll use Claude Fable 5" into a client engagement had an immediate problem on day four.

This is not a one-off. It is the shape of the frontier AI market in 2026. If you build your delivery on a named model, you are one regulatory update, one usage policy change, or one pricing restructure away from a broken promise.

Here is how to stop that being your problem.

What the Fable 5 incident actually tells you

Anthropic confirmed the launch and subsequent restriction publicly. The pattern is worth understanding: a frontier model releases, gets traction, then hits a constraint that is entirely outside the provider's control.

This is not a vendor reliability issue. Anthropic did not pull Fable 5 because it was bad. They pulled it because of export-control law. That distinction matters. No amount of due diligence on your model selection protects you from geopolitical and regulatory shifts. The only protection is structural.

The risk for consultants and coaches is specific:

• You named a model in a proposal or SOW
• A client saw you demo it and expects that exact experience
• You built your workflow prompts to take advantage of that model's specific capabilities
• Your team is trained on that model's quirks

When the model disappears, all four of those become liabilities.

The wider pattern is documented in the Fable rise-and-fall piece. Fable 5 is one data point. The broader message is that the frontier model space moves faster than annual contract cycles.

The fix: capability-based language in every SOW

This is the immediate, practical change.

Stop writing: "This engagement will use Claude Fable 5 / GPT / Gemini Ultra."

Start writing: "This engagement uses a frontier reasoning model of equivalent capability, selected and maintained by [your firm] based on performance, availability, and regulatory compliance at time of delivery."

That one sentence shift does four things:

1. Removes model lock-in from your contractual obligations
2. Signals sophistication to clients who understand the space
3. Protects you legally when a model is pulled or changes pricing
4. Positions you as the expert, not the tool

Clients are not paying for Claude. They are paying for outcomes. If your proposal conflates the two, you have a positioning problem as much as a delivery problem.

If you have not audited how many places a specific model name appears in your client-facing materials, do that today. Proposals, SOWs, onboarding docs, delivery templates. The AI Dependency Audit gives you a structured way to map this.

Why your advisory value rises when models churn

Here is the counter-intuitive part. The Fable 5 incident is bad news for consultants who sold a specific tool. It is good news for consultants who sell judgment.

Every time the model space shifts, your clients need someone to answer:

• Should we move to the new model or stay put?
• Is the capability uplift worth the migration cost?
• What does this change break in our existing workflows?
• When is the cheaper, older model still good enough?
• What do we do if the new model does not match our compliance requirements?

These are not questions a client can answer themselves. They are exactly the questions a well-positioned AI consultant or coach should be fielding. Every model release and every model restriction is a reason for a client to call you.

The consultants who get those calls are the ones who positioned themselves around judgment, not tools.

The ones who do not get called are the ones who set up a workflow, handed over an automation diagram, and disappeared. When the model gets replaced by the next version, those clients have no one to call. They just muddle through. And eventually they hire someone else.

This reframe has implications for how you sell. Your advisory value is in building systems that survive the answer changing, not in knowing which model is best today.

Building a delivery stack that doesn't depend on one model

Resilient AI delivery has three structural components. None of them are complicated. Most consultants skip all three because they are not visible to the client.

1. An abstraction layer

Your prompts, workflows, and templates should reference a configurable model slot, not a hardcoded model name. In practice, this means:

• Your system prompts live in a document or config file, not embedded in a tool
• Switching models means updating one configuration, not rewriting 40 prompts
• Your method is documented independently of any specific model's capabilities

If you are running Claude Code, n8n, Make, or any orchestration tool, this is a 30-minute setup change that can save you days of rework when a model shifts. See how custom AI delivery systems handle this in practice.

2. A documented fallback model

Before any client engagement starts, know which model you would switch to if your primary model became unavailable. Document it. Test your core workflows on it.

This does not need to be a perfect substitute. It needs to be good enough to maintain delivery until you make a more considered decision. Fallback models are usually one tier down from your primary. The cost difference matters too. When a frontier model gets restricted, stepping down to a cheaper model may actually reduce your operating costs while you evaluate alternatives.

3. Human-in-the-loop on client-facing outputs

IBM's framework on human-in-the-loop AI is worth reading in full, but the core point is simple: any output that goes directly to a client needs a human checkpoint before it leaves.

This is not about AI being unreliable. It is about two things:

• Model transitions: When you swap models, the outputs change. Human review catches regressions before the client does.
• Accountability: Your client is paying for your judgment, not a model's output. The checkpoint is where that judgment gets applied.

The checkpoint does not need to be a full review of every word. It is a 3 to 5 minute scan for accuracy, tone, and anything the model got wrong about the client's specific context. Build it into your workflow as a non-negotiable step, regardless of which model you are using.

The AI delivery stack for coaching businesses goes deeper on how to structure this across a full program delivery.

The positioning shift: from prompt hacker to AI orchestrator

There is a version of "AI for consultants" that is shallow and exposed. It looks like: learn the best prompts, use the best model, automate a few workflows, charge for the time saved.

That version is fragile. It depends on the specific model working, the specific tool persisting, and the specific prompts remaining effective. When anything in that chain changes, the value proposition breaks.

There is a different version. It looks like: design a dependable AI-enabled delivery system, document the method, build in resilience, and position yourself as the ongoing guide who manages the system as the space shifts.

Prompting is useful. Orchestration is strategic.

The market for the second version is growing faster than the first, precisely because the model space is churning. Clients who got burned by tool-dependent consultants are now looking for people who build systems, not dependencies. A revenue-first AI delivery model like Njin is built around outcomes and systems, not a single tool. See why AI dependency is a strategic problem, not just a technical one. Getting the architecture right from the start is central to good AI consulting.

For cohort-program owners, the same logic applies. If your program teaches a specific tool or model, every model update is a curriculum crisis. If your program teaches a method for evaluating, selecting, and working with AI systems, every model update is evidence that your curriculum is right. The anti-fragile AI approach for cohort owners covers how to make that shift.

What to do this week

Three concrete actions, in order of priority:

Audit your existing SOWs and proposals. Pull every active engagement document. Count how many name a specific AI model. Prioritise updating any that are mid-engagement or about to renew. The AI Dependency Audit gives you a checklist to work through systematically.

Rewrite your proposal template. One change: replace every model name with capability-based language. "A frontier reasoning model of equivalent capability, selected by [your firm] based on performance and availability." Done. Takes 20 minutes. Protects every future engagement.

Map your abstraction layer. For each workflow you run for clients, note where the model name is referenced. If it is in more than one place, you do not have an abstraction layer. Pick the highest-risk workflow and fix it first.

None of this requires rebuilding your practice. It requires treating model selection as an operational decision you make and maintain, not a fixed specification you hand to clients.

The Fable 5 incident will not be the last. The consultants and coaches who thrive through each one are the ones who designed their delivery to be resilient from the start.

That is the difference between using AI for consultants and building an AI-enabled practice that holds up.

Run The AI Dependency Audit to map where your delivery is exposed to single-model risk. It takes about 12 minutes and tells you exactly where to start.