What it takes
to remember

Every AI session starts cold. Whatever we decided yesterday, the agent opening my folder this morning doesn't know it. It doesn't know which draft is current, which idea we killed and why, or that the thing it's about to "discover" is something we tried in August.

For a while I solved that the way everyone does: a long notes file and "read this first." It works until the notes are longer than the work. Then the agent reads half, guesses the rest, and confidently rebuilds a decision I already overturned.

Hearth is what I built instead. The Kingdom is my working system: a set of separate project workspaces I call houses, each with its own job, sharing one set of tools. Hearth is the part of those tools whose whole job is continuity, so the next session starts from where the last one stopped instead of from a reconstruction of it. Each kind of agent I use reaches it through its own packaging; that plumbing gets its own piece.

It worked for months. Then, over about a week in late October, it started failing in ways that taught me more than the months it worked.

Text description of Figure 4

A loop of four stations. Kindle reads the charter, capsule, ledger and handoff in order and checks freshness. Capture drops one small note per decision into a pending folder. Fold applies pending notes to the capsule under a lock. Bank recaps, records decisions and lessons, and closes the session, then feeds the next kindle. Above the loop sit three automatic hooks: an orientation at session start that asks the agent to kindle, house attribution before each tool call, and a log line at stop; the last two write no memory. Kindle, capture and fold are done by the agent following rules; bank is triggered by a person. Two failure points are marked: a freshness check that compared only dates, and a correct write refused at close because a detail the integrity check counted had changed.

The names came from a hearth. Picture whichever one you like: a stone fireplace built into an old house, or a ring of rocks at a campsite. Either way, in the morning you gather kindling and get a fire going from what's left. At night you bank it: rake the coals together, cover them, and put the wood somewhere dry so tomorrow's fire starts fast.

So the two original verbs are kindle and bank.

Kindle is the warm start. It reads a small, fixed set of files in a fixed order: the house's charter, a compact capsule (four fields: why the house exists, the rule that decides what work counts, what's open, and what's next), the decision ledger, and a handoff note from the last session. Then it checks whether the capsule is fresh before trusting it. The order is the design. The agent reads the frame first and the details second, so it starts from "here's what we're doing and why" instead of whatever file it happened to open.

Bank is the end-of-milestone close. It recaps what changed, writes decisions to the ledger with the reason and what was rejected, records lessons, prunes what's stale, and checks that the capsule now tells the truth. Bank is the expensive one, and the one that gets skipped.

Two verbs came later, once it was obvious that banking only at the end lost everything in the middle. Capture drops one small typed note (a decision, a state change, an open item) into a pending folder the moment it happens. Fold applies the pending notes to the capsule in order, under a lock, so two sessions can't both rewrite it at once.

We never gave those two fire names. In hindsight, capture is gathering the wood and fold is stacking it. I'll leave that as a lesson about naming things while you're busy.

One helper matters as much as the verbs: the session claim. Before an agent writes anything the house treats as canon, its official record, it claims a session naming the files it intends to change. Two agents in one house can't overwrite each other, and a closing session has to show it changed only what it claimed.

One capture, one capsule

Here's a real capture from this house, lightly trimmed:

{
  "kind": "decision",
  "text": "chose story-first editorial intent: setup, context and connections carry the articles; evidence roughly a quarter or less",
  "why": "agents kept driving to the nearest provable example and skipping the setup the story needs",
  "rejected": "evidence-first commissioning; ranking stories by provability"
}

That's the whole flow in miniature. Notes land in a pending folder. Fold applies them to the capsule, a few kilobytes of JSON with the four fields every house shares (thesis, the_governing_gate, open_items, next), and appends each decision to the ledger, which is the permanent log. The capsule is the current summary a cold session reads first; the ledger is the history behind it. If you build one thing from this essay, build that: a typed note at the moment of decision, with the why and the rejected, folded into a summary small enough to read first.

People ask about this part most. There are three kinds of work in Hearth, and the line between them is deliberate.

