A few years ago, the conversation about AI ownership focused on data. Who owns the training set? Who owns the model weights? That felt abstract to most practitioners. What feels less abstract now — and a lot more pressing — is a different question: who owns the way work gets done?
Over the past year, workflows have quietly migrated into tools practitioners do not fully control. The prompt that took a week to refine lives inside one product. The rules encoded in an agent about a particular writing style are locked in another tool’s config format. The judgment calls encoded about how to review a pull request — the order of checks, what counts as done, what triggers a second pass — ended up scattered across three environments with no clean way to move them.
This is what one framework calls “procedural debt,” and it is accumulating faster than most of us realize.
The distinction that keeps getting collapsed
There is a difference worth drawing carefully here, because collapsing these three things creates the mess:
A prompt is what you want right now — a single instruction for a single task.
A memory is what an agent should hold about you or a piece of work: a preference, a fact, a prior decision.
A skill is how a type of work should happen, repeatedly. It carries judgment: when to use it, when not to, what sources matter, what the output looks like, what counts as evidence that the work is complete.
Skills are closer to craft than to a checklist. And they are the thing that, if they leave your hands and end up scattered across vendor-specific formats, costs you the most to rebuild.
The one question worth asking
There is a simple test worth applying to any repeated workflow built with an agent: if this skill had to move to a different tool tomorrow, what would break?
When this question is answered honestly, the answer is uncomfortable. A lot would break. Not because the idea was complex, but because the procedure had been encoded in ways specific to one tool’s folder structure, one tool’s loading behavior, one tool’s hook system. The concept was portable. The working knowledge was not.
The concrete failure modes are predictable once you have seen them once. The skill file lands in the wrong folder and is never loaded. The trigger logic assumes a loading model the new tool does not support. Scripts are treated as plain text instead of being executed. A dependency on an MCP server — a server that provides the agent with additional tools or context from outside itself — is simply missing in the new environment. The agent reports the work done, but what it actually did was quietly hand the hard parts back to a human.
What portability actually requires
A file with a procedure written in it is not the same as a portable skill. Portability requires making the harness explicit: where the file installs, how the agent discovers it, what triggers it, what tools and permissions it needs, which external dependencies it assumes, how it proves the work is complete.
This sounds like overhead. In practice it is the difference between a skill that survives a tool switch and one that has to be rebuilt from scratch — and between a skill a teammate can inspect and run versus one that exists only in your head.
The compounding cost of the second kind is real. When improvements to a skill are too hard to share, people stop making them. Lessons stay private. Every new person on a team starts from zero. Every tool switch resets the clock. The people with the best private prompts have an edge today, but the people who can turn repeated work into skills that others can inspect and run will have the durable one.
Where this is going
The honest reckoning is that most of us have been building skills in rented space without fully noticing. The next move is not complicated: treat your working procedures the same way you already treat your documents or your code. Keep the source somewhere you control. Make the dependencies explicit. Ask, periodically, whether you could actually move this.
The tools will keep changing. The models will keep changing. The working knowledge we build on top of them does not have to evaporate every time the environment shifts — but it will, unless we decide it should not.
That is the choice worth making before the debt gets harder to pay down.
Text summarized and optimized using Anthropic’s models and reviewed by a human.