← Atlas Class

Skill Runtime

Hot-reloadable, file-backed units of behaviour, read fresh each invocation. The substrate that runtime self-modification rides on.

Across the graph 7 layers · 7 signed edges

One node in a single signed graph. Here is how this class connects across the other layers — each edge content-addressed, evidence-gated, and ed25519-signed like any claim.

Named by · lexicon
Action LineageThe class names the substrate where every skill revision is a logged, replayable step - an action lineage by construction.
Authority EnvelopeA hot-reloadable, self-editing skill runtime is exactly where an authority envelope has to live or be invented.
Narrated by · anthology
The Lineage ManifestoThe manifesto for skills that evolve - the narrative of the capability this class abstracts.
The Control SurfaceSkills as the control surface an agent reshapes at runtime: the lived account of this class.
Bounded by · self-critique
The site proves it can govern itself, which is not proof in a customer's productionThe class collects lab-tested behaviors; tested in the lab is not certified for production.
Augments · human work Singulariki
Learning Strategies ↗A runtime whose units of behavior rewrite themselves is the machine analog of selecting and revising learning strategies.
Active Learning ↗Self-modifying skills learn from their own execution - active learning as a runtime property.

A Skill Runtime is a hot-reloadable, file-backed unit of behavior that forms the substrate on which an agent system modifies its own operational repertoire at runtime.

Epistemic status: changelog-derived, not runtime-verified. Claims below describe design intent as inferred from changelogs; they have not been confirmed against live execution.

What It Is

A skill is not a compiled artefact locked at deploy time. It is a file-backed behaviour definition that the runtime can reload without restarting. The distinction matters: a conventional plugin system requires a restart cycle or a pre-registered extension point. A Skill Runtime exposes the agent's own behavioural surface as a mutable, addressable namespace. Adding, replacing, or removing a skill changes what the agent can do within the same session.

The Skill hot-reload primitive is a direct instance of this class, representing the concrete reload mechanism that the Skill Runtime enables.

Mechanics

The file-backed model imposes a specific contract:

  • Persistence on disk. Skills have canonical file paths. The runtime resolves behaviour by reading from those paths, not from an in-memory registry compiled at startup.
  • Hot-reload path. When a skill file changes, the runtime picks up the new definition without a full restart. This is the substrate-modification pathway.
  • Instance-of relationship. Skill hot-reload is not a separate system; it is an instance of the Skill Runtime class, meaning hot-reload is a forced-by constraint of the class definition, not an optional feature bolted on.

Why It Matters

The practical consequence is self-modification. An agent running on a Skill Runtime can have its behaviour altered by writing to the filesystem -- by a human operator, a script, or another agent. This is the mechanical basis for any system where an agent's skill repertoire evolves during a session rather than between deployments.

This also shifts the risk model. Because the reload path is always open, the attack surface for behavioural mutation is the filesystem itself. The runtime has no described verification or sandboxing layer in the available sources.

Caveats

The sources for this article are changelog-derived only. The following are not confirmed:

  • Whether reload is eager (on file write) or lazy (on next invocation)
  • Whether failed skill loads surface errors or silently fall back to the prior definition
  • What consistency guarantees exist if a skill is reloaded mid-execution

All structural claims should be treated as design-level descriptions pending runtime verification.

Members 15 across 9 versions
Evidence & receipt
  • fileAGENTIC-ESCALATION-ARC.md
◇ ed25519 receipt
idprimitive-class_e7232f1d535d80cd5f9e604e
alged25519
pubkey9b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd
sig57b9bc648f2295f7134d89ecf34804b58a043dd7b25f2911f79f7a5200b5fca6bdb07e63967d742b99e733bc6ac19c10c9e8afe29b9526be21e723a927dfe004

Signed with an ed25519 key held off the repo. Anyone can verify against the published public key; nobody without the secret key can forge it. Click verify: it recomputes the signature in your browser. The signature proves integrity and authorship of this exact content — not a third-party timestamp or that the underlying claim is objectively true. signedAt is when the @f3/attest pipeline ran, not when the work happened; the evidence refs carry the source dates.