What happens	Who triggers it
A short orientation prints when a session starts	Automatic (a start-up hook)
Each file touched is attributed to the right house	Automatic (a hook before each tool call)
A line is logged when a session stops	Automatic (that's all the stop hook does)
Kindling: reading the capsule in the right order	The agent, told to by the orientation and the charter
Claiming a session before canonical writes	The agent, by rule
Capturing a decision as it happens	The agent, by rule. Nothing forces it
Folding captures into the capsule	The agent or me, periodically; changes to the authored fields are flagged for me
Banking at a milestone	My decision, carried out by me or by the agent when I say "bank"
Anything published, spent, deleted or begun	Me. Always

Hooks are small scripts the app runs on its own at set moments. The automatic layer is thin on purpose: a hook can run a script, but it can't exercise judgment. I can automate "you're in this house now." I can't automate "that was a decision worth writing down." Capture isn't a hook because the moment a decision happens isn't an event the software sees. It's a sentence in a conversation.

Bank stays with me for a different reason. A bank rewrites what the house believes is true, and an agent that banks on its own schedule is grading its own homework. Same rule as everywhere in the Kingdom: the maker doesn't get to be the judge.

If I start a task without saying "kindle," does Hearth still kick in? Partly. The start hook always fires, and it prints a contract telling the agent to orient, read the charter and check the board, the running page that tracks every piece of work and its status. But the hook doesn't kindle, and it doesn't claim a session. Those are the agent's to do. If the agent skims past the contract and goes straight to the work, the work still gets done, and none of it gets remembered. Nothing complains loudly, either.

That gap bit us one morning that week. A session in this house kindled, checked freshness, and got a pass. The capsule carried a recent date. It was also wrong. Over the previous few days, dozens of sessions had saved real work (drafts, plates, site changes) without writing a single capture, so the capsule still described the house as it was days earlier.

The freshness check compared dates. It never compared what the capsule claimed against what the board showed: open items the board had already marked done, a "next" that had already happened. So a capsule could carry yesterday's date, describe last week, and pass.

That one's on the design, not the agent. Capture by rule degrades quietly. Nobody decides to stop capturing. A busy session just doesn't, then the next one doesn't, and the check that should have noticed was reading the date stamp. The lesson we wrote down: capture at the decision, and have kindle compare the capsule's claims against the board.

The second failure was louder, and it's the one that made me look under the floor.

When a Hearth session claims its files, it records a fingerprint of each one. When it closes, it fingerprints them again and checks the result against what it said it would write. If they don't match, it refuses to close. That's the integrity rule, and it's a good one: no session can quietly change something it didn't claim.

That week, sessions started writing their files correctly and then refusing to close. The bytes on disk were exactly right, but the close said they didn't match. One session got stuck holding its claims, and the sessions after it couldn't get around it. With no clean close, there was no bank.

The cause turned out to be almost funny. Many of my sessions don't run on my own computer. They run in a cloud workspace that reaches my folders through a connection, and that connection hands files back with slightly different permissions than my computer would. Hearth's fingerprint counted permissions. So a file that was byte-for-byte correct looked changed, and Hearth refused a perfectly good write over a detail that had nothing to do with the content.

Underneath sat a slower problem. The ledger had grown large, and every check that replays it got slower over the cloud connection.

The Kingdom has a rule for this: find it, fix it. A house that hits a problem assesses it, fixes what's reasonably within reach, then hands the fix to Foundry, the house that keeps the shared tools. No one gets off the hook by filing a complaint. So this house found the cause, wrote a narrow fix that tolerates that connection's quirk while still refusing real tampering, proved the tampering cases still get refused, and handed it to Foundry. A tool every house depends on should carry a lot of review before it changes, so that fix is still in review.

So, was it really working? For months, yes: captures, folds and banks ran cleanly, and decisions carried their reasons. I'll grant the irony that a record can look current and be wrong; that's the first failure. The second started because more of the work moved to the cloud and the house got big enough for the connection's quirks to matter. The design assumed a local disk, and for most of its life that held.

This is the part I have to be most careful with, because it's observation from one setup, not proof.

In my setup, the difference turned out to be mostly where the work runs, not which model does it. As of October 2026, I point both of my agent tools, Anthropic's Claude desktop app and OpenAI's Codex, at the same folders so they work in the same Kingdom. (I pay for both; neither sponsored or reviewed this.) Codex runs right where the folders live, so its hooks, its scripts and the data are all in one place. Claude's desktop app can run a task in the cloud or on my computer, and for a stretch most of my Claude work ran in the cloud.

In a cloud task, Hearth's hooks run in a workspace where the Kingdom isn't there. They look for a registered Kingdom, find none, and do nothing, while the agent reaches my files another way. Switching back to local helped less than I hoped; in some setups the hooks still can't see the folders. So in my setup, Codex has reliably landed its work and banked, and Claude often couldn't write its memory back, even when the work itself was fine.

That's a fixable mismatch. Under the same find-it-fix-it rule, the list went to Cupel, the house that does the Kingdom's research, and a candidate fix came back the same evening. The part worth copying is how they tested it: one frozen copy of the fix, run through the same checks on both tools. Every rule tested so far behaved the same on each. What differed was the machine underneath, and each difference got sorted into one of three bins: a setting I can change, a limit of the platform, or an assumption in our own code. That turns "it works on one and not the other" from a hunch into a list.

The fix isn't released yet. Two cases still haven't been tested end to end.

The cloud connection plays by slightly different rules in smaller ways too. We've caught it serving a stale copy of a just-edited file to a helper agent, and it can't remove even the throwaway lock files tools leave behind; the Kingdom archives and never deletes work, so only that tool housekeeping trips on it. Small things, but a protocol that's solid locally can be flaky remotely, and the agent usually can't tell which world it's in.

If you want to build something like this, this is the list I'd hand you. We learned it mostly by watching each item fail to hold.

1. The agent can read the frame before it acts. A start-up signal that tells it to load memory, and a small, ordered set of files it can actually reach. Without that, every session improvises its own orientation.
2. A session starts properly, or it doesn't count. Orient, claim, then work. A session that skips the claim can do excellent work and leave no memory of it. And when a session can't remember, it should say so out loud instead of failing quietly.
3. The scripts are reachable from where commands run. Not "the skill is installed," but actually runnable from the shell the agent uses. Keep a copy next to the data if you have to.
4. The filesystem behaves like the one you designed for. Permissions, lock-file cleanup, fresh reads and time limits. If your integrity checks fingerprint files, know which filesystem they'll meet.
5. Capture is cheap enough to happen in the moment. One small note, not an essay. If writing it down costs more than the decision took, it won't get written.
6. Freshness is checked against the work, not the clock. A date tells you someone touched the file. It doesn't tell you the file is true.
7. A person decides what becomes canon. The agent proposes; the bank is a human decision.
8. The memory stays small. Every replay, every kindle and every check gets slower as the ledger grows. Compacting it, keeping a snapshot and trimming the replayed history, isn't housekeeping; it's how the protocol stays inside its time budget.

Most of the list above is still a discipline, not a guarantee. Three gaps are worth naming on their own:

• The house has to diagnose its own environment. The pending fix teaches it to recognize the cloud case. Stale reads still rely on the agent knowing to check first-hand.
• Recovery is manual. A stuck session needs a person to look at what's on disk and release it. That's by design, and it's also friction.
• I can only speak for my setup. Two agent tools, one person's Kingdom, a few months. Treat this as a field account.