Lesson 6 · ClaudeTag

The Memory Lifecycle

Curating what your channel Claude learns — and the privacy trade-off underneath it.

~6 min · builds on Lesson 5 · Mission: better Prism/agent prompts

You know memory is channel-scoped and persistent (Lesson 2). This lesson is about its lifecycle: what goes in, how it's governed, and how to stop it rotting — the same discipline you apply to your own memory notes.

1. What it learns, and from where

By default a ClaudeTag learns from its own channel's activity. With permission it "can even automatically learn from other Slack channels and data sources."[ref §3] Independent coverage put the flip side plainly: it's "learning your company one Slack message at a time."[TechCrunch] Persistent memory is an asset and a liability in the same breath.

2. It's inspectable — so govern it

Admins can view, edit, and delete stored memory in Organization settings.[ref] That turns memory from a black box into something you curate, exactly like your MEMORY.md:

Your memory hygieneClaudeTag equivalent
Delete memories that turn out wrongEdit/delete a stale channel memory before it misleads
Don't store what the repo already recordsDon't let it memorise noise it can re-derive
Verify a recalled fact still holdsTreat old channel memory as "true when written"
Prism transfer Your own rule — "recalled memories reflect what was true when written; verify a named file/flag still exists" — applies verbatim to a ClaudeTag. A channel that memorised "live account = 1513552477" months ago will confidently cite a burned account. Curate, or it drifts.

3. The privacy boundary

Two facts bound the risk: channel memory is kept separate from your Claude.ai history, and it stays scoped to the channels an admin defines.[ref] For a live-trading estate that means: keep secrets out of channel chatter (they'd become memory), and never bridge a sensitive channel outward without a reason (Lesson 4's wall).

Anything you'd refuse to paste into a memory note: live credentials, account passwords, API keys, secrets. Your estate already keeps these in Keychain / a DPAPI store precisely so they never land in plaintext notes — the same rule holds for a channel a Claude is memorising. If a secret must be used, it belongs in a scoped Access-bundle credential, not typed into the thread.

A channel memory from months ago names a now-burned account. Best practice?

Memory is "true when written." Admins can edit/delete it, so curate stale entries — same as pruning a wrong MEMORY.md note. Stored memory is not self-refreshing, and spend caps are unrelated.

Why keep live credentials out of a Claude-watched channel?

What's said in the channel can be remembered — so a pasted secret becomes stored memory. Use scoped Access-bundle credentials instead. Secrets don't affect latency or billing.

Your win

You can treat a ClaudeTag's memory as a curated store, not magic: seed it deliberately, prune what's stale, and keep secrets out. It's your existing memory hygiene, pointed at a channel.

Read this next ~6 min, the outside view: TechCrunch on the memory model.
Ask your teacher Next: Lesson 7 — setup, spend & the audit log: the operational governance that keeps a live-money ClaudeTag accountable.