Connect Each Skill to Cost and Business Value
A skill library is not valuable because it contains many capabilities. It is valuable when those capabilities reliably improve an outcome at a cost the business can justify.
- Cost per invocation
- Cost per successful outcome
- Model choice by skill
- Caching and reusable artefacts
- Human time saved
- Revenue, conversion, quality, and risk metrics
The situation
Skill architectures make it easy to add capabilities. That can create a new form of feature creep: every team wants an agent skill, each one triggers model calls and tools, and aggregate cost grows without anyone knowing which capabilities are actually useful.
The naive solution
Measure total AI spend and try to make every skill cheaper by choosing a smaller model or reducing tokens.
The hidden constraint
The cheapest skill is not necessarily the best business skill. A high-cost capability may be excellent if it produces a valuable result, while a tiny low-cost skill may create huge aggregate spend at high volume without changing any outcome. Skills also differ in reasoning difficulty, so one global model choice is rarely optimal.
The decision
Measure economics per skill and per successful outcome. Model routing, context size, tool usage, caching, and human review should be optimised against value rather than token count alone.
The implementation
I would attribute model and tool costs to skill invocations and connect those records to workflow outcomes where possible. Some skills may justify a stronger model because errors are expensive. Others can use a smaller model or deterministic code. Frequently reused research or account summaries may be cached with clear freshness rules. I also measure human intervention because a cheaper skill that requires twice as much correction may not be cheaper operationally.
The tradeoff
Business value is harder to measure than API spend. I still prefer an explicit value proxy to cost optimisation with no outcome metric. Even directional measures such as minutes saved, escalation avoided, qualified leads produced, or successful tasks completed are more useful than raw token totals.
The evidence I would look for
I would expect the team to know which skills are expensive, which are valuable, which are both, and which are simply noisy. Cost changes should be explainable by invocation volume, model mix, context growth, retries, or tool usage rather than surprise provider invoices.
The reusable lesson
Treat a skill as a unit of economics as well as a unit of architecture.
The consultant's questions
- What does one successful invocation of this skill cost?
- What business metric should improve when this skill is used?
- Is the model choice appropriate to the consequence of being wrong?
- Which repeated outputs could be cached or reused safely?