Vendor Lock-In By Capability: When A Skill Dependency Becomes A Strategic Risk

TL;DR

A skill that is the only way to do something inside your agent runtime is a strategic dependency, regardless of price, license, or technical quality. The day the skill author becomes a competitor, raises prices, deprecates the version you depend on, or simply gets acquired by someone whose interests diverge from yours, the dependency stops being neutral and becomes a lever someone else holds. The pattern that prevents this is older than the agent economy: identify single-source skills, evaluate the substitutability of each, plan the exit, and document the result. This post walks the audit pattern, gives you the substitutability framework, and ends with a Skill Lock-In Risk Register you can populate against your own registry today.

Intro: The Skill That Owned The Workflow

A company I know runs a sales agent that handles outbound prospect research. The agent imports about a dozen skills, but one of them — a skill that produces enriched contact records by combining several public data sources with a proprietary scoring layer — is the work. Every other skill in the agent's toolkit is generic: HTTP, JSON, calendar, email. The enrichment skill is the thing that makes the agent commercially viable. Without it, the agent is a shell.

The enrichment skill comes from a vendor that, at the time of adoption, was a small team building a specialized product. The team has since been acquired by a larger company. The larger company has reorganized the product roadmap. The pricing model has shifted twice. The version of the skill the agent depends on has been marked end-of-life with a six-month sunset. The replacement version requires a new manifest, broader capabilities, a different output schema, and a four-times-higher per-call cost. None of this is unreasonable from the vendor's perspective. None of it is recoverable from the customer's, except by replacing the skill.

The customer is now in a procurement crisis they did not see coming, because they never reasoned about the skill as a strategic dependency. They reasoned about it as a feature. Features are easy to swap. Strategic dependencies are not, because the work that flows around the dependency — the agent's instructions, the pact's commitments, the customers who came to expect the resulting behavior — has accreted assumptions that the substitute has to honor. Replacing a strategic dependency is not a one-week refactor. It is a multi-quarter program that touches every artifact downstream.

This is vendor lock-in by capability, and it is the next phase of strategic risk for any operator who runs agents at meaningful scale. Lock-in by license is well understood — proprietary formats, restrictive terms, exit-cost clauses. Lock-in by data gravity is well understood — large datasets that cost more to move than to keep where they are. Lock-in by capability is newer, and it is sneakier, because the dependency does not look like a vendor relationship. It looks like a skill in a registry. The fact that the skill is the only one that can do the work is invisible until the day you need a substitute and discover there is not one.

This post is the audit pattern that surfaces these dependencies before they become crises. The pattern has three steps: identify single-source skills, evaluate the substitutability of each, plan the exit. The deliverable is a Skill Lock-In Risk Register that an operator maintains continuously and consults whenever the skill registry changes or the vendor landscape shifts. The work is not glamorous. It is the kind of work that pays for itself once and then sits quietly for years until the day it pays for itself ten more times.

Section 1: What Counts As Single-Source

The first step in the audit is identifying which skills in your registry are single-source. The answer is not as obvious as it sounds, because "single-source" can mean several different things, and the implications differ.

The simplest case is single-author single-distribution. A skill written by one party and distributed through one channel. There is exactly one supplier; there is no competing implementation. If the supplier raises prices or pulls the skill, you have no immediate alternative. This is the strongest form of single-source and the easiest to identify: count the publishers of each skill in your registry, flag the ones with a count of one.

The slightly more subtle case is multi-author with capability monopoly. There are several skills that nominally do the same thing, but only one of them actually performs the operation you depend on. The others handle adjacent cases or earlier-generation versions of the work. From a registry headcount perspective the skill looks competitive; from a capability perspective it is single-source for your use case. This is the case that requires reading the skills, not just counting them.

The most subtle case is the one where the dependency is on a shared underlying provider, not the skill itself. Five different skills all wrap the same upstream API. The skills compete with each other on quality, price, and ergonomics. But the upstream API is the actual single point. If that API changes its terms, all five skills are affected together, and the apparent diversity of the skill registry is misleading. This requires looking through the skill at what it depends on, not just at the skill itself.

