Your team spent four months building workflows inside an AI tool.
Your team spent four months building workflows inside an AI tool. Custom prompts, trained the team on it, documented everything around that platform’s specific features. It was working.
Then the pricing changed. Or a better model launched. Or a feature got deprecated. And now the team is looking at you asking whether they need to start over.
You’ve probably diagnosed this as a vendor risk problem. Or a “we need to evaluate platforms more carefully” problem. It’s neither. It’s a value location problem. The team put their thinking, their processes, their quality standards inside a product they don’t control.
We see this in almost every company we work with. The AI landscape shifts constantly, and the teams that spend weeks rebuilding after every change aren’t rebuilding because the new tool is hard to learn. They’re rebuilding because their process logic was embedded in the old one. They never separated what they know from where they run it.
The Protocol
Your playbooks are the asset. Your AI tools are rentals.
A playbook is the structured capture of how work gets done: the steps, the rules, the quality standards, the decision logic. Your thinking, codified. The AI tool running that playbook is the execution layer. And if you do it right, that should be interchangeable.
This protocol sits alongside “Think Like an AI Operator” as a mindset shift. That protocol changes what you see. This one changes what you value.
Three Forms of Tool Dependency
Most teams are tool-dependent in ways they don’t recognize until something changes. These are the three we see most often.
Feature-Bound Processes
The team discovers a powerful feature in their AI tool. A specific analysis type, a document handling method, a workflow automation unique to that platform. They build their process around it.
When it’s missing: The team can’t articulate their process without referencing a specific tool. “We use [tool name]‘s feature to do X” instead of “Our process for X is…” If you asked them to describe the workflow on a whiteboard without mentioning any product, they’d stall.
What breaks without it: Every feature change, deprecation, or pricing shift becomes a process disruption. The team isn’t evaluating whether a new tool is better. They’re asking whether they can afford to leave the old one. That’s not a technology decision. That’s dependency.
Prompt Libraries as Process Documentation
Your best AI user has 47 carefully crafted prompts. Refined over months. They produce great results in the tool they were written for.
When it’s missing: Knowledge lives in prompts instead of playbooks. The prompts work, but nobody can explain the underlying logic without running them. When the model updates and half the prompts behave differently, the team doesn’t know what to fix because the reasoning was never separated from the execution.
What breaks without it: Nothing transfers across tools. Nothing survives a model change intact. Every prompt that breaks requires reverse-engineering what the process was supposed to do, not just how it was implemented. Months of refinement become perishable.
Evaluation Without Benchmarks
The team is evaluating three AI platforms. Everyone has opinions. Someone likes the interface. Someone likes the integrations. Someone read a review. The decision takes six weeks and nobody’s confident.
When it’s missing: No playbooks to test against. The evaluation is subjective because there’s nothing concrete to measure. “Which tool is best?” is unanswerable without “best at what, specifically?”
What breaks without it: Tool selection becomes political instead of empirical. The team picks based on demos and marketing instead of performance against their actual work. Six months later they’re evaluating again.
Failure Modes
Tool dependency interacts with the two traps from the previous protocol in predictable ways:
Tool chasing + no playbooks: You evaluate every new tool that launches but have no benchmark to test against. The evaluation never ends because there’s no definition of “good enough for our work.” You’re always shopping, never building.
Settling + tool dependency: You’ve built everything inside one tool and stopped looking at alternatives. Comfortable, until the tool changes. Then you’re stuck, because switching means rebuilding, and rebuilding means admitting you built wrong. So you stay. The tool owns you.
Playbooks exist + still tool-dependent: You documented the process but embedded tool-specific implementation into the playbook itself. The playbook says “use [tool]‘s summarize feature” instead of “produce a summary that meets these criteria.” It looks portable. It’s not.
Where This Sits
This is a Mindset protocol. It changes what you value, not what you build.
The question this protocol teaches you to ask: “If this tool disappeared tomorrow, what would we lose, and how much of that is the tool vs. our thinking?”
Read next: Protocol: The Five AI Ops Roles →
Figure out your path: Who Is This For? →
Stay connected:
I lead a team and want to build an AI-capable organization. [Subscribe to Leading Momentum →]
I’m operationally minded and want to build AI operations skills. [Subscribe to the Operator newsletter →]