When your employer pulls the tool you rely on

Microsoft pulled Claude Code licences from thousands of developers this week. No long runway. No migration path handed down alongside the news. Just a revocation notice and a nudge toward GitHub Copilot.

For most affected developers, the immediate pain is practical: muscle memory broken, config files orphaned, prompting habits that took months to build now pointing at nothing. But the deeper problem is structural. And it affects every agency, product team, and studio that has wired a third-party AI tool into how work actually gets done.

The question is simple. When the licence disappears, what do you still own?

The workflow is the asset, not the subscription

Agencies talk about deliverables. Clients pay for outputs. But the real value a team compounds over time is not in any single file. It is in the workflow: the sequence of decisions, the prompts that encode judgment, the review loops that catch drift before it ships.

When that workflow lives inside a tool you do not control, the asset is borrowed. You are building on rented land.

This is not a new problem. It happened with Sketch when Figma arrived. It happened with every team that built deep Notion automations before Notion changed its API pricing. The pattern repeats: a vendor builds a category, teams embed it deeply, the vendor reprices or pivots, and the cost of switching arrives as a surprise.

What is new is the speed. AI tooling is moving fast enough that vendors are making platform decisions on quarterly timescales, not annual ones. A tool that is standard practice today can be deprecated or redirected before your team has finished onboarding.

What Microsoft actually did

The move is straightforward as a business decision. Microsoft owns GitHub Copilot. It also distributes Claude Code to enterprise customers through its Azure and developer tooling agreements. Pulling those licences and steering developers toward Copilot consolidates spend, reduces a dependency on Anthropic, and keeps users inside Microsoft's surface area.

For Microsoft, this is rational. For the developers affected, it is a live demonstration of platform risk that no amount of vendor trust-building prevents.

Large organisations have IT departments, procurement teams, and enterprise agreements that can absorb a migration like this, even if it is painful. Agencies and smaller product studios do not have that buffer. When your ten-person team loses the tool that three people have built their entire code-review and spec-generation process around, the cost lands immediately and personally.

The interesting part is not the disruption itself. It is what it reveals about where teams have and have not been deliberate about ownership.

Where agencies are exposed right now

Most agencies have not done a tooling audit with ownership as the lens. They have evaluated tools on capability and price. Those are the wrong primary criteria when the tool is going to shape how thinking gets done.

Here is where exposure tends to cluster.

Prompts stored inside vendor interfaces. ChatGPT Projects, Claude's project memory, Copilot Notebooks. If your team's institutional prompts live in these, they are not portable. When the vendor changes the interface, or the organisation loses access, the prompts go with it. The fix is procedural: store prompts in version control, the same place you store code.

Evaluation criteria that exist only in people's heads. AI-assisted review loops only stay sharp if the criteria driving them are written down and stored somewhere the team controls. If the model is doing the evaluation but the rubric was never externalised, you can't port the judgment to a different model when you need to.

Workflows built against one model's quirks. Every model has behaviours. Teams learn them and build around them. Claude handles long context differently than GPT-4o. Gemini's function-calling behaviour differs from both. When a migration forces a model switch, workflows tuned to one model's output style break in ways that are hard to debug under pressure.

None of these exposures are inevitable. They are each a documentation and architecture decision that teams have not yet made.

The case for model-agnostic workflow design

The practical response is not to avoid AI tools or to bet only on open-source alternatives. It is to design workflows so the logic is separable from the interface.

That means a few concrete things.

First, treat prompts as code. They go in a repo. They have commit history. They get reviewed like any other artifact that encodes how the team thinks.

Second, abstract the model call. Whether your team writes actual code or uses a workflow tool, the step that invokes a model should be one configuration setting, not something baked into every node of a pipeline. Switching from Claude to GPT-4o should be an afternoon, not a sprint.

Third, own your evaluation layer. If you are using AI to review work, the criteria for good work belong to you. Write them down. Test new models against them before migrating. The model is the engine. The criteria are the car.

Fourth, keep a vendor map. Know which tools your team depends on, who controls them, and what the migration cost would be if access disappeared tomorrow. Most teams have no idea until they need it.

This is not paranoia. It is the same thinking that led serious engineering teams to avoid vendor lock-in on infrastructure. AI tooling deserves the same discipline.

What this week should change

The Claude Code revocation is a useful forcing function. It is concrete enough to take to a leadership team that has been vague about AI tooling governance. It puts a face on a risk that was previously abstract.

For agencies specifically, the implication runs deeper than tooling. Clients are starting to ask how their own AI-assisted work is structured. If you cannot answer questions about portability, data residency, and what happens when a model is deprecated, that is a gap in your practice, not just your stack.

The studios that will be in the best position twelve months from now are not the ones using the most impressive tools today. They are the ones that have been deliberate about what they own versus what they rent, and have built their work accordingly.

Tooling will keep shifting. Vendors will keep making decisions that serve their roadmaps, not yours. That is fine, as long as your workflow does not live entirely in their house.