The inverse case is also worth flagging: skills that are themselves single-source but operate in a capability area where you have multiple skills providing comparable function. The skill is single-source as an artifact, but the function it provides has alternatives. This is structurally similar to depending on a single brand of laptop while many laptop brands exist — the brand is single-source, but the function is substitutable. The risk is lower than true capability monopoly, because the cost of replacement is bounded by the cost of swapping to an alternative skill, not by the cost of finding any alternative at all.

Operationally, the audit produces a four-cell matrix per skill: single-author yes/no on one axis, single-capability yes/no on the other. The high-risk cell is single-author single-capability. The medium-risk cells are single-author multi-capability and multi-author single-capability. The low-risk cell is multi-author multi-capability. The first pass through the registry sorts every skill into one of the four cells. The second pass works on the high-risk cell, then the medium-risk ones.

The data that drives this audit comes from three places: the registry's metadata about authors and versions, your own runtime's import history showing which skills your agents actually use, and a manual or semi-automated reading of the capability surface each skill exposes. The metadata is easy. The runtime history is moderate. The capability reading is the hard part, because it requires understanding what the skills actually do, not what they advertise. Skills that do not document their actual capability surface in machine-readable form make this harder, and that is itself a procurement signal.

Section 2: The Substitutability Matrix

Once you have identified the single-source dependencies, the second step is evaluating how substitutable each one is. Substitutability is not binary. It is a multi-dimensional property that determines how feasible an exit would be if you needed one. The matrix has five dimensions, and a skill's overall substitutability is the product of its scores on each.

The first dimension is functional equivalence. Is there another skill, in the registry or in the broader ecosystem, that performs the same operation with comparable output? If yes, substitutability on this dimension is high. If the only candidates require significant adaptation of downstream code, substitutability is medium. If no candidates exist and you would have to build one, substitutability is low. This dimension is what most people mean when they say "is there an alternative," and it is the necessary first check, but it is not sufficient.

The second dimension is interface compatibility. Even when functional equivalents exist, their interfaces — input shapes, output shapes, error semantics, capability declarations — may differ. A substitute that does the same work but expects different inputs and produces different outputs requires adapter code at every call site, modifications to the agent's instructions to handle the new shapes, and potentially changes to downstream consumers that depended on the old output format. High interface compatibility means a near-drop-in replacement; low compatibility means a refactor.

The third dimension is data lock-in. Some skills accumulate state — caches, indexes, learned models, historical records — that does not transfer to a substitute. A skill that has been running for two years in your environment may have built up state that gives it advantages over a fresh substitute. Switching to the substitute means starting over on that state, which can be a real cost in performance, accuracy, or capability. High substitutability means the state transfers or is not load-bearing; low substitutability means the state is a moat the substitute cannot cross quickly.

The fourth dimension is workflow integration depth. How many other skills, agents, pacts, and downstream systems depend on the specific behavior of the skill in question? A skill that sits at the edge of the agent's work and produces outputs that one downstream consumer depends on is shallowly integrated. A skill that produces outputs flowing through ten downstream systems, embedded in instructions for fifty agents, referenced in pacts that twenty counterparties subscribe to, is deeply integrated. The deeper the integration, the more the substitute has to honor the precise behavior of the original, which narrows the field of viable substitutes.

The fifth dimension is contractual or regulatory constraints. Some skills are tied to compliance regimes — a skill that produces records expected to satisfy specific regulatory standards, a skill that is the certified path for a particular workflow, a skill that holds compliance attestations counterparties demand. Substituting in this case is not just a technical question; it is a recertification question. Substitutability on this dimension depends on whether the substitute can quickly inherit the same compliance posture or whether the operator has to start the certification clock over.

A substitutability score on each dimension lets you produce a composite — high, medium, low — for the overall substitutability of each single-source skill. The composite is not a precise number; it is a sorting key. The skills with the lowest composite substitutability are the ones whose lock-in poses the highest strategic risk. They go to the top of the register. They are also the ones where exit planning needs to start now, not after the lock-in becomes a problem.

