Abstract
The architecture of LLM-based agents has evolved through five distinct morphologies in four years: the prompt, the tool-calling agent, the agent loop, the harness with hooks and subagents, and finally the skill- and plugin-extended harness. Each stage solved the preceding stage's binding constraint and created the next one. We argue that the current stage has a constraint that is economic rather than architectural: every installed capability must purchase residency in a fixed context budget before it can influence behavior, and the ecosystem's distribution mechanisms (plugins, marketplaces, one-line installs) are compounding while the discovery budget is not. We formalize this as a solvency problem — the total description mass of installed capabilities exceeding the context quota allocated to discovery — and show that its failure modes (arbitrary capability loss, nondeterministic selection, follow-through decay, contradictory obligations, and unauditable execution) are already measurable at present scale and become dominant at the plugin densities projected within months. We show that the distinction between implicit and explicit invocation, widely assumed to mitigate the problem, does not: invocation mode gates triggering, not context residency. We further argue that foreseeable model-side advances — parameter-efficient task adapters, attention improvements, and longer context windows — do not close the gap, because the problem is one of allocation, verification, and portability rather than capacity. We then describe SkillSpec, an open-source contract layer that treats discovery as a compile-time problem and execution as a gated, evidenced walk: a static risk auditor, a typed behavioral contract co-resident with prose skills, a stateful CLI guide that serves one gate at a time in \(O(1)\) context, cryptographically fingerprinted decision traces with post-hoc alignment, and a compiled discovery layer (distilled descriptions, domain facades, tiered visibility, pull-based routing) whose context cost is bounded by the number of domains rather than the number of skills. We close with honest limitations: the contract is advisory rather than enforced, hookless discovery is probabilistic, and the central efficacy claim awaits controlled benchmarking.
1. Introduction
A SKILL.md file is a promising and fragile object. It is promising because it packages procedural knowledge — how to fill a PDF form, how to review a pull request, how to run a company's deploy checklist — into a portable folder that any compliant agent can discover and load [3, 4]. It is fragile because, the moment it activates, it is a prompt again, and it inherits every reliability pathology that prompts have: position-dependent attention [7], degradation with input length [8, 11], sensitivity to formatting [9], and instruction-following rates that decay predictably as obligations accumulate [10].
The ecosystem's answer to prompt fragility was structure at the packaging layer: progressive disclosure, frontmatter metadata, bundled scripts [3, 4]. The packaging succeeded — the Agent Skills format is now implemented by dozens of independent harnesses [4] — and its success created a new problem that packaging cannot solve. Skills are cheap to install and non-rival to distribute, so they accumulate. Each installed skill's name and description must occupy context at session start in order to be discoverable at all. The context allocated to this inventory is a small, fixed fraction of the window. Distribution compounds; the budget does not. The curves cross.
This paper does three things. First (§2–§5), it maps the evolution that produced the current agent stack, formalizes the shapes of its components, and derives a first-order cost model of discovery and follow-through that locates the crossing point — the regime we call context insolvency — and describes, concretely, what an ordinary machine with twenty plugins looks like after the crossing. Second (§6), it argues that this regime is robust to foreseeable model-side improvement: it is a systems problem that scaling laws route around rather than through. Third (§7–§9), it describes a working artifact — SkillSpec [18] — built on the position that the load-bearing parts of a skill should be moved out of prose into a typed, testable, traceable contract, and that discovery should be compiled rather than hoped for. Throughout, we distinguish measured claims from design claims, and we state plainly where the artifact's central hypothesis remains unproven.
2. The Morphology of the Agent Stack
2.1 Five stages, each solving the last one's constraint
Stage 1: The prompt. A single context window, a single completion. The binding constraint is statelessness: nothing persists, nothing acts.
Stage 2: The tool-calling agent. ReAct-style interleaving of reasoning and action [1] gave the model hands: emit a structured action, observe the result, continue. The constraint becomes orchestration — one reasoning thread, ad-hoc control flow, no lifecycle.
Stage 3: The agent loop. The loop formalizes stage 2 into a runtime: a conversation state, a tool registry, permission checks, retry semantics. The constraint becomes extensibility and safety: how does the loop acquire new capabilities, and how does its operator constrain them?
Stage 4: The harness. The loop grows an ecosystem around itself: lifecycle hooks (pre-prompt, pre-tool-use, post-tool-use, session start) that let deterministic code intercept the probabilistic core; subagents that fan work out to isolated contexts; configuration layers; permission modes. The harness is the point where the agent stops being a program and becomes a platform. Its constraint: capabilities are still bespoke — every team re-teaches every agent the same procedures in prose.
Stage 5: Skills and plugins. The Agent Skills format [3, 4] answers stage 4's constraint with portable procedural knowledge: a folder with a SKILL.md, loaded by progressive disclosure. Plugins bundle skills, commands, and agents into distributable units with marketplaces and one-line installs. The constraint this stage creates — the subject of this paper — is that every installed capability competes for a fixed discovery budget, and nothing in the format governs what happens when the competition is oversubscribed.
Each transition has the same signature: the previous stage's content problem becomes the next stage's coordination problem. Skills solved "how do I tell the agent how we do things here." They did not solve "which of the eight hundred things it has been told applies now, and did it actually follow the one that applied."
2.2 The shape of a loop with hooks
An agent loop with hooks can be written as a tuple
where \(M\) is the model, \(C\) the context assembly function, \(T\) the tool registry, and the \(H\) are deterministic hook sets that may inject context, block actions, or transform results. One turn is:
The decomposition matters for one reason: hooks are the only deterministic surface in the loop. Everything the model does is probabilistic; everything a hook does is code. Any reliability property one wants to guarantee — rather than encourage — must live in \(H\), in \(T\)'s permission layer, or outside the loop entirely. This observation recurs in §7 and §9.
Note the term \(\text{inv}\) in the context assembly: the inventory — the list of installed capabilities (skill names and descriptions, tool schemas) that the model must see to know what it can do. The inventory is paid on every turn of every session, whether or not any capability is used. It is the rent line in the context budget, and it is where insolvency begins.
2.3 The shape of a skill
A skill under the open format [4] is a staged object:
with name \(n\) and description \(d\) loaded for every installed skill at session start; body \(B\) loaded on activation; and references/scripts \(R\) loaded only when execution reaches them. Progressive disclosure is genuinely sound information architecture — the design intent is that a large library is carried at small context cost because only \((n,d)\) is always resident [3, 4].
Two properties of this shape are load-bearing for what follows. First, \((n, d)\) is simultaneously the index entry, the routing function, and the advertisement — one prose string doing three jobs, written by parties with varying skill and varying incentives [14]. Second, once \(B\) is in context it is guidance, not contract: the model may follow it fully, partially, out of order, or not at all, and the format provides no mechanism to detect which occurred.
2.4 The shape of a plugin
A plugin is a distribution morphism, not a discovery unit:
Installing \(P\) inserts all of its skills' \((n_i, d_i)\) pairs into the inventory in one action. The unit of user intent ("I want the Acme suite") and the unit of context cost (\(k\) description entries, forever) are mismatched by a factor of \(k\). Marketplaces make acquiring \(P\) a one-line operation. Nothing in the current stack makes the resulting inventory obligation visible, priced, or reversible with equal ease. This asymmetry — frictionless acquisition, invisible recurring cost — is the mechanism by which insolvency arrives not through any single bad decision but through the accumulation of individually reasonable ones.
3. A Cost Model of Discovery and Follow-Through
We now make the constraint quantitative. The model below is deliberately first-order — its purpose is to locate regimes and crossings, not to fit curves.
3.1 The discovery budget
Let \(C\) be the context window and \(\varepsilon\) the fraction a harness allocates to the skill inventory. Harness implementations bound this region through per-description character caps and total-budget truncation; a working value consistent with observed behavior is \(\varepsilon \approx 0.02\). The discovery budget is
With \(N\) installed skills of mean description length \(\bar{d}\) tokens, the inventory demands \(T_{\text{inv}} = N\bar{d}\). Define the visibility fraction
Measured description lengths in the wild run \(\bar{d} \approx 100\text{–}250\) tokens (skill authors write descriptions as advertisements and trigger nets, not index entries; we measured managed skills at the top of that range in a live harness). At \(\bar{d} = 120\):
| \(N\) (skills) | \(T_{\text{inv}}\) (tokens) | \(\varphi(N)\) | Regime |
|---|---|---|---|
| 25 | 3,000 | 1.00 | solvent |
| 33 | 4,000 | 1.00 | at the boundary |
| 100 | 12,000 | 0.33 | insolvent |
| 800 | 96,000 | 0.04 | deeply insolvent |
Beyond the boundary, the harness must truncate descriptions, cap the list, or drop skills — and the drop criterion available to it (load order, registration sequence, alphabetization) is uncorrelated with relevance, quality, or usage. "Installed" and "available" become unrelated properties, and no signal reports the divergence.
Note that \(\bar{d} \approx 25\) tokens — achievable by deliberate compression — moves the boundary to \(N \approx 160\). Description mass, not skill count, is the first-order variable. This observation grounds the distillation primitive of §8.
3.2 Selection degrades before the budget is exhausted
Even inside the solvent regime, selection is a retrieval task over \(N\) prose distractors embedded mid-context — the region where models attend worst [7], at input lengths where performance is already declining on far simpler tasks [8, 11]. The most direct external evidence comes from the adjacent tool-selection setting: as registries scale to thousands of entries, baseline selection accuracy collapses (13.6% in one MCP-scale benchmark), while offloading selection to an external retrieval index more than triples it and halves prompt tokens [12]. The mechanism is identical for skills: a flat prose inventory is the wrong data structure for a growing capability corpus, independent of model quality. Formatting sensitivity compounds the problem: near-meaning-preserving differences in how descriptions are phrased shift selection behavior by large margins [9], which means selection at scale is not merely inaccurate but unstable across sessions.
3.3 Follow-through decay after activation
Activation loads a body \(B\) carrying \(m\) obligations (steps, forbids, gates). If obligation \(i\) is independently followed with probability \(p_i\), the probability of full follow-through is
exponentially decaying in obligation count even for high \(\bar{p}\). This is not hypothetical: controlled measurement at increasing instruction densities finds even frontier models at 68% adherence by 500 concurrent instructions, with earlier-instruction bias and three characteristic decay shapes (threshold, linear, exponential) across model families [10]. Position effects give the per-obligation probability structure: \(p_i\) is a decreasing function of the obligation's depth into a long body [7]. The practical corollary practitioners recognize immediately: the "never do X" on line 400 is precisely the instruction most likely to be skipped, and each miss, patched with another paragraph, increases \(m\) and lowers \(P_{\text{follow}}\) for the next run — a structural ratchet.
3.4 Compaction as a lossy channel
Long sessions compact. Compaction is a lossy summarization channel: skill bodies, mid-session decisions, and partially-completed step state are compressed by a mechanism that does not know which sentence was load-bearing. Harnesses mitigate by re-attaching recent skill content within a bounded budget, but re-attachment competes across all active skills and restores text, not execution state — which step was completed, which check passed, which forbid is in force. Any reliability architecture that keeps run state only in the window is betting against the channel. (§7.4 returns to this with state that lives outside the window by construction.)
3.5 The follow-through budget
Summing: a task's reliability under the current stack is bounded by the product of a selection term, a follow-through term, and a compaction-survival term,
with the three factors respectively decreasing in library size, obligation count, and session length. All three trends are empirically documented [7, 8, 10, 11, 12]. Nothing in the current format arrests any of the three; and — the governance point — the operator controls none of the three at request time. You ask; what is invoked is a function of description prose you did not write, competing entries you did not audit, and position effects you cannot see. The descriptions may be duplicative (twenty plugins ship four PDF skills), contradictory (one mandates a tool another forbids), or complementary — and the stack treats all three cases identically.
4. Invocation Semantics: The Residency–Trigger Distinction
A widely-held intuition says explicit invocation solves the budget problem: mark skills user-invocable-only, and they stop consuming resources until called. The intuition confuses two different gates.
Definition. A skill's invocation mode determines who may trigger activation (the model, on description match; or the user, by explicit command). A skill's context residency determines whether its \((n, d)\) occupies the inventory.
Observation (mode gates trigger, not residency). In current harness implementations, skills flipped to explicit-only remain listed in the inventory with full descriptions — the harness must render the catalog so that slash-commands can be dispatched and recognized. We verified this directly in a live session: skills set to user-invocable-only through native visibility overrides continued to occupy the model-visible inventory at full description length. The quota is charged per listed skill, regardless of mode.
Two corollaries follow. First, explicit invocation does not restore solvency; it changes who pulls the trigger while the rent is paid either way. Second, the description of an explicit-only skill is almost pure waste: descriptions exist to inform selection, and an explicit-only skill has opted out of selection — the model needs only \(n \to\) dispatch. The economically correct listing for a manual-only skill is name-only, a state the format can express conceptually but current harnesses do not natively honor. Until they do, the only levers that actually reclaim budget are fewer entries and shorter entries — which is why §8 treats discovery as a compilation target rather than a visibility flag.
There is also a human ceiling: explicit invocation presumes the user remembers what is installed. No operator recalls eight hundred slash-commands; the help surface becomes a phone book. Explicitness relocates the discovery problem from the model to the person without shrinking it.
5. The Accumulation Regime: A Crystal-Ball Extrapolation
Consider a machine — months away, not years, at current plugin-marketplace growth — with 20 installed plugins averaging 40 skills each: \(N = 800\).
The arithmetic. At \(\bar{d} = 120\): \(T_{\text{inv}} = 96{,}000\) tokens against \(Q = 4{,}000\) — 24× oversubscribed, \(\varphi = 0.04\). The model can see perhaps 3–5% of installed capability, the surviving subset chosen by mechanisms uncorrelated with value. This is not degraded discovery; it is arbitrary discovery, silently applied.
Selection instability. Twenty vendors guarantee semantic pile-ups — every serious plugin ships its own "review," "deploy," "pdf," "test." If a fraction \(p_{\text{dup}}\) of skill pairs have materially overlapping trigger surfaces, expected collisions scale as \(\binom{N}{2} p_{\text{dup}} \approx \tfrac{N^2}{2} p_{\text{dup}}\) — quadratic in library size. Selection among near-duplicates inherits the formatting instability of §3.2: same prompt, different skill on different days [9, 12].
Composition becomes the attack surface. Beyond individual skill quality, 2026 measurements show that skills benign in isolation become harmful in composition — outputs, trust signals, and authorization cues from one skill steering later invocations — with composed-path attack success rates of 33.6% against near-zero for isolated evaluation [17]. Semantic supply-chain attacks target exactly the metadata layer that drives selection [14]. Eight hundred prose instruction files from twenty vendors, none of which passed any acceptance gate, co-resident in one machine's trust domain [6, 14, 17].
Contradiction without adjudication. Skill A mandates qpdf; skill B forbids it. When both bodies are active, behavior is undefined and unreproducible. The format has no notion of conflicting obligations, so the conflict is discovered — if ever — as a mysterious intermittent failure.
Skill debt without garbage collection. No record exists of which skills fired, which were dead weight, which failed silently. Curation is manual guesswork over an inventory too large to audit by hand. The realistic operator response — already observable — is wholesale plugin disabling and retreat to a hand-tended working set of ~15 skills, at which point the ecosystem's growth has destroyed the ecosystem's value: every additional installed plugin lowers the probability that any given capability is seen, selected, and followed.
The endgame of the current trajectory is not a crash. It is quieter: an inventory of eight hundred capabilities, five percent visible, selected nondeterministically, followed partially, verified never.
6. Why Model-Scale Remedies Do Not Close the Gap
It is tempting to file all of this under "wait for better models." We consider the three standard candidates and argue each addresses capacity when the binding constraints are allocation, verification, and portability.
Task-adapted parameters (LoRA-class adapters [2], skill-specific fine-tunes). Adapters internalize procedures into weights, removing them from context. But (i) the skill corpus is heterogeneous, versioned, org-specific, and changes weekly — retraining cadence cannot track a registry; (ii) internalized behavior is less auditable than prose, not more: there is no artifact to review, no diff between versions, no way to attest which procedure ran; (iii) adapters bind capability to a specific model, destroying exactly the cross-harness, cross-model portability that made the skill format succeed [4]. Adapters are a caching layer for stable, verified procedures — which presupposes the contract-and-evidence layer this paper argues for, rather than replacing it.
Better attention / mitigated position effects. Suppose lost-in-the-middle [7] were fully solved. Selection over \(N\) near-duplicate prose descriptions remains a retrieval problem whose difficulty grows with \(N\) and with distractor similarity — and \(N\) grows without bound while the inventory remains a flat list. The tool-selection evidence is instructive: the fix that worked was not a better model but a better data structure — an external index queried at need [12]. Attention improvements raise the constants; they do not change the asymptotics of flat-list discovery.
Longer context windows. Two failures. Empirically, usable context lags advertised context and degrades with length on even trivial tasks [8, 11], so a 10× window does not deliver 10× reliable inventory. Economically, capability supply is elastic: any budget increase is absorbed by ecosystem growth (the induced-demand dynamic familiar from road capacity). \(\varepsilon C\) rising from 4k to 40k tokens moves the insolvency boundary from ~33 skills to ~330 at current description mass — a regime the 800-skill machine has already passed, with marketplaces still accelerating. A widening window changes when the curves cross, not whether.
And none of the three touches the verification gap. A model that selects perfectly and follows perfectly still leaves no record — no artifact by which an operator, an auditor, or the next model version can confirm which route ran, which forbid held, which check passed. Recent security work names this precisely: the audit–runtime gap, the absence of binding between what a skill was reviewed to be and what executed [16]. Capacity does not produce evidence. Evidence requires machinery outside the model.
7. SkillSpec: A Contract Layer Between Prose and Execution
7.1 Origin, honestly stated
SkillSpec [18] did not begin as a grand design. It began as dogfood irritation: good skills kept becoming long Markdown files with buried decisions, and their agents kept skipping the late safety rule, grabbing an undeclared tool, and reporting "done" with no proof. The project's own reliability-gap analysis concluded that every mitigation the field had converged on — shorter bodies, numbered steps, dependency fields, invocation toggles — moved load-bearing logic in the same direction: off the natural-language layer, toward something a machine can check [15 provides the corpus-level motivation: curated procedural structure lifts agent task pass rates from 33.9% to 50.5%, but only when the structure is actually followed]. SkillSpec is a bet on completing that motion as a layer rather than as point fixes: keep the prose for judgment and tone; move routing, prohibition, dependency, and completion semantics into a typed contract that validators, compilers, tests, and traces share. The instructive embarrassment: the project's own SKILL.md grew to 5,885 tokens and 40 modal obligations and scored critical on its own drift auditor — the disease reproducing inside the treatment — which forced the guided-trampoline architecture of §7.4. We report this because it is evidence for the thesis: prose accretes obligations by default, even when its authors are professionally paranoid about exactly that failure mode.
7.2 The measurement primitive: a static risk auditor
skillspec doctor inspects any skill folder or public repository URL and emits an agent follow-through risk score: a transparent penalty model over measured structural signals — activation body size and its share of loaded text, modal-obligation count and position (obligations past the 60% mark are penalized per §3.3's position term), unlabeled operational prose, undeclared dependencies inferred from command blocks, missing behavior contract, missing test/trace surface, and frontmatter discovery risk (description length, genericity, truncation exposure). Every penalty cites either published measurement [7, 8, 10, 13, 14] or a named local methodology, and the report separates what is measured from what is a policy threshold. The auditor is deliberately standalone — no adoption of the rest of the system required — because measurement is the honest first move: it converts "prose skills feel unreliable" into per-skill, per-finding, remediable evidence.
7.3 The contract primitive: skill.spec.yml
Beside the prose SKILL.md sits a typed contract declaring:
- routes — named strategies with ranked applicability and optional phased execution plans;
- rules — predicates over the task that select routes, and crucially carry forbids with narrow allows: "prefer the browser route; forbid native-search-as-answer; allow native search for URL discovery only." Negative steering with scoped exceptions is the semantic that prose cannot carry reliably and that drift exploits;
- dependencies — CLIs, packages, services, credentials, with provisioning options and permission gates, checkable before execution rather than discoverable mid-task;
- tool boundaries — per-phase allow/forbid/permission-required lists over tools, substrates, and data sources;
- scenario tests — assertions that given inputs select given routes, add given forbids, request given elicitations: the contract is regression-testable steering;
- trace requirements — which decision events must be recorded.
The contract is a real specification: a typed model, a JSON Schema, a reference grammar, and a conformance suite of valid/invalid fixtures [18]. An importer mechanically drafts contracts from existing prose skills, quarantining low-confidence inferences as review_required rather than flattening ambiguity into fake confidence.
7.4 The execution primitive: a guided trampoline in \(O(1)\) context
The runtime inverts the skill-loading economics. The installed SKILL.md shrinks to a boot pointer (~500 tokens): start or resume the CLI guide. The guide (run-loop --guide agent) loads the spec, selects the route, opens a run directory, and serves exactly one gate at a time: current phase, open requirements, do-now, do-not, allowed commands, and when-to-advance. The gate is derived from ledger state, not scripted — a phase remains current until requirement_satisfied / phase_completed events land in an append-only execution ledger, so checkpoints cannot be skipped by momentum, only explicitly failed or blocked.
The context accounting is the point. Under prose skills, per-task instruction cost is \(O(|B|)\) — the whole body, with \(P_{\text{follow}}\) decaying in its obligation count (§3.3). Under the guide it is
where \(G\) is the number of phases and \(|g| \approx\) a few hundred tokens: each gate arrives freshest in context, at the position models attend to best [7], carrying only the obligations active now — directly attacking the \(\bar{p}^m\) decay by keeping effective \(m\) per decision small. Compaction resilience follows from the same move: run state (guide-state.json, the ledger, a compact human summary) lives on disk, not in the window; resume recovers the task from the trace and revalidates it against a three-level fingerprint ladder — input hash, spec fingerprint, and a decision fingerprint over only the active contract (selected route, phase order, requirements, forbids) — so an irrelevant spec edit warns while a contract-changing edit forces replanning. The model's memory is never the system of record.
7.5 The evidence primitive: traces and alignment
Every guided run leaves a decision trace (hashed, append-only, spec-fingerprinted) and an execution ledger of typed proof events. trace align replays the decision against the current spec and evaluates the derived obligations against recorded evidence, yielding pass, fail, or — deliberately — unproven: absence of evidence is reported as absence, never inferred as success, and the runtime explicitly prohibits manufacturing proof rows after the fact. We state the honest boundary plainly, because the field's credibility depends on it: this is post-hoc verification, not runtime enforcement. The agent cooperates voluntarily; a violation is made visible, not impossible. Enforcement of tool boundaries belongs to the harness (§2.2's deterministic surface), and §9 describes the planned compilation of contract boundaries into harness pre-tool-use hooks — the mechanism by which the audit–runtime gap [16] narrows from "reviewed then hoped" to "reviewed then gated," without ever claiming the CLI is a security sandbox.
8. Compiling Discovery: Restoring Solvency
The router problem of §3–§5 admits a reframe that changes its complexity class: the installed skill set changes on install/update; the task changes per turn. Discovery is therefore a compile-time problem, and per-prompt routing machinery is dynamic overhead applied to static structure. SkillSpec's discovery layer compiles the inventory into tiers, using only native format mechanisms — no persistent prompt hook required.
Tier 0 — distillation. Each skill receives a description budget \(Q / (|H| + K)\) and the compiler emits a trigger-dense entry from material the index already extracts (activation keywords, tags, route labels), deduplicating cross-skill boilerplate. Since the boundary scales as \(Q / \bar{d}\), cutting \(\bar{d}\) from 120 to 25 tokens quintuples solvent capacity before any structural change. The static auditor enforces the budget as a workspace check.
Tier 1 — domain facades. When distilled inventory still exceeds \(Q\), shard the trigger surface: cluster the index into \(K\) capability-domain gateways (documents, review, browser-automation — pointedly not per-vendor), each an ordinary implicit skill whose ~30-token description covers its cluster and whose generated body is a compact catalog of members with load instructions. Members flip to manual-only. Discovery cost becomes
bounded by the number of domains, which saturates, rather than the number of skills, which does not. For the §5 machine: ~12 hot skills (350 tokens) + ~20 facades (600 tokens) ≈ 1,000 tokens carrying 800 skills — 1% of the naive inventory cost, inside a 4k budget with headroom, at the price of one extra load hop paid only when a warm skill is actually needed. This is the RAG-MCP result [12] applied one layer up, and it is progressive disclosure [3] applied to discovery itself.
Tier 2 — pull routing. The cold tail lives in a local SQLite index (BM25 over names, triggers, activation keywords, with duplicate-install collapse to logical identity). Facade bodies carry the instruction to query it when the task's domain is not covered — routing round-trips are paid on suspected matches, not on every prompt. Where an operator wants deterministic first-hop routing, an opt-in hook mode performs the route inside the prompt hook (which already receives the prompt text) with banded emission — a directive when confident, a two-line candidate hint when ambiguous (the main model, already reading the prompt, is the cheapest competent semantic reranker), and silence on bypass, so the common case costs zero tokens and zero round-trips.
The closed loop. Run traces and ledgers record which skills actually fire per project; tier assignment becomes cache policy with real eviction data — used recently → hot; discovery-miss (a task matched a skill that never loaded, detectable from alignment) → promote; unfired in \(N\) days → cold, surfaced in a dead-weight report. Skill debt [§5] acquires a garbage collector. Around the whole pipeline sits an admission gate: doctor risk report, budget-fit check, collision detection, and (planned) cross-contract conflict lint at plugin install time — converting §5's silent arbitrary capability loss into explicit, reviewable admission decisions.
Honest tradeoff: hookless discovery is probabilistic — it depends on the model noticing a facade — where the mandatory first hop was deterministic. The mitigations are that facade descriptions are precisely the artifact the auditor optimizes, and that discovery misses are measured (the ledger sees them) rather than silent. Determinism remains available as policy; it is no longer the architecture.
9. Beyond the Loop: Utility Agnostic of Harness and Model
The design center of everything in §7–§8 is a single principle: keep the system of record outside the model and outside any particular harness. Concretely:
- State on disk, not in the window. Run directories, ledgers, guide state, fingerprints. Sessions crash, compact, and migrate; the contract walk resumes from disk under any model, including a different model mid-task — the resume validates fingerprints, not vibes. Model switches become a non-event by construction.
- One contract, many targets. The spec compiles to thin loaders per harness (Claude Code, Codex, generic Markdown) with identical semantics; the conformance suite, not any harness's behavior, defines the format. When a harness adds native support for a control (name-only listing, invocation gating), the compiler emits it; where support is missing, the loader emulates. The contract outlives harness churn the way OpenAPI outlived HTTP client churn.
- Determinism migrates to hooks. Per §2.2, guarantees live in the deterministic surface. The planned enforcement path compiles a run's active tool boundary into scoped, run-lifetime harness pre-tool-use hooks — forbidden substrates fail at the harness, not on the honor system — installed at run start, removed at run end, never resident globally. This narrows the audit–runtime gap [16] with local mechanisms and no new trust infrastructure, while the trace remains the audit artifact.
- Vendor-neutral by boundary. The router answers only "which local skill, if any"; execution-substrate policy belongs to the selected skill's own contract. A project adopts the discovery and evidence layers without inheriting anyone's runtime.
- The human channel is part of the contract. Gates carry not only do-now but a user-register status line, and completion reporting is a contract surface (result, evidence paths, alignment status, token economics) — because a system whose proof is unreadable gets its proof ignored.
The through-line: models will keep changing, harnesses will keep absorbing features, and context windows will keep growing. A contract-and-evidence layer that lives in files, compiles to whatever the harness natively honors, and measures its own efficacy is the part of the stack designed to still be true after each of those shifts.
10. Limitations and Open Problems
We state these without hedging, because the field's pattern of over-claiming is itself one of the failure modes this paper catalogs.
- Advisory, not enforced (yet). The contract constrains a cooperative agent and evidences an uncooperative one. Until boundary-to-hook compilation ships, a model can ignore every forbid and the system can only report it afterward. The honest description is "auditable," not "guaranteed."
- The efficacy claim is unbenchmarked. The central hypothesis — spec-backed skills route better, drift less, and cost fewer tokens than prose skills on identical tasks — rests on dogfood evidence and the cited external measurements, not on controlled side-by-side runs. SkillsBench-style task suites [15] make this measurable; publishing the misses matters more than publishing the wins, because the misses locate where the grammar is vague.
- Probabilistic hookless discovery. Facade-mediated discovery can miss; the measured discovery-miss rate is the architecture's health metric and its honest report card.
- Contract-authoring cost. A ~100-type spec grammar risks recreating, at the schema layer, the very density problem it solves at the prose layer. The core steering subset (routes, rules, forbids, dependencies, tests, traces) must stay learnable in an afternoon; everything else belongs behind profiles.
- The evidence channel trusts the reporter. Ledger events are written by the same agent being audited; the runtime forbids retroactive proof manufacture, but detection of fabricated contemporaneous evidence requires the hook-level attestation of §9 or external binding of the SIGIL variety [16].
- Platform absorption. Harness vendors may natively absorb routing, budgets, and enforcement. The durable positions are the portable contract, the conformance authority, and the audit trail — the runtime loop is the layer most exposed.
- Composition semantics are open. Cross-skill contract conflicts (§5) are detectable in principle by workspace lint; merge semantics for composed specs (inheritance, includes, safety-weakening review gates) are designed but unimplemented — and composition is where the 2026 attack literature points [17].
11. Related Work
Format and platform. The Agent Skills format and its progressive-disclosure model [3, 4]; harness-level skill management, invocation control, and command unification [5]. SkillSpec builds on the format rather than replacing it: the contract co-resides with SKILL.md.
Degradation measurement. Position effects [7]; effective-versus-advertised context [8]; length-dependent degradation across 18 frontier models [11]; formatting sensitivity [9]; instruction-density decay with primacy bias [10]. These jointly supply the empirical basis for §3's cost model.
Selection at scale. Retrieval-offloaded tool selection against prompt bloat [12] is the closest structural precedent for §8's compiled discovery; package-management approaches to skill distribution with format validation [13] address the registry layer.
Skill ecosystems and security. Benchmarking skill efficacy at corpus scale [15]; semantic supply-chain attacks on skill metadata [14]; compositional risk in skill ecosystems [17]; cryptographic binding of audited skills to runtime [16]; prompt-injection taxonomy and mitigations [6]. SkillSpec's admission gate, provenance marks, and trace/alignment machinery are complementary local mechanisms to [16]'s registry-level binding.
Model-side adaptation. Parameter-efficient task adaptation [2] as the internalization endpoint for stabilized procedures — downstream of, not a substitute for, contract verification (§6).
12. Conclusion
The agent stack evolved by moving each era's chaos into the next era's structure: prompts into loops, loops into harnesses, bespoke instructions into portable skills. Each move succeeded, and each success shifted the binding constraint upward. The current constraint is a budget: capabilities multiply freely while the context that makes them discoverable, selectable, and followable does not. Left alone, the arithmetic ends in context insolvency — installed capability that is invisible, selection that is arbitrary, follow-through that decays exponentially in obligations, and execution that leaves no evidence. Model-side progress relocates the boundary; it does not remove it, because allocation, verification, and portability are not capacity problems.
The response this paper describes is unglamorous by design: measure the risk statically, move the load-bearing decisions into a typed contract, walk execution one evidenced gate at a time with state on disk, verify alignment after the fact and say unproven when it is unproven, and compile discovery so its cost is bounded by the number of domains rather than the number of skills. None of this requires a new runtime, a new model, or anyone's permission. It requires treating skills the way the last four decades taught us to treat every other artifact that mattered: with contracts, tests, budgets, and audit trails — because "hope" was never a plan, and at eight hundred skills it stops even being a pretense.
References
[1] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, Y. Cao. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. https://arxiv.org/abs/2210.03629
[2] E. J. Hu, Y. Shen, P. Wallis, Z. Allen-Zhu, Y. Li, S. Wang, L. Wang, W. Chen. LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022. https://arxiv.org/abs/2106.09685
[3] Anthropic. Equipping agents for the real world with Agent Skills. Engineering blog, October 16, 2025. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
[4] Agent Skills: an open format for extending AI agents. Specification and adopter registry. https://agentskills.io/
[5] Anthropic. Extend Claude with skills. Claude Code documentation. https://code.claude.com/docs/en/skills
[6] OWASP GenAI Security Project. LLM01:2025 Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
[7] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, P. Liang. Lost in the Middle: How Language Models Use Long Contexts. TACL 2024. https://arxiv.org/abs/2307.03172
[8] C.-P. Hsieh, S. Sun, S. Kriman, S. Acharya, D. Rekesh, F. Jia, Y. Zhang, B. Ginsburg. RULER: What's the Real Context Size of Your Long-Context Language Models? COLM 2024. https://arxiv.org/abs/2404.06654
[9] M. Sclar, Y. Choi, Y. Tsvetkov, A. Suhr. Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design. ICLR 2024. https://arxiv.org/abs/2310.11324
[10] D. Jaroslawicz et al. How Many Instructions Can LLMs Follow at Once? 2025. https://arxiv.org/abs/2507.11538
[11] Chroma. Context Rot: How Increasing Input Tokens Impacts LLM Performance. Technical report, July 14, 2025. https://www.trychroma.com/research/context-rot
[12] T. Gan et al. RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. 2025. https://arxiv.org/abs/2505.03275
[13] S. Saha, P. Hemanth. Skilldex: A Package Manager and Registry for Agent Skill Packages with Hierarchical Scope-Based Distribution. 2026. https://arxiv.org/abs/2604.16911
[14] S. Saha, K. Faghih, S. Feizi. Under the Hood of SKILL.md: Semantic Supply-chain Attacks on AI Agent Skill Registry. 2026. https://arxiv.org/abs/2605.11418
[15] X. Li et al. SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks. 2026. https://arxiv.org/abs/2602.12670
[16] T. Shen, Y. Feng, K. Zhu, X. Jia, Y. Liu, L. Zhang. Sealing the Audit-Runtime Gap for LLM Skills. 2026. https://arxiv.org/abs/2605.05274
[17] Y. Xie, J. Du, Y. Cheng, J. Zhou, Z. Yin. Benign in Isolation, Harmful in Composition: Security Risks in Agent Skill Ecosystems. 2026. https://arxiv.org/abs/2606.15242
[18] Modiqo. SkillSpec: skills that agents can actually follow. Open-source (MIT/Apache-2.0). https://github.com/modiqo/skillspec · https://skillspec.sh/
All URLs verified live as of July 2, 2026. Formulas render under MathJax ($…$ inline, $$…$$ display).