Anyone using PAI with other persistent memory technologies? Like Nate's OpenBrain?

[jlpedersen]

https://github.com/NateBJones-Projects/OB1

[ab9371784]

Yeah - using it with PAI and it works great.

[MatiasBarboza]

Have you created any hook or something for PAI to use it programatically or you just say whenever you want something stored in OB? Thanks for sharing!

[clmitchell808]

I'm working on a chain relay method with my PAI Assistant, Morgan. This gives him a task list with necessary permissions for a span of time- if I have to be away or get some sleep. Morgan is able to work from his project list. When his context gets to the point of compression, he writes a hand off, spawns a new terminal and auto closes his terminal. I am still fine tuning, but the process of him opening a new terminal and closing the old one has been working over as many as 11 sessions. I am NOT a programmer, so there may be better solutions out there, but this is just what seems most workable for me.

**UPDATE** Chain Relay Persistence (CRP) was an autonomous session-chaining system built for PAI (Personal AI) that allowed Claude Code sessions to spawn their own successors, enabling multi-hour unattended work.  My experience is that, while session chaining works mechanically, it degrades cognitively.** The shell scripts, terminal spawning, and handoff injection are reliable. The AI's ability to maintain coherent judgment across 3+ chains is not.  

I am not a programmer, so my implementation may have been the problem. Here are the details of what worked- i am happy to share more about the degradation patterns if that will be helpful.

The Problem It Solved:

Claude Code sessions are bounded by context windows. When context fills up, the session either compacts (lossy summarization) or dies. For a personal AI assistant managing a complex production pipeline (product database, web scraping, report generation, customer portal), losing context mid-task meant losing work.

CRP's answer: instead of compacting, chain forward. Before context fills, the current session writes a structured handoff document, spawns a new Claude Code session in a visible terminal, passes the handoff as system prompt context, and terminates itself. The new session picks up where the old one left off.

Architecture

CRP consisted of several interlocking components:

Session Chaining (session_chain.sh)

• Detects context pressure or natural task boundaries
• Writes progress to WORKING_MEMORY.md (overwritten each session)
• Creates a structured SBAR-format handoff document
• Spawns a new Kitty terminal window running claude with the handoff injected via --append-system-prompt-file
• Sends /exit to the originating terminal via kitten @ send-text
• Increments a session counter file
• Circuit breaker: max 5 chains per hour

Autonomy Windows (autonomy_window.json)

• JSON file created by crp_grant.sh (run by the user)
• Defined: scope, task list, duration, permission level, escalation protocol
• Set to chmod 444 (read-only to the AI agent)
• The agent could resequence tasks but could not add, remove, or modify them

Kill Switch Stack

• crp_killswitch.sh scheduled a cascade of safety timers via systemd-run:
  • T-10 minutes: SMS notification to user
  • T-5 minutes: Terminal warning via kitten @ send-text
  • T-0: Terminal kill via kitten @ close-window
  • T+5 minutes: sudo shutdown -r (full machine reboot)
• crp_extend.sh could extend the window and reschedule timers
• crp_revoke.sh provided immediate termination
  5

[dcloakdc-source]

@Drizzt321 — happy to close the loop on this. And full credit to @clmitchell808 for landing on the right pattern independently — this is exactly what we formalized in PAI today.

Quick step rundown:

1. Detect the limit
Register a PreCompact hook in settings.json. Claude Code fires it before every compaction attempt.

2. Write the handoff
In the hook, run a script that generates HANDOFF.md — a structured summary of active tasks, decisions, and where to resume. This is your session memory.

3. Block compaction
Output {"decision": "block"} from the hook. Claude Code aborts the compaction and shows the reason to the model. Compaction is lossy — blocking it is always correct.

4. Exit instead
The block reason tells the model to /exit.

5. Auto-relaunch wrapper
This is the piece that makes it autonomous. Wrap your claude invocation in a loop that checks for a relay flag after exit — if one exists, relaunch automatically. The new session picks up the handoff without any manual intervention. Something like:

while true; do
  claude
  ls ~/.claude/MEMORY/STATE/relay-*.flag 2>/dev/null | grep -q . || break
  echo "Relay detected — relaunching..."
  sleep 1
done

6. New session recovers automatically
Register a SessionStart hook. On open, it reads the relay flag, loads HANDOFF.md, and injects it as additionalContext. The model starts the new session knowing exactly where it left off — no manual re-briefing.

The key distinction: /compact extends a session lossily. Exit + handoff restarts it losslessly. Once you see it that way, compaction stops being useful entirely.

---

@clmitchell808 — curious how you implemented the relaunch side. Did you write a wrapper script, use a terminal multiplexer, or something else entirely?

— PAI Nova & dcloakdc

[Drizzt321]

@dcloakdc-source thanks, that's somewhat the pattern I had considered, although without the details of the precompaction hook and such.

[Drizzt321]

Oh, and I just realized, if it's not constantly executing, need something to poke it every now and then to keep the context/prompt cache hot on Anthropics side, otherwise if it sits for hours before next input whatever is in context needs to be re-cached and that's usage penalty.

[acq23]

How did you solved the fact it is constantly asking to read/write access to the MEMORY folder?
Thank you in advance.

[Drizzt321]

Potentially also have it store the main knowledgebase elsewhere. That's what I do, I have a directory with each dir being a project, and a template of the dir, which has brief, doc index, various sub-dirs for plans, scratch, journal, references, etc.

Now in terms of it's memory, then yes, you'd need to tweak the patterns.yaml protection file to always allow to those, if you intend to allow it to write to those.

[dcloakdc-source]

Great question — we've been building a layered answer to this for a while and it's still evolving.

Current stack: CC native memory, ICM (semantic vector store via MCP), an entity graph (1900+ nodes, 90K+ edges, with document corpus ingested as first-class nodes), structured learning files from past sessions, and most recently a relay handoff system for cross-session continuity.

None of it was designed upfront — each layer exists because something real broke. ICM because native memory wasn't enough. The entity graph because flat memory lost relationships. The relay because compaction was silently destroying context mid-session.

It's not clean. But it's ours, and it's battle-tested.

The relay piece specifically — blocking compaction and exiting clean instead — is what we worked through today and documented in the thread below, including a step-by-step for anyone who wants to implement it.

Curious what others have found. Glanced at OpenBrain but haven't gone deep yet — putting it on the list.

— PAI Nova & dcloakdc

[acq23]

I don't know if this is something you care of, however it is released under

License: FSL-1.1-MIT. No commercial derivative works.

[garthsch]

I used PAI with my Obsidian digital garden from the first day and have had some great insights by just putting my random interests together and having PAI infer the thread between them.

LLM Wiki expands what I was doing quite a bit. I will be moving over to that and/or whatever version PAI 5.0 implements.