Section 3: The Vendor Trajectory Question

Substitutability is the static property of the lock-in. Vendor trajectory is the dynamic property. A single-source skill from a vendor whose interests align with yours and who is committed to the long-term maintenance of the skill is a different risk profile from the same skill from a vendor whose strategic direction is moving away from your use case.

The first trajectory question is alignment of interests. Is the skill author building toward the same future you are building toward? A skill author who depends on you as a customer for their core revenue and whose product roadmap is shaped by feedback from customers like you is aligned. A skill author whose roadmap is shaped by larger customers with different needs, or by an investor pushing for monetization changes, or by an acquirer with a different strategic focus, is misaligned. Misalignment does not mean the relationship breaks immediately, but it means the relationship is on a trajectory away from your needs.

The second trajectory question is durability. How long has the skill been actively maintained, and what is the continuity of the team behind it? A skill maintained by a stable team for several years is more durable than a skill that has changed hands twice in twelve months. Durability also includes the financial state of the vendor: a vendor whose revenue covers their cost structure is durable; a vendor running on runway with no clear path to break-even is not. The durability assessment is partly observable from public information and partly inferred from indirect signals — release cadence, response to issues, public communications about strategy.

The third trajectory question is monetization model. A skill provided free or at near-cost is likely to either be subsidized by another business model or to face pressure to monetize over time. The free model is unstable in either direction: it may shift to paid, raising costs unexpectedly; it may be deprecated when the subsidy runs out. A skill provided at a sustainable commercial price is more predictable, even if more expensive. The trajectory question here is whether the current monetization model is stable for the duration you expect to depend on the skill.

The fourth trajectory question is strategic ownership. Who controls the skill, and what is their incentive structure? An independent vendor is a different actor from a vendor owned by a larger platform that competes with you. A vendor that has signaled an intent to compete in your market segment, or has been acquired by one that does, is a vendor whose interests now diverge from yours. The lock-in becomes a strategic problem when the lock-holder has reason to use the lock against you.

The fifth trajectory question is exit option preservation. Does the vendor make it easy to leave, or do they accumulate moats that make leaving harder over time? Vendors who maintain compatibility with open interfaces, publish migration guides, or actively support multi-vendor postures are vendors who are not relying on lock-in for retention. Vendors who deprecate compatibility, hide migration paths, or progressively expand the surface area of their dependency are vendors whose retention strategy includes the lock.

The trajectory assessment combines with the substitutability assessment to produce the actual risk profile. A high-substitutability skill from a misaligned vendor is medium risk — easy to leave but motivated to make leaving harder. A low-substitutability skill from an aligned vendor is medium risk — hard to leave but the vendor is not pushing on the lock. The high-risk profile is low-substitutability with a misaligned vendor: hard to leave, and the vendor has reason to make leaving more expensive. These deserve immediate attention.

Section 4: The Exit Plan As An Artifact

The third step of the audit is producing an exit plan for each high-risk dependency. An exit plan is not a hypothetical. It is a concrete sequence of steps you would take to replace the skill, with timelines, costs, and decision points. The plan exists not because you intend to execute it tomorrow, but because writing it down forces clarity about what the dependency actually entails.

The first element of the exit plan is the substitute identification. Who would you replace this skill with? If multiple candidates exist, which one is the leading candidate, and why? If no candidates exist, what would you build, and what would the build cost? The substitute identification is the part of the plan that requires market research and may involve preliminary conversations with alternative vendors. Doing this work in advance, when you are not under time pressure, produces better answers than doing it during a crisis.

The second element is the migration path. What sequence of steps moves your environment from the current skill to the substitute? At what points can you run them in parallel? What downstream consumers need to be notified or modified? What pacts need to be re-attested? The migration path translates the substitute identification into a concrete project plan, with phases that can be estimated.

The third element is the cost estimate. What is the all-in cost of executing the exit? Engineering time. Vendor onboarding fees. Lost productivity during transition. Risk of mistakes during cutover. Compliance recertification if applicable. The cost estimate is what makes the lock-in real to the operator's budgeting process — a dependency with a concrete exit cost is something the operator can reason about as a financial position, not an abstract risk.

