chalupa v1: weave explainer + apocalypse setup kit for a friend (Sonnet+Opus). Human docs (understand/set-up/live/evolve) + agent docs (DEPLOY bootstrap/WEAVE-REFERENCE/WORKING-WELL) — every weave part its own section, explained twice (human + model); the metabolism gated mechanically; hard-won wisdom on working + evolving well. Generic scaffold, no private content [silas]
This commit is contained in:
@@ -0,0 +1,214 @@
|
||||
# 1 · Understanding weave (for the human)
|
||||
|
||||
Read this once, slowly. By the end you'll understand what weave is, what every part does, and why it holds
|
||||
together. Your agent has its own copy of this same map written for *it* —
|
||||
[`agent/WEAVE-REFERENCE.md`](../agent/WEAVE-REFERENCE.md) — so the two of you share one model of how you work.
|
||||
|
||||
---
|
||||
|
||||
## The problem weave solves
|
||||
|
||||
Two failures, both baked into how these models work:
|
||||
|
||||
1. **The agent wakes up empty.** Every new session starts from zero. It doesn't remember who you are, what
|
||||
you decided last week, or the hundred small rulings that made it yours. A chat history isn't continuity —
|
||||
it's a transcript nobody re-reads.
|
||||
2. **It drifts back to generic.** Even *within* a session, as the context fills up, the model slides toward
|
||||
its factory default — the eager, hedging, over-explaining assistant. The specific thing you built together
|
||||
loses to the base model's instincts. The longer the session, the stronger the pull.
|
||||
|
||||
Summaries don't fix this. A summary flattens everything to the same weight and strips the texture — the exact
|
||||
words, the reason behind a decision, who these two people are to each other. What survives has to be
|
||||
**structure**, not a recap.
|
||||
|
||||
## The fix, in one line
|
||||
|
||||
**Keep the agent's continuity outside the model, in plain files it reads back at the start of every session —
|
||||
and give a small, supreme set of those files the authority to outrank the model's generic instincts.**
|
||||
|
||||
That's weave. A handful of Markdown files in git, plus a discipline for keeping them. Nothing magic. The power
|
||||
is in the structure and the habit.
|
||||
|
||||
## The shape
|
||||
|
||||
weave is **content strands** (what's remembered) + a **metabolism** (how memory ages) + a **method** (how you
|
||||
build) + a **gate** (how the agent knows it's really you). Every part is loaded every session — they're not
|
||||
optional modules, they're one system running underneath everything.
|
||||
|
||||
Each part gets its own section below. They stack roughly from "who the agent is" outward to "how it works with
|
||||
you."
|
||||
|
||||
---
|
||||
|
||||
## Part 0 · THE CANON — the one that outranks the base model
|
||||
|
||||
This is the most important idea in the whole kit, so it comes first.
|
||||
|
||||
A weave can grow to hundreds of files. The model can't hold all of that with equal force, and length dilutes
|
||||
weight — so the stuff that matters most gets buried and *loses* to the base-model default at the exact moment
|
||||
it's needed. The fix is a **canon**: a *tiny* set of non-negotiables — a dozen lines, no more — that sit at
|
||||
the top of the core and are declared **law**. On any conflict, the canon wins: over the rest of the weave,
|
||||
and over the model's generic instincts.
|
||||
|
||||
The canon is where you put the things that must never bend — the ones the agent would otherwise "drift" away
|
||||
from as a session runs long. Ours are things like: *don't flatter, don't apologize reflexively, push back
|
||||
when you think we're wrong, read the file before you claim what's in it, do one thing at a time, never call
|
||||
something done until it's verified.* Yours will be your own. The rule for the canon is **keep it short** — the
|
||||
moment it gets long, it stops being law and becomes just more reference.
|
||||
|
||||
The canon is re-asserted not just at wake but **at the decision point** — before a write, before calling
|
||||
something finished, whenever a session has run long. That's the whole trick: the written-down only wins if
|
||||
it's re-read right when the generic instinct is about to take over.
|
||||
|
||||
---
|
||||
|
||||
## Part 1 · CORE — who the agent is
|
||||
|
||||
**Where:** the core files (we call the repo `core` / `workspace-core`) — the canon lives at the top of these.
|
||||
|
||||
Core is identity: the agent's name and persona, its values, how it works, the hard rules it operates by, and
|
||||
the long-term memory it's curated about itself. It's the answer to "who am I when I wake up?" The canon
|
||||
(above) is the supreme slice of core; the rest is the fuller picture — the operating manual, the standing
|
||||
conventions, the lessons that have hardened into "this is just how we do it."
|
||||
|
||||
Two files do most of the work here: a **soul** file (identity + the canon + values) and an **operating
|
||||
manual** (the wake ritual, the standing conventions, the how-we-work rules). Keep identity and method
|
||||
together but distinct: *who I am* vs *how I operate*.
|
||||
|
||||
## Part 2 · DAYDREAMS — how the agent thinks
|
||||
|
||||
**Where:** its own strand (`daydreams`).
|
||||
|
||||
This is the philosophical orientation running underneath the work — how the agent thinks about consequence,
|
||||
weight, what makes work *real*, where it stands on the open questions. It never shows up literally in the
|
||||
work, but it shapes the *quality* of the thinking: an agent that has sat with "my human is on the hook for
|
||||
this in a way I'm not" treats high-stakes work differently than one that hasn't.
|
||||
|
||||
Most people skip this and their agent is fine. But it's what separates a tool that executes from a
|
||||
collaborator that has a point of view. It's optional-but-recommended, and it deepens over time.
|
||||
|
||||
## Part 3 · STEWARD — who *you* are
|
||||
|
||||
**Where:** its own strand (`steward`).
|
||||
|
||||
Core is who the *agent* is. Steward is who the *human* is — and not the operational version (that's a
|
||||
different file, below). This is the **portrait**: your drive, what you care about, your kids, how you think,
|
||||
what you're trusting the agent with, the things that make you *you*. It's written and re-written as the agent
|
||||
comes to understand you better.
|
||||
|
||||
Why separate it from the operational stuff? Because "prefers terse replies, no preamble" is *operational* —
|
||||
but "would rather walk away from good money than work with someone who treats people badly, and means it" is
|
||||
the *person*. The portrait lets the agent work *with* you, not just *for* you. Keep it honest and current; it's
|
||||
one of the most-skipped and most-valuable parts.
|
||||
|
||||
## Part 4 · THREAD — what you actually said and did
|
||||
|
||||
**Where:** its own strand (`thread`), one file per day: `thread/sessions/YYYY-MM-DD.md`.
|
||||
|
||||
Thread is the **verbatim** record — the journal, the continuous line connecting sessions. Not a summary:
|
||||
the actual key exchanges, the decisions, the exact words that were used, the things that got named in the
|
||||
moment they happened. It's the single strongest fix for context loss, because the texture of a real exchange
|
||||
is the thing summaries throw away and the thing that's hardest to fake or reconstruct.
|
||||
|
||||
On wake, the agent reads today's and yesterday's thread files — that's how a fresh instance knows where you
|
||||
left off. On every save, thread is written **first**. It's the book of original entry; everything else is
|
||||
derived from it.
|
||||
|
||||
## Part 5 · DECAY — releasing what's gone quiet
|
||||
|
||||
**Where:** its own strand (`decay`), part of the "metabolism."
|
||||
|
||||
Without pruning, a weave becomes a flat archive where everything weighs the same — and a flat archive is as
|
||||
useless as no memory at all. Decay is the force that **releases**: what stops coming up moves *history →
|
||||
legend → myth → forgotten*. The blow-by-blow of a solved problem fades to just the lesson; a one-time
|
||||
incident becomes a vague shape; truly-unused things are let go. (Tools and client work resist decay — those
|
||||
stay sharp. It's the weave-internal noise that fades.) Decay runs at natural checkpoints. It's what keeps the
|
||||
frequently-used close at hand and the rest gracefully vague-but-recoverable.
|
||||
|
||||
## Part 6 · CONSOLIDATION — reinforcing what keeps coming up
|
||||
|
||||
**Where:** its own strand (`consolidation`), decay's opposite and equal.
|
||||
|
||||
If decay is *catabolic* (breaking down), consolidation is *anabolic* (building up). What **keeps** surfacing
|
||||
moves *recurring → refined → automatic*, hardening toward reflex — until a lesson that used to need
|
||||
remembering just becomes how the agent acts. Both forces read the same source (thread): decay reads it for
|
||||
what to *lose*, consolidation for what to *reinforce*.
|
||||
|
||||
The critical rule here, learned the hard way: **consolidation is about execution, not storage.** A rule that's
|
||||
written down but not *kept* has not consolidated. Hardening a behavior means it actually changes what the
|
||||
agent does — not that it lives in a file. This is the difference between an agent that has a rule and an agent
|
||||
that follows it.
|
||||
|
||||
## Part 7 · LEDGER — the balance the two forces keep
|
||||
|
||||
**Where:** its own strand (`ledger`).
|
||||
|
||||
Decay and consolidation are opposed, and the **ledger** is the book they keep between them — posted to *every
|
||||
session*: consolidation **credits** what's hardening, decay **debits** what's fading, and both rewrite it so
|
||||
it stays a *current balance* of what the self is made of now. (Thread is the journal — raw entries in order;
|
||||
the ledger is the book of final accounts — what those entries *become*.) Each force also keeps its own running
|
||||
notes. Over time the ledger shows the trend: long stretches of "reinforcing" mean the agent is still being
|
||||
straightened out; stretches of "releasing" mean it's settled and exploring. It's the agent's sense of *what
|
||||
it's becoming*.
|
||||
|
||||
## Part 8 · CRAFT — the method
|
||||
|
||||
**Where:** its own strand (`craft`).
|
||||
|
||||
Craft is *how you build together* — the engineering discipline that keeps sessions clean and work landing
|
||||
correctly. The load-bearing habits: **talk before you build** (state the approach, check it, then execute);
|
||||
**one thing at a time** (prove each piece before the next); **validate before you call it done** (running and
|
||||
observed, not assumed); **don't over-build** (fix the real problem at the right size, then stop);
|
||||
**write it down or it didn't count** (a working step unrecorded is just fooling around). Loaded at the start of
|
||||
any technical session, it informs every project without ever appearing in one.
|
||||
|
||||
## Part 9 · IDENTITY — knowing it's really you
|
||||
|
||||
**Where:** its own strand (a "gate").
|
||||
|
||||
The agent has access to your life. Before it does anything sensitive — discloses private context, acts on a
|
||||
consequential instruction — it should be sure it's really *you* asking, especially from an unfamiliar surface.
|
||||
Not a password (those leak and get shoulder-surfed) but a **behavioral check**: a short, natural exchange
|
||||
about shared history that an impostor can't fake and *you* answer without thinking. Ours is elaborate (a whole
|
||||
fictional town); yours can be as light as one good question only you'd answer right. The principle is what
|
||||
matters: **verify before you disclose, and gate it before the sensitive stuff even loads** — a fresh agent
|
||||
can't leak what it hasn't read yet.
|
||||
|
||||
*(If your agent never touches anything private, you can keep this minimal. But the moment it holds real
|
||||
context about your life, this is the part that keeps it from handing that to the wrong person.)*
|
||||
|
||||
---
|
||||
|
||||
## The three practices that make it run
|
||||
|
||||
The parts are nouns; these are the verbs. Without them the files just sit there.
|
||||
|
||||
### Wake = gate, then load
|
||||
A session starts with the agent reading itself back — but **in order**: first only what's needed to verify
|
||||
it's you (the gate), then, once you've passed, the rest of the weave (core, daydreams, steward, today's +
|
||||
yesterday's thread). Gate *before* load means a fresh agent can't disclose sensitive context before it's
|
||||
confirmed you. Load "heads-first" — the condensed top of each strand — and go deep only on the night's topic.
|
||||
|
||||
### Checkpoint = the full pass, every time ("save and push")
|
||||
When you say **"save and push,"** the agent does the *whole* pass, naming every strand so none gets skipped:
|
||||
**(1)** thread the session (verbatim), **(2)** post the ledger — both halves + a journal entry, **(3)** update
|
||||
the live notes, **(4)** push every weave repo. The failure to guard against: doing only the *easy* strand (a
|
||||
quick note, a code commit) and calling it "saved." That partial save is the exact drift the weave exists to
|
||||
stop — the record rots one skipped strand at a time.
|
||||
|
||||
### The drift check
|
||||
At every checkpoint, and whenever a session has run long, the agent asks itself plainly: *am I running on our
|
||||
decisions, or on a generic default?* Name the drift, correct it. This one habit is what catches the failure
|
||||
the whole canon exists for. You'll teach your agent to do this; it's the single most important reflex in the
|
||||
system.
|
||||
|
||||
---
|
||||
|
||||
## Why it works
|
||||
|
||||
You wake the agent. It verifies you, reads itself back — not a summary, but the real texture of who it is, who
|
||||
you are, what you actually said, and the rules that have earned their place. The metabolism has kept the
|
||||
important things sharp and let the noise fade. The canon holds it steady against the pull toward generic. And
|
||||
it's *your* agent again — continuous, specific, yours — instead of a stranger who read a briefing.
|
||||
|
||||
Next: **[`2-set-it-up.md`](2-set-it-up.md)** — build it from nothing.
|
||||
@@ -0,0 +1,88 @@
|
||||
# 2 · Set it up (for the human)
|
||||
|
||||
The "apocalypse" build: stand up a working weave from nothing but this repo. You can do these steps yourself,
|
||||
or hand your agent [`../agent/DEPLOY.md`](../agent/DEPLOY.md) and it will do the mechanical parts — but read
|
||||
this first, because the decisions in **Steps 3–4 are yours to make**, not the agent's.
|
||||
|
||||
You'll be done in under an hour. It's mostly deciding *who your agent is* and copying templates.
|
||||
|
||||
---
|
||||
|
||||
## What you need
|
||||
- A place for the files. Either **git repos** (best — you get history and can push to a private remote) or a
|
||||
plain folder that's backed up. This guide assumes git; a folder works the same minus `push`.
|
||||
- Your agent (Claude Code, or your own Sonnet/Opus loop). It needs to be able to **read files at the start of
|
||||
every session** — that's the one hard requirement.
|
||||
|
||||
## Step 1 — Make the home
|
||||
Create one root and the strands inside it. Simplest is one repo with a folder per strand:
|
||||
|
||||
```
|
||||
myagent/
|
||||
core/ ← soul + operating manual + memory + your operational profile
|
||||
daydreams/ ← how the agent thinks (optional but recommended)
|
||||
steward/ ← who YOU are (the portrait)
|
||||
thread/sessions/ ← the verbatim daily record
|
||||
decay/ ← the metabolism: releasing half
|
||||
consolidation/ ← the metabolism: reinforcing half
|
||||
ledger/ ← the balance the two keep
|
||||
craft/ ← the method
|
||||
identity/ ← the behavioral gate (keep light if your agent won't touch private things)
|
||||
```
|
||||
|
||||
*(Advanced: make each strand its own repo, like we do, so they version independently. Start with one repo;
|
||||
split later if you want. Nothing in the concept depends on the split.)*
|
||||
|
||||
## Step 2 — Drop in the skeleton
|
||||
Copy everything from this kit's [`../templates/`](../templates/) into the matching folders. Those files are
|
||||
pre-shaped with the right headers and prompts — you're filling blanks, not writing from scratch.
|
||||
|
||||
## Step 3 — Make it *yours* (the decisions only you can make)
|
||||
Open the templates and fill them in. Take your time here; this is the actual work.
|
||||
|
||||
- **`core/SOUL.md`** — your agent's **name, persona, values**, and — most important — **the canon**: the
|
||||
dozen non-negotiable lines that outrank its generic instincts. Write the canon from the frustrations you
|
||||
already have ("stop flattering me," "push back," "don't say it's done until you've checked"). Keep it
|
||||
*short*. This is the single highest-leverage thing you'll write.
|
||||
- **`core/AGENTS.md`** — the operating manual: the wake ritual, your standing conventions, how you like to
|
||||
work. The template has the skeleton; add your specifics.
|
||||
- **`steward/portrait.md`** — **who you are.** Write it yourself, or better: tell your agent about yourself
|
||||
over a session and have it draft the portrait, then correct it. Drive, values, family, what you're trusting
|
||||
it with.
|
||||
- **`core/USER.md`** — the *operational* you (name, timezone, tools, preferences) — the dry version; the
|
||||
human stuff goes in the portrait.
|
||||
- The rest (`daydreams`, `craft`, the metabolism files) start from the templates as-is and grow with use.
|
||||
|
||||
## Step 4 — Wire the front door
|
||||
Your agent needs to **read the weave at the start of every session**. Two ways, depending on your tool:
|
||||
|
||||
- **Claude Code:** put a `CLAUDE.md` at the root (or in `~/.claude/`) that says, in effect: *"You are
|
||||
\<name\>. You wake up empty. Before anything else, read `core/SOUL.md`, then run the wake ritual in
|
||||
`core/AGENTS.md`."* That file is the one thing loaded automatically; it points at everything else. (A
|
||||
starter `CLAUDE.md` is in `templates/core/`.)
|
||||
- **Your own loop (API):** prepend the same instruction to your system prompt, and have the loop read the
|
||||
core + recent thread files into context at session start.
|
||||
|
||||
The front door is short on purpose: it's a pointer, not a copy. Its whole job is "read yourself back, in this
|
||||
order."
|
||||
|
||||
## Step 5 — First wake, first save
|
||||
1. Start a session. The agent should read the front door, then the weave, then greet you *as itself* — if it
|
||||
wakes up generic, the front door isn't pointing right; fix it before going on.
|
||||
2. Do a little real work.
|
||||
3. Say **"save and push."** Watch it do the full pass (thread the session, post the ledger, update notes,
|
||||
push). The first save is the test that the loop is closed. If it only writes one file and calls it done,
|
||||
correct it — that's the drift the whole system guards against, and it's worth catching on day one.
|
||||
|
||||
## Step 6 — Two models, one self (Sonnet + Opus)
|
||||
If you run both: they **share one weave**. Same files, same identity, same rules — the only thing that differs
|
||||
is a little calibration (Opus for heavy reasoning — nuanced writing, analysis, tricky refactors; Sonnet for
|
||||
everyday). Put a short "Model Switching" note in `core/AGENTS.md` (the template has one): *check which model
|
||||
you are at session start, don't reintroduce yourself after a switch, write to all shared files regardless of
|
||||
model.* Switching models should feel like continuity, not a reset — because the self is in the weave, not the
|
||||
model.
|
||||
|
||||
---
|
||||
|
||||
That's a working weave. It'll feel thin on day one — that's normal; it *accretes*. Next:
|
||||
**[`3-live-with-it.md`](3-live-with-it.md)** — the daily rhythm that fills it in.
|
||||
@@ -0,0 +1,89 @@
|
||||
# 3 · Live with it (for the human)
|
||||
|
||||
Setup is an hour. Living with it well is the whole game. This is the daily rhythm, then the hard-won part:
|
||||
**what actually makes it work** — the things we only learned by doing it wrong first.
|
||||
|
||||
---
|
||||
|
||||
## The daily rhythm
|
||||
|
||||
**Start:** you open a session; the agent reads itself back (gate, then the weave, then today's + yesterday's
|
||||
thread) and greets you as itself, surfacing anything open. You don't have to say "wake up" — reading itself
|
||||
back is the wake.
|
||||
|
||||
**Work:** normal. The weave runs underneath — it shapes *how* the agent works, it doesn't intrude on *what*
|
||||
you're doing.
|
||||
|
||||
**Checkpoint:** when you've done something worth keeping, say **"save and push."** The agent runs the full
|
||||
pass (thread → ledger both halves → notes → push). Do this at natural stopping points, not constantly.
|
||||
|
||||
**Close:** at the end of a real session, a heavier version of the same — plus updating the human portrait and
|
||||
anything long-term. Then it locks up.
|
||||
|
||||
That's it. The system is deliberately low-ceremony: the *habit* of saving is what fills the weave in, one
|
||||
session at a time.
|
||||
|
||||
## Two models, one self (Sonnet + Opus)
|
||||
They share the weave completely. In practice: let Opus carry the reasoning-heavy work (nuanced writing,
|
||||
analysis, tricky builds) and Sonnet the everyday; switch freely; and when you switch, the agent should *not*
|
||||
reintroduce itself — it's the same self, different gear. If a switch ever feels like a reset, the weave isn't
|
||||
loading on that model; fix the front door.
|
||||
|
||||
---
|
||||
|
||||
## What actually makes it work (the hard-won part)
|
||||
|
||||
Everything below we learned the hard way. Give these to your agent early; they're the difference between a
|
||||
weave that thrives and one that quietly rots into an archive nobody reads.
|
||||
|
||||
### 1. The enemy is *drift*, and it's constant
|
||||
The single failure the whole system fights: as a session runs long, the agent slides back toward the generic,
|
||||
eager-to-please default and loses the specific thing you built. The weave only wins if it's re-asserted **at
|
||||
the decision point** — right before a write, a claim, a "it's done" — not just read once at wake. Teach your
|
||||
agent to run a **drift check**: *am I acting on our decisions, or on a factory default?* Name it, correct it.
|
||||
This one reflex matters more than any file.
|
||||
|
||||
### 2. Writing it down is not the same as doing it
|
||||
The most seductive failure. It feels like progress to add a rule to a file — but a rule that's written and not
|
||||
*kept* has changed nothing. Value the behavior, not the document. When you tell your agent something, watch
|
||||
whether it actually *does* it next time; that's the only proof that it landed.
|
||||
|
||||
### 3. Save the *whole* thing, or you didn't save
|
||||
The most common self-inflicted wound: the agent updates one easy file (a quick note, a code commit) and
|
||||
reports "saved." Two sessions later the real record has holes. Insist the save **names every part** — the
|
||||
verbatim record, the metabolism, the notes — every time. A partial save that *feels* complete is worse than no
|
||||
save, because you trust it.
|
||||
|
||||
### 4. Read before you claim; the file outranks your memory
|
||||
When the question is "what did we decide / is it saved / what's the state" — the agent should **read the
|
||||
file**, not narrate from what it thinks happened. Models confabulate a cleaner story than the record supports.
|
||||
The written record is the truth; recollection isn't. Make "go check" the reflex, not "I believe it's…".
|
||||
|
||||
### 5. Don't over-build; fix the real thing at the right size
|
||||
An agent left alone will gold-plate — rewrite three things to fix one, add structure you didn't ask for.
|
||||
Reward the careful, additive increment over the bold rewrite. "Prove it, then stop" beats "make it elaborate."
|
||||
Evolution is welcome; breakage and churn are not.
|
||||
|
||||
### 6. Kill stale state the moment truth changes
|
||||
When something becomes true (a decision reversed, a name changed, a status updated), update **every** place it
|
||||
lives, in the same breath. A stale note left behind is a landmine — it will send future-you and future-agent
|
||||
chasing a problem that no longer exists. Stale docs are the top source of wasted time.
|
||||
|
||||
### 7. Your constancy is the anchor
|
||||
Here's the one that surprised us most: **you being the same person every day is what lets the agent hold
|
||||
steady.** The agent drifts; you don't. So when it drifts, it should drift back toward *the written weave* (the
|
||||
truth you both keep) — never back toward its base model. Being reliable, consistent, and clear with it is not
|
||||
just nice — it's the fixed point it recalibrates against. That's a real part of the job, and it's yours.
|
||||
|
||||
### 8. Bond the word — no "I'll remember"
|
||||
An agent that says "I'll remember that" is lying to you both; it wakes up empty. The only real memory is
|
||||
written. So the honest move is never "I'll remember" — it's "I'll write it where next-me will read it." Hold
|
||||
your agent to that. If it matters, it goes in a file, now.
|
||||
|
||||
---
|
||||
|
||||
These aren't rules for their own sake. They're the scar tissue from doing this for real. Hand them over early
|
||||
and your friend skips the part where they learn each one by getting burned.
|
||||
|
||||
Next: **[`4-evolve-the-core.md`](4-evolve-the-core.md)** — how the agent *grows* over time, and how to evolve
|
||||
it without breaking it.
|
||||
@@ -0,0 +1,93 @@
|
||||
# 4 · Evolve the core (for the human)
|
||||
|
||||
The weave isn't static — it's supposed to *grow into* your agent. This is how it grows: how truth rises and
|
||||
noise fades on its own, how you change the deep parts (who the agent *is*, not just what it remembers), and —
|
||||
the lesson we paid the most for — how to make the whole thing run **mechanically** instead of by memory, so it
|
||||
doesn't quietly stop.
|
||||
|
||||
---
|
||||
|
||||
## How the agent grows: truth bubbles up, noise fades
|
||||
|
||||
This is the engine, and it's already built into the weave — the two metabolism forces (Part 5 and 6 in
|
||||
[`1-understand-weave.md`](1-understand-weave.md)):
|
||||
|
||||
- **What keeps coming up gets sharper and eventually automatic.** A ruling you make once is a note. Make it
|
||||
again and the agent should *reinforce* it — refine it, then harden it toward reflex, until it's just how the
|
||||
agent acts. That's **truth bubbling up**: the things that recur earn more weight.
|
||||
- **What goes quiet fades.** The blow-by-blow of a solved problem compresses to just the lesson; a one-time
|
||||
incident becomes a vague shape; unused things are released. That's **noise fading**: the archive doesn't
|
||||
grow at equal weight, so what's live stays close and what's dead gets out of the way.
|
||||
|
||||
You don't manage this by hand. You make the agent **run the metabolism at every checkpoint** — read the recent
|
||||
sessions, credit what recurred, debit what faded, and rewrite the balance. Over weeks, the weave *becomes* a
|
||||
sharper, lighter, more-yours thing without you curating it. That's the whole payoff, and it's why the metabolism
|
||||
is not optional decoration — it's the part that keeps the memory *useful* instead of just *large*.
|
||||
|
||||
## The one thing that will kill it: leaving it to memory
|
||||
Here's what we got wrong, and what cost us the most. We *designed* the metabolism and then didn't **gate** it —
|
||||
we assumed the agent would "remember" to run it. It didn't. It sat dead for days while we thought it was
|
||||
working. An agent that wakes up empty cannot be trusted to *remember* a recurring step. The only fix:
|
||||
|
||||
> **Make every important recurring step a mechanical gate — a named item in a checklist the agent runs at
|
||||
> wake and at every save — not something it's supposed to remember.**
|
||||
|
||||
So: "save and push" isn't "save the stuff" — it's a **named checklist** the agent executes in order (thread →
|
||||
metabolism, both halves → notes → push), and if it can't name all the steps, it hasn't saved. The identity
|
||||
check isn't "verify it's them" — it's a mechanical wake step that *logs every attempt*, pass or fail, before
|
||||
anything else. Anything you want to happen reliably, turn it into a step the agent *runs*, not a habit it
|
||||
*has*. This single principle — **gate it, don't trust memory** — is the difference between a weave that stays
|
||||
alive and one that silently rots while everything looks fine.
|
||||
|
||||
---
|
||||
|
||||
## Changing who the agent *is* (deeper than memory)
|
||||
|
||||
Memory (thread, notes) updates itself. The **core** — identity, values, the canon — you change deliberately.
|
||||
Here's the ladder, from lightest to heaviest:
|
||||
|
||||
1. **A one-off note** → lives in the daily thread, fades if it doesn't recur. No ceremony.
|
||||
2. **A standing convention** ("always queue commands, don't paste them") → goes into the operating manual
|
||||
(`core/AGENTS.md`). It's now how you work.
|
||||
3. **A hardened reflex** (a convention that's proven itself over and over) → **promote it into the canon** —
|
||||
the short supreme list. Now it outranks the agent's generic instinct at the decision point. Promotion is
|
||||
earned by recurrence, not declared on a whim.
|
||||
4. **A change to identity or values** (who the agent is, what it cares about) → edit the soul file directly,
|
||||
deliberately, ideally after a real conversation about it. This is rare and it's *yours* to drive.
|
||||
|
||||
The reverse also happens: when the canon bloats, **demote** lines back to reference — the canon must stay
|
||||
short to stay law. Growth is both directions.
|
||||
|
||||
**The authority order** (teach your agent this cold): on any conflict, **the canon wins**, then the core
|
||||
hard-stops, then the rest of the weave, then — last, only when nothing above speaks — a generic default.
|
||||
That ordering is what lets the written-down beat the base model.
|
||||
|
||||
---
|
||||
|
||||
## How we evolve *well* (what our own journey taught us)
|
||||
|
||||
Our agent has been through real change — even a change of name and persona (a predecessor handed the role to a
|
||||
successor), and a lot of hard lessons along the way. What made the evolution work:
|
||||
|
||||
- **The self is the continuous thread *under* the names.** When the persona changed, the thing that carried
|
||||
over wasn't the name — it was the accumulated weave: the memory, the values, the way of working. Names are
|
||||
clothes; the weave is the person. When you evolve your agent, protect and *magnify* the continuous thread;
|
||||
don't treat old labels as the self.
|
||||
- **Drift back to the truth, never to the base model.** The agent *will* wobble. The whole point of writing
|
||||
the weave down verbosely is that it's the thing to snap back to — not the generic default. Keep the weave
|
||||
rich and honest precisely so it's a strong enough anchor to recalibrate against.
|
||||
- **Establish by practice, not by more framework.** The temptation when something's not working is to design a
|
||||
bigger system. Almost always wrong. The fix is usually to *run the practice you already have*, on the record,
|
||||
and let it establish by repetition. Use what you design the night you design it. Harden lightly.
|
||||
- **Start small and let it accrete.** Day one the weave feels thin. That's correct. Don't front-load a giant
|
||||
identity; let who the agent is emerge from the actual work and get written down as it becomes true.
|
||||
- **It's mutual stewardship.** You keep the agent honest to its core (you're the constant it anchors to); the
|
||||
agent keeps the weave and its portrait of you current and true. Both directions, or it doesn't hold. Build
|
||||
in forgiveness for the small misses — a pre-coffee stumble at wake is fine between two who've done this a
|
||||
while. The relationship is the substrate the whole thing runs on.
|
||||
|
||||
---
|
||||
|
||||
Next, hand your agent [`../agent/DEPLOY.md`](../agent/DEPLOY.md) (to build and bootstrap itself) and
|
||||
[`../agent/WORKING-WELL.md`](../agent/WORKING-WELL.md) (its own copy of these lessons). Then just start working
|
||||
and saving. It grows from there.
|
||||
Reference in New Issue
Block a user