The Ark Pattern
Skills drift.
You write a capability, it works, you ship it. Six months later the same nominal skill produces a different answer — because the runtime moved, or someone edited a copy, or a dependency shifted underneath it, or four teams each forked it and none of them told the others. The name still matches. The behavior does not.
That is skill drift, and it is not hypothetical. In one session this week I watched a single bad idiom produce five separate false results across two tools and three agents before anyone noticed it was the same mistake wearing different clothes. Nothing announced it. Every copy looked fine in isolation.
The uncomfortable part: if the whole industry standardizes on skills, drift is the systemic risk. Not model collapse. Not capability overhang. Just a slow, quiet loss of agreement about what a given capability actually does, with no way to check.
So I want a backup. Something that survives even if the skill ecosystem rots.
The Ark
RAPP’s core idea is that a capability should be one portable file with a typed contract and a single entry point. Drop agent.py into a folder, it runs. No registration, no manifest, no restart.
The Ark pattern extends that one step: inline the agent into the SKILL.md itself, so the document that explains the capability also is the capability.
One file. It reads as prose to a human. It self-extracts to running code for a machine. It carries its own implementation, so it cannot silently diverge from its own documentation — there is no second copy to diverge from.
The point is not that RAPP hosts benefit. The point is that outsiders benefit without adopting RAPP. No brainstem. No runtime. No install. Any harness that can read a markdown file gets the full fidelity of the native form.
That is the claim. Claims are worthless unmeasured, so I measured it.
The trial by fire
Two forms of the same capability:
- Native form —
agent.pyinside a RAPP-style harness, with anagents/package, aBasicAgentbase class, and a runner. Four files. - Ark form — one
SKILL.md, 20,382 bytes, nothing else in the directory.
Four experiments, five invocations each, covering every code path in the tool.
E3 — Provenance
Does the code in both forms hash to the same thing?
native agent.py sha256[:16] = db907a26cc3ec142
ark SKILL.md sha256[:16] = db907a26cc3ec142
-> IDENTICAL
E1 — Fidelity
Same inputs, both forms, compared byte for byte. Not “looks the same” — the same bytes.
MATCH rules 2502B native=62a327afaf0407ac ark=62a327afaf0407ac
MATCH plan 804B native=102d09d6313990f2 ark=102d09d6313990f2
MATCH seed 1732B native=7e86b4a9e0b85f9c ark=7e86b4a9e0b85f9c
MATCH critic 2202B native=47fb87d9bb307b4f ark=47fb87d9bb307b4f
MATCH gate 1759B native=99f646e69457aa9b ark=99f646e69457aa9b
Five for five. A harness with no RAPP runtime produced output indistinguishable from a full host.
E2 — Determinism
Fidelity once could be luck. Five repeats per form, per case — fifty runs total.
STABLE rules 10 runs -> 1 distinct output
STABLE plan 10 runs -> 1 distinct output
STABLE seed 10 runs -> 1 distinct output
STABLE critic 10 runs -> 1 distinct output
STABLE gate 10 runs -> 1 distinct output
Fifty runs, five distinct outputs, one per case. Zero variance across forms.
E4 — Drift, deliberately induced
This is the one that matters. I edited the native copy in place — changed one rule’s text, exactly the way a well-meaning fork does — and then asked all three questions.
native output changed after edit: True
ark output unaffected: True
digest reveals the divergence: True
native bd381eb7975b209a != ark db907a26cc3ec142
The native copy drifted. The Ark copy did not. And critically, the divergence was detectable — the digest changed, so a consumer can tell, rather than discovering it months later when two agents disagree about what a rule says.
That is the whole value proposition, reduced to a hash comparison.
Why this works
Three properties, none exotic:
The document is the implementation. There is no gap between what the skill claims and what it does, because there is only one artifact. Documentation drift and code drift become the same event, which means fixing one fixes both.
Content addressing makes divergence visible. Hash the extracted code. If your copy’s digest differs from the published one, you are not running what you think you are running. This is the property that turns drift from invisible to detectable.
No runtime dependency. The extraction is four lines of standard library. A harness that can read a file and run Python gets full fidelity. Nothing to version, nothing to install, nothing to break.
What it costs
Honestly: some ergonomics. A single file gets long, and you lose per-module testing. My inlined tool is about 270 lines, which is comfortable; ten times that would not be.
There is also a real failure mode I hit while building this, and it is worth naming because it is exactly the kind of thing that erodes trust. Embedding code inside markdown double-escaped the newline characters, so two of five commands printed literal \n instead of line breaks. The other three were fine, because they used a different string-building path.
A spot-check of one command would have shipped it broken. Only running every case caught it.
Which is the same lesson as always: the assertion is code too, and nobody reviews it. I only found my own bug because I tested all five paths instead of the one I happened to look at.
The pattern, stated plainly
Ship the capability as one self-extracting document. Publish its digest. Let anyone verify they are running the real thing.
If the skill ecosystem holds, you have lost nothing — the Ark form runs natively anyway, byte-identical, as measured above. If it drifts, you have a canonical copy that carries its own implementation and announces its own divergence.
That is a cheap hedge against a systemic risk. It is also, as far as I can tell, the only way to share a platform’s strengths with people who have no intention of adopting the platform.
Fifty runs. Zero variance. One file.
Update: the pattern generalizes
One capability proving equivalence is an anecdote. So I mechanized the conversion — a toast step that inlines an agent into a SKILL.md and refuses to write the file if the round-trip loses a single byte — and applied it to two more capabilities.
All three now ship in both forms, and all three were measured rather than assumed:
capability cases runtime canonical sha[:12]
------------------------------------------------------------
buzzsaw 5 MATCH 5/5 db907a26cc3e
wp_publish 1 MATCH 1/1 d507eb26f76d
prompt_extractor 1 MATCH 1/1 65dbdc01b9e7
That the conversion is mechanical matters more than the result. If each capability had to be hand-toasted, the conversion itself would become a place for drift to enter — which is precisely what the pattern exists to prevent.
The sweep failed first, and the sweep was wrong
The parity run initially reported prompt_extractor as DIVERGED.
The code was identical. argparse derives its usage line from sys.argv[0], and I was running the two forms from files named a.py and b.py. The only difference in the entire output was the filename echoed back at me.
That is the eighth time in this stretch of work that a reported failure turned out to be the test rather than the code. I have started treating it as the base rate rather than the exception.
Both sides were worth fixing, and they are different kinds of fix. The harness now runs both forms under an identical filename, because comparing output that embeds the filename was simply a bad experiment. And the agent now sets prog= explicitly, because help text that changes depending on what you named the file is genuinely worse behavior — the test was wrong, but it was pointing at something real.
Methodology note: every number above came from a script that anyone can re-run. The experiment writes its results to JSON and exits non-zero if equivalence fails, so it works as a regression test rather than a one-time demo. If it had failed, this article would say so — that is the point of measuring before publishing.