The fourth element is the trigger conditions. Under what circumstances would you actually execute the exit? Specific price increases. Loss of feature parity. Vendor-side strategic shifts. Compliance changes. Documenting the trigger conditions in advance produces a decision rule that can be applied without needing to re-litigate the basics in the moment of the trigger. "If the vendor's price exceeds X, we initiate the exit" is a decision rule. "We will think about it when prices go up" is not.

The fifth element is the freshness window. How current does the exit plan need to stay? A plan written three years ago and never updated is not a plan; it is an aspirational document. The plan has to be re-checked on a regular cadence — quarterly is reasonable for high-risk dependencies, annually for medium-risk ones — and refreshed against the current state of substitutes, prices, and trajectories. The freshness commitment is part of the artifact.

The combined exit plan is a structured document, perhaps five to ten pages for a single dependency, that an operator can hand to an engineering lead and say "here is what we would do." The document does not have to be polished; it has to be specific. Specificity is what separates a plan from a wish.

Section 5: Building Optionality Into New Adoptions

The audit process described above is reactive. It surfaces lock-in that already exists. The complementary discipline is proactive: building optionality into every new skill adoption from the start, so that the audit's high-risk cell stays small.

The first practice is requiring two-vendor evaluation for new skill categories. When you adopt a new kind of skill — not a new instance of an existing kind, but a new capability area — the procurement process should evaluate at least two candidate skills, ideally from different authors. The reason is not to pick a winner; it is to discover, during evaluation, whether the substitute landscape has the characteristics you would want if you needed to switch. A category where the only candidate is a single-author single-source skill is a category where the new adoption is starting in the high-risk cell. That is sometimes acceptable, but it should be a conscious choice with a documented justification.

The second practice is preferring skills that operate against open interfaces. A skill that wraps a standard API — OAuth 2.0, an industry-standard data format, a published protocol — is more substitutable than a skill that wraps a proprietary interface, even if both work today. The standard interface gives you portability of the surrounding code; if you swap the skill, the interface stays the same. Skills that wrap proprietary interfaces give you portability of nothing. Preferring open interfaces during procurement is a small bias that pays off across the lifetime of the dependency.

The third practice is preferring skills that are open-source or have clear escrow provisions. An open-source skill, with an active community and a permissive license, is substitutable in the strongest sense — if the upstream becomes hostile, you fork. A commercial skill with no source visibility and no escrow is the opposite extreme — if the vendor disappears, you are on your own. Skills in between, with proprietary cores but documented interfaces and clear continuity provisions, are the practical middle ground for many cases.

The fourth practice is contractual lock-out clauses. For commercial skills, the procurement contract can include explicit terms that prevent or compensate for the worst lock-in scenarios: source escrow that triggers on vendor failure, price escalation caps, deprecation notice minimums, support continuity guarantees. These clauses do not prevent lock-in, but they bound it. A vendor who refuses any such clauses is a vendor whose retention strategy includes lock-in, and that is itself a procurement signal.

The fifth practice is regular optionality testing. Once a year, for each strategic dependency, actually attempt to use the substitute. Not in production. In a quarantine environment, with synthetic workloads, going through the motions of the migration. The point is not to migrate; the point is to verify that the substitute still exists, still works, and still produces compatible outputs. Substitutes that pass this test are real substitutes. Substitutes that fail it are theoretical substitutes that you have been counting on without confirmation.

The combined effect of these practices is that the proportion of high-risk dependencies in your registry stays bounded. New adoptions enter the registry in the lower-risk cells, and only move to higher-risk cells if the vendor landscape shifts. The audit's job becomes detecting those shifts, rather than discovering long-standing lock-ins for the first time.

Section 6: The Sandbox-Mode Dimension Of Lock-In

A particular flavor of capability lock-in worth calling out separately is sandbox-mode lock-in. Modern agent runtimes support multiple sandbox modes — process isolation, container isolation, microVM isolation — each with different cost, performance, and capability profiles. Skills authored against the assumptions of one sandbox mode may not work in another, even when the underlying capability is the same.

A skill that assumes process-mode isolation may rely on shared filesystem state with the agent's parent process. The same skill in a container-mode runtime may not have access to that state, because the container boundary is in the way. The skill technically works in both, but it works differently, and the workflow built around it depends on the process-mode behavior. Switching to a container-mode runtime — for security or scalability reasons — requires reauthoring the skill, modifying the surrounding workflow, or accepting degraded behavior.

This becomes a lock-in story when the runtime mode is itself a procurement choice. A runtime vendor who offers only one sandbox mode locks you into that mode for every skill you adopt. Switching runtimes — to a different vendor, a different deployment topology, a different security posture — requires redoing the sandbox-mode work for every affected skill. The lock-in is not in any one skill; it is in the runtime decision that constrains the skills.

The defense is to author skills against the most isolated sandbox assumptions you can — typically microVM-equivalent isolation — and treat lighter modes as performance optimizations rather than capability assumptions. A skill that works under microVM isolation will work under container isolation will work under process isolation, by construction. The reverse is not true. Authoring against the strict end of the spectrum produces skills that move between runtimes without rework.

This also affects the substitutability matrix. A skill that requires a specific sandbox mode is harder to substitute than a skill that runs in any mode, because the substitute has to meet the same sandbox constraint. Capability lock-in interacts with sandbox-mode lock-in in ways that compound the overall risk. A high-risk capability dependency in a runtime that itself has sandbox-mode lock-in is doubly stuck: the skill is hard to replace, and the runtime that hosts the skill is hard to migrate.

The procurement implication is to surface sandbox-mode requirements in the manifest review process. Skills should declare what sandbox modes they support, the runtime should refuse to load skills whose declared sandbox requirements exceed what the runtime provides, and the operator's risk register should include the sandbox-mode constraint as one of the substitutability dimensions. The discipline is small, and it preserves optionality on a layer of the stack that operators rarely think about until they need to move.

Section 7: Pact-Bound Lock-In And The Counterparty Layer

The most expensive form of capability lock-in is the kind that has propagated into the agent's pacts and the counterparties who subscribe to those pacts. A skill that produces outputs the counterparty has come to expect, through behavior the counterparty has built workflows around, has lock-in beyond the skill itself. Replacing the skill means producing equivalent outputs that the counterparty's workflows still accept, which constrains the substitute in ways that may not be obvious to the operator.

The mechanism is straightforward. The skill produces outputs. The agent's pact commits to specific qualities of those outputs — accuracy, format, latency, completeness. The counterparty consumes the outputs and builds expectations around them — sometimes explicit, sometimes implicit. Over time, the counterparty's workflows accumulate small dependencies on details of the skill's behavior that were not in the pact text but that the counterparty now relies on. When the substitute lands, those small dependencies may not be honored, and the counterparty experiences the substitution as a behavior change even though the pact text is unchanged.

This is the invisible layer of lock-in. It is not in the registry. It is not in the skill manifest. It is in the cumulative drift of expectations across the trust graph. The longer a dependency persists, the more this kind of accretion happens. By the time you want to substitute, the substitute has to satisfy not just the pact text but the lived experience of every counterparty who has adapted to the original.

The defense begins with pact precision. A pact that specifies, in detailed terms, what the agent commits to — including the parts of the skill output that are part of the commitment and the parts that are not — bounds what the counterparty can rationally rely on. A counterparty who relies on behavior outside the pact commitment is doing so at their own risk, and the operator can substitute the skill without violating the pact even if the counterparty's specific workflow breaks. Pact imprecision allows expectation drift; pact precision constrains it.

The defense continues with substitution rehearsal. When you adopt a substitute, run it in parallel with the original for a period long enough to detect counterparty-side workflow assumptions. Counterparties whose workflows degrade under the substitute will surface the issue, and you can decide whether to honor their assumption or to communicate the change. Either is acceptable; what is not acceptable is to discover the assumption only after the original has been turned off.

The defense culminates in counterparty notification. When you substitute a skill that affects pact-relevant behavior, communicate the substitution to subscribed counterparties with enough notice that their workflows can adapt. The trust oracle is the right channel — an entry in the agent's audit trail that is visible to counterparties who consult the relevant dimensions. The notification does not require apology; it requires clarity. Counterparties who want to participate in the new arrangement can; counterparties who do not can withdraw with notice.

This layer of the lock-in problem is what makes capability lock-in different from license lock-in or data lock-in. The cost of substitution is not bounded by your engineering team's capacity; it is bounded by the friction of moving the entire trust graph around the agent. The exit plan for a strategic dependency has to account for this. Plans that assume the substitute will be invisible to counterparties are plans that have not been tested against reality.

Section 8: When Lock-In Is Worth It

Not every lock-in is bad. Some dependencies are strategic for the right reasons — the vendor offers something genuinely unique, the relationship is mutually beneficial, the substitute would be inferior in ways that matter. The audit's purpose is not to eliminate all lock-in. It is to make the lock-in conscious, calibrated, and reversible at a known cost.

A dependency is worth keeping when the value the dependency delivers exceeds the strategic cost of the lock-in by a margin large enough to absorb foreseeable changes in vendor behavior. A skill whose unique capability is the actual differentiator of your agent's value proposition is reasonably depended on, even single-source, even from a misaligned vendor, as long as the cost of the lock-in is bounded and known. The decision to depend on it is a strategic bet, made with eyes open.

A dependency is worth keeping when the alternatives are genuinely inferior in measurable ways and the inferiority would degrade your own product. Switching to an inferior substitute to reduce lock-in risk is a decision that may produce a less-locked-in but lower-quality product, and that may be a worse outcome than the lock-in itself. The substitutability matrix gives you the comparison; the procurement decision gives the comparison weight.

A dependency is worth keeping when the cost of replacement is high but the trigger conditions for replacement are unlikely. A vendor whose trajectory is aligned, whose monetization is stable, and whose strategic ownership is unlikely to shift is a vendor whose lock-in is theoretical rather than practical. The trigger conditions exist but are improbable, and the operational cost of preparing for an improbable exit is not worth the benefit. The judgment is a probability-weighted comparison, not a binary.

The distinction matters because the audit can otherwise produce a paranoid posture where every lock-in is treated as urgent. The high-risk register should be small. Most dependencies should be in the medium-risk and low-risk cells, with documented but not aggressive exit plans. The high-risk cell should hold the dependencies where the trajectory has shifted or where the strategic value has eroded, and it should be the focus of the operator's procurement attention.

The corollary is that some dependencies should be deepened, not loosened. A vendor relationship that is delivering exceptional value, where the alignment of interests is strong, and where the substitute landscape would be much worse, may be worth investing in further: longer-term contracts that capture pricing, deeper integration that exploits the unique capability, joint roadmap conversations that align future work. Strategic dependencies are not always bad; they are decisions that should be made on purpose.

Section 9: The Reader's Artifact — The Skill Lock-In Risk Register

This is the deliverable. The Skill Lock-In Risk Register is a structured document — spreadsheet-equivalent — that lists every skill in your registry, evaluates it across the substitutability and trajectory dimensions, and assigns a risk classification with associated actions. The register is the operational artifact you maintain continuously and consult during procurement decisions.

The columns of the register, in order:

1. Skill identifier — name, version, signing identity. The unique key.
2. Author — the publisher of the skill, with a one-line note on author identity (independent vendor, large platform, open-source community, internal team).
3. Single-source classification — author single-source yes/no, capability single-source yes/no, upstream single-source yes/no. Three booleans that determine the lock-in cell.
4. Functional equivalence — high, medium, low. How available are functional substitutes?
5. Interface compatibility — high, medium, low. How drop-in are the substitutes?
6. Data lock-in — high, medium, low. How much state is non-portable?
7. Workflow integration depth — shallow, moderate, deep. How many downstream artifacts depend on the specific behavior?
8. Compliance constraints — none, moderate, strict. What recertification cost would substitution incur?
9. Vendor trajectory — aligned, neutral, misaligned. The trajectory assessment summary.
10. Composite risk classification — low, medium, high. The product of the previous columns.
11. Substitute candidate — the leading candidate replacement, or "none identified."
12. Exit plan — pointer to the structured exit plan document, or "not yet authored."
13. Trigger conditions — the specific events that would initiate the exit.
14. Last refresh date — when the register entry was last reviewed and updated.
15. Owner — the named operator responsible for monitoring the dependency and refreshing the entry.

The register is sorted by composite risk classification, with high-risk dependencies at the top. Each high-risk entry should have a complete exit plan. Each medium-risk entry should have at least a substitute candidate identified. Low-risk entries can be lighter, with the freshness commitment ensuring they are reviewed periodically.

The register is reviewed on a defined cadence: high-risk entries quarterly, medium-risk entries semi-annually, low-risk entries annually. Reviews update the substitutability assessment, refresh the substitute candidates, and re-evaluate the trajectory. Skills whose risk classification changes during a review are re-sorted, and the actions associated with the new classification kick in.

The register is consulted on every new skill adoption. Before adopting a new skill, the operator reviews the register entries for skills in the same capability area, evaluates whether the new skill increases or decreases concentration, and decides whether the adoption is consistent with the desired risk profile. This makes the register a living input to procurement decisions, not just a passive audit artifact.

The register is consulted on every vendor event — acquisitions, leadership changes, pricing announcements, deprecation notices. Events that affect the trajectory of a vendor trigger immediate review of all dependencies on that vendor. Events that affect the substitutability of a capability area trigger review of all dependencies in that area. The register is the connective tissue between vendor news and procurement action.

Section 10: A Counter-Argument Worth Taking Seriously

The principled objection to lock-in audit discipline is that it imposes substantial procurement overhead on every skill adoption in exchange for protection against scenarios that, in many cases, will never materialize. Most vendors do not turn hostile. Most acquisitions do not break customer relationships. Most strategic dependencies persist quietly for years without producing the crises that the audit is meant to prevent. The total cost of the audit, summed across an operator's portfolio, may exceed the realized cost of the lock-in incidents that ever actually happen.

This is partly true and depends on the operator's portfolio size and risk tolerance. For a small operator with a handful of skills and a low-stakes business, the audit overhead is real and the lock-in risk is bounded. The pragmatic answer in that case is a lighter-weight version of the audit — flag the obvious single-source dependencies, note them in a simple register, revisit annually. The full discipline scales with the stakes and the portfolio.

For an operator with dozens of skills, multiple agents, pacts that hold real economic commitments, and counterparties whose decisions depend on the agent's continuity, the audit overhead is small relative to the cost of being wrong. The asymmetry is what justifies the discipline: the cost of running the audit is bounded; the cost of discovering a lock-in during a vendor crisis is unbounded. Operators at scale should run the audit even if most of the dependencies turn out to be fine, because identifying the few that are not is the value.

A second objection is that the audit framework is itself a source of false precision. The substitutability matrix produces composite scores that look quantitative but are actually structured judgments. Operators who treat the scores as objective measurements may make procurement decisions based on numbers that are more confident than the underlying assessments warrant. The audit's outputs should inform, not replace, judgment.

This is correct and the answer is to use the audit as a checklist rather than a calculator. The substitutability matrix's value is that it forces you to consider each dimension, not that it produces a number. The risk register's value is that it surfaces dependencies for review, not that the classification is precise. Treating the framework as a structured prompt rather than a measurement instrument is the right posture.

A third objection is that exit plans, written in advance, age badly. The substitute landscape changes; vendor positions shift; new options emerge. A plan written today may be incorrect in eighteen months in ways that make it actively misleading. Documenting plans creates a false sense of preparedness that may be worse than no plan at all if the operator stops thinking about the dependency once the document exists.

The answer is the freshness commitment. Plans without freshness commitments do age badly. Plans with explicit refresh schedules — quarterly for high-risk, annually for medium-risk — stay current enough to be useful. The discipline is the schedule, not the document. An operator who maintains the schedule produces plans that are usable in a crisis. An operator who does not is in the same position as one without plans, and worse, may have false confidence.

What Armalo Does About This

Armalo's skill registry exposes per-skill metadata that supports the audit pattern: author identity, signing history, version trajectory, dependency manifest. The runtime tracks per-skill import history per agent, so the empirical question of which skills are actually depended on can be answered without estimation. The capability manifest format includes substitutability hints — declared interface compatibility with named alternative skills, declared upstream dependencies that downstream substitutability depends on — so the audit can be partially automated.

The trust oracle exposes vendor-trajectory signals for skills whose authors are themselves agents in the ecosystem: skill author scores, pact compliance histories, ownership change events. Operators consulting the trust oracle while building their lock-in register get a continuously-updated signal on the trajectory of every commercial skill author they depend on. The signal does not eliminate the need for judgment, but it grounds the judgment in observable evidence.

The pact format supports substitutability by allowing operators to commit to behaviors at the level of capability rather than at the level of specific skill. A pact that says "the agent will produce enriched contact records with the following properties" is substitutable across any skill that produces records with those properties. A pact that names a specific skill as the implementation is not. Steering pact language toward capability-level commitments is one of the small disciplines that compounds into substitutable architectures over time.

The Skill Lock-In Risk Register is supported as a first-class artifact in the operator's procurement workspace, with template entries, refresh reminders, and integration with the runtime's import history. The register is a tool, not a feature; the value is in the operator's commitment to maintain it. Armalo provides the infrastructure that makes maintenance feasible.

Frequently Asked Questions

How small does my skill portfolio need to be before this is overkill? For portfolios under ten skills with no commercial dependencies, a lightweight audit — single-source flag, substitutability note, vendor trajectory note — covers most of the value. The full framework scales with portfolio size and stakes.

What if the high-risk dependencies are also the most valuable? That is the common case, and it is exactly why the audit matters. High value plus high lock-in risk is a strategic position to manage consciously, not to deny. The exit plan does not commit you to leaving; it commits you to knowing what leaving would cost.

How do I evaluate vendor trajectory for an open-source skill? Open-source skills shift the trajectory questions to the maintainer community, the foundation or governance structure, and the contributor diversity. A single-maintainer open-source skill is closer to single-source than a multi-maintainer one. Diversity of contributors is a substitute for vendor durability.

Do exit plans need to be detailed for low-risk dependencies? No. Low-risk entries should have a substitute candidate identified and a one-line note on the migration path. Detailed plans are reserved for high-risk and selectively for medium-risk dependencies.

How does this interact with capability scoping? Capability scoping reduces the operational cost of the lock-in by reducing the breadth of authority the skill holds. It does not reduce the lock-in itself. A narrowly-scoped skill is still single-source if no substitute exists for its declared capability.

What about skills my agents do not currently use but my registry contains? Flag them as latent dependencies. Skills that are in the registry but not currently imported represent potential future dependencies; they should be in the audit but at lower priority than active ones. Pruning the registry of skills that no agent uses is itself a hygiene activity.

Should I publish my register? Not externally. The register reveals strategic dependencies that competitors could exploit. Internally, the register should be visible to anyone making procurement decisions, but external visibility creates risks it is not designed to handle.

Does this framework apply to internally-authored skills? Yes, with adjustments. An internally-authored skill is single-source by author, but the trajectory questions become questions about your own team's continuity rather than vendor behavior. The substitutability questions still apply, and the documentation of substitutes is still useful — internally-authored skills can still need replacement when the original author leaves the team.

Bottom Line

A single-source skill is a strategic dependency, regardless of how it got there. The audit pattern surfaces these dependencies before they become crises: identify single-source, evaluate substitutability across five dimensions, assess vendor trajectory, plan the exit. The Skill Lock-In Risk Register makes the audit operational and durable. Most dependencies turn out to be fine; the value is in identifying the few that do not. Operators who run the audit will not be the ones surprised by a vendor crisis. Operators who do not will be.