Blog practitioner posts

Claude Code Memory / Multi-Agent / Fleet — Blog Prior Art Summary

14 posts. Captured 2026-05-11. Per-post markdown saved alongside this file.

1. Writing a good CLAUDE.md

URL: https://www.humanlayer.dev/blog/writing-a-good-claude-md Author: Kyle (HumanLayer) · Date: 2025-11-25

Thesis: CLAUDE.md is the highest-leverage memory file you write; keep it small, universal, and offload everything else to a agent_docs/ directory loaded on demand.

Practical advice:

Keep CLAUDE.md under 300 lines, ideally far fewer. HumanLayer’s root file is under 60 lines.
Cover only the three universal dimensions: WHAT (stack/structure), WHY (purpose), HOW (commands/workflows).
Frontier LLMs reliably follow only 150–200 instructions; Claude Code’s system prompt already burns ~50. Budget accordingly.
Use Progressive Disclosure: put task-specific guidance in agent_docs/*.md files referenced by name from CLAUDE.md, instruct Claude to read them when needed.
Never use Claude as a linter. Use Claude Code Hooks to run real linters/formatters, or Slash Commands for style guidance.
Do NOT auto-generate CLAUDE.md. Hand-craft it.

Novel/non-obvious:

Anthropic explicitly tells Claude: “this context may or may not be relevant to your tasks” — so dumping irrelevant content makes Claude ignore the file entirely. Bloat literally reduces obedience.
file:line references age better than embedded code snippets.

Relevance: HIGH — directly contradicts the “stuff everything in CLAUDE.md” anti-pattern. Our global is already ~200 lines via imports; this validates aggressive trimming + Progressive Disclosure pattern (which we already do via topic router files).

2. We Read Claude Code’s Leaked Source. Here’s How Its Memory Actually Works

URL: https://milvus.io/blog/claude-code-memory-memsearch.md Author: Cheney Zhang (Milvus/Zilliz) · Date: 2026-04-03

Thesis: Claude Code’s leaked 2.1.88 source reveals a 4-layer memory system (CLAUDE.md → Auto Memory → Auto Dream → KAIROS) with hard structural limits — 200-line index cap, grep-only retrieval, no cross-tool portability — that vendor-side patches can’t fix.

Practical advice:

Treat the 200-line MEMORY.md cap as a hard physical limit — anything past line 200 is invisible.
Auto Memory organizes notes into 4 categories: user_*, feedback_*, project_*, reference_* — each as a separate .md file pointed to from MEMORY.md.
Auto Dream trigger: >24h since last cleanup AND >=5 new sessions. Run manually with “dream”.
KAIROS (unreleased) defers any action that would block the user >15 seconds. Worth borrowing as a design budget.
The leaked system prompt tells Claude to treat its own memory as a hint, not a fact — verify against real code before acting. Adopt this for any memory system.

Novel/non-obvious:

Grep-only retrieval is the killer limit, not the 200-line cap — “port conflicts” in your head ≠ “docker-compose port mapping” in the note.
Auto Dream resolves contradictions and replaces vague time references with exact dates (“yesterday’s deploy” → “2026-03-28 deploy”). This is a real memory hygiene primitive.

Relevance: HIGH — this is the canonical reference for what Claude Code’s native memory actually does and where it caps. Direct input for our memory architecture.

3. Claude Code Memory Explained

URL: https://joseparreogarcia.substack.com/p/claude-code-memory-explained Author: Jose Parreño Garcia · Date: 2026-02-24

Thesis: Memory isn’t conversation tuning — it’s coordination. Treat global/project/rules files as a “working contract” defining how Claude operates (plan vs. act, ask vs. proceed), not how it sounds.

Practical advice:

Global CLAUDE.md ≈ 50 lines is enough. Author’s example covers Voice, Primary Objective, Planning/Change Control, Communication Style, Output Defaults.
Project CLAUDE.md size guidance: 20–80 lines (small repos), 80–200 lines (typical), >200 lines means split into .claude/rules/*.md.
Use paths: frontmatter on rule files to make them path-scoped (load only when editing matching files).
Use @path/to/import pointers for deeper guidance loaded on demand.
Define a clear trivial/non-trivial boundary so Claude knows when to plan vs. act. Author’s threshold: new functionality, multi-file changes, files >50 lines, docs >300 words = plan first.

Novel/non-obvious:

Reframing memory from “personality” to “coordination” — pre-text decisions (plan? ask? edit?) happen before generation, so memory shapes what Claude does, not what it says.
The trivial/non-trivial threshold encoded as concrete LOC/word counts removes the “ask first” judgment from Claude.

Relevance: HIGH — closest match to how our fleet ethos is written (operational contract, not personality). The threshold pattern is borrowable.

4. I tried 3 different ways to fix Claude Code’s memory problem

URL: https://dev.to/gonewx/i-tried-3-different-ways-to-fix-claude-codes-memory-problem-heres-what-actually-worked-30fk Author: decker · Date: 2026-02-27

Thesis: All three popular fixes (manual notes, SQLite-MCP, git-tied session replay) are workarounds for a tool design gap; a hybrid covers ~80% of needed continuity but native session persistence is the real fix.

Practical advice:

CLAUDE.md + notes/YYYY-MM-DD.md works if you’re disciplined. Author skipped writing notes ~40% of the time.
SQLite-via-MCP memory captures what was decided but loses why — disconnects decision from code state.
Mantra (git-state-tied session replay) is the best for after-the-fact recovery but requires manual review and prompt reconstruction.
Hybrid: SQLite MCP for “remember this” moments + Mantra for session history review + minimal CLAUDE.md notes for non-obvious insights. 3–5 min per session overhead.

Novel/non-obvious:

The decision-state coupling problem: a memory of “we chose PostgreSQL” without the code state at that moment is half-useful. Git-state binding is the cleanest fix.
Honest framing — these are all workarounds. None solve the underlying limitation.

Relevance: MEDIUM — mostly confirms what we already know. The git-state-coupled-memory idea is the takeaway.

5. How I Built Persistent Memory for Claude Code (claude-brain)

URL: https://dev.to/mikeadolan/how-i-built-persistent-memory-for-claude-code-1dn7 Author: Mike Dolan · Date: 2026-04-02

Thesis: A 6-hook + SQLite + 3-search-mode memory system that captures every conversation losslessly, with personal vs. project scoping, is sufficient to give Claude usable cross-session memory at scale (1,321 sessions, 67k messages).

Practical advice:

Use all six Claude Code hooks: session-start, user-prompt-submit, stop, session-end, pre-compact, post-compact. Pre/post-compact pair is critical for surviving in-session compaction.
Local SQLite with FTS5 keyword + sentence-transformer embeddings + fuzzy — three search modes, no cloud, no API keys.
Score sessions -3 to +3 automatically; tag with completions, decisions, debugging, corrections, rework, frustrated. Lets you query “show me my worst sessions” or “where did I rework most?”
Verify-at-retrieval, not at write-time — when memory names a file path, check it exists before acting. Raw data never deleted; staleness never causes silent failure.
Scope: personal preferences (writing style, working hours) global; project facts (architecture, repo structure) per-project. One DB serves all.
Crystallization thresholds (from comments): security issues 1–2 occurrences, workflow corrections 3, style preferences 5+. Formula: ceil(3/severity_weight).

Novel/non-obvious:

Lossless append-only event sourcing means search improvements retroactively benefit all 67k historical messages.
Cross-platform import — ChatGPT/Gemini/Claude.ai conversations all merge into one searchable corpus.
Multi-machine via Dropbox/iCloud syncs project files only — never the DB (SQLite + cloud sync = corruption). DB backups sync, not live DB.

Relevance: HIGH — directly applicable to our fleet. The hook-pair pattern for compaction, the scoring/tagging dimensions, and the global/project scoping rule are all reusable. The “no DB over cloud sync” warning matches our existing ~/.claude.json + .claude-peers.db setup.

6. Using tmux with Claude Code

URL: https://hboon.com/using-tmux-with-claude-code/ Author: Hwee-Boon Yar · Date: 2025-11-28 (updated 2026-05-11)

Thesis: A short list of tmux configuration tweaks that make Claude Code usable inside tmux, plus the observation that Claude Code itself understands tmux commands well enough to coordinate sibling sessions.

Practical advice:

.tmux.conf: set -g allow-passthrough on; set -s extended-keys on; set -as terminal-features 'xterm*:extkeys' — required for Shift+Enter + notifications.
Use normal tmux, not iTerm2’s tmux -CC integration — the integration mode breaks Claude’s alternate screen buffer and mouse tracking.
/tui fullscreen inside Claude Code + set -g mouse on enables wheel scrolling.
Copy mode: ctrl-w [ to enter; capture pane to editor: tmux capture-pane -t 0 -p -S -10000 | v.
Bind passthrough for control shortcuts: bind o send-keys C-o lets ctrl-w o send ctrl-o.
Run 3-5 concurrent Claude Code sessions in separate tmux windows, auto-rename to show what each is working on.

Novel/non-obvious:

Claude Code knows tmux subcommands — it can read sibling pane contents, scroll back, issue commands. A “main” Claude can supervise its siblings via tmux directly, no fancy orchestration framework needed.
iTerm2 tmux-CC is actively harmful. Worth flagging.

Relevance: MEDIUM — useful baseline tmux config. We already use tmux extensively for variant sessions, so the integration warning and the “Claude understands tmux” insight are confirming.

7. Watch Claude Code Agents Work Side by Side: A tmux Setup Guide

URL: https://ksingh7.medium.com/watch-claude-code-agents-work-side-by-side-a-tmux-setup-guide-1ef3ba1531c4 Author: Karan Singh · Date: 2026-03-01

Note: Original Medium URL returned 403. Content recovered via the dariuszparys.com mirror.

Thesis: A full macOS tmux + Catppuccin + Claude Code recipe for watching agent-team teammates work in side-by-side visible panes instead of as invisible background processes.

Practical advice:

Required settings: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1" + CLAUDE_CODE_SPAWN_BACKEND: "tmux" + teammateMode: "tmux" in ~/.claude/settings.json.
Layout binds: t tiled, v main-vertical (lead left), h main-horizontal (lead top).
3-5 agents max — past that, token cost and coordination overhead dominate.
synchronize-panes toggle on S for broadcasting keystrokes (useful if you want every agent to receive the same instruction at once).
Mouse drag-select pipes to pbcopy automatically.
Status bar with CPU/RAM thresholds (50/80 CPU, 60/85 RAM) — visual warning before overloading the machine.

Novel/non-obvious:

The official CLAUDE_CODE_SPAWN_BACKEND: tmux setting wires Claude Code’s experimental Agent Teams feature directly into tmux panes — no custom orchestration needed.
display-panes-time 2000 + pane-border-status top + pane-border-format " #{pane_index}: #S " gives you labeled, identifiable agent panes at a glance.

Relevance: MEDIUM — applies if/when we adopt Agent Teams. Our current variant model is heavier (launchd-managed long-running sessions), but this is the lighter weight pattern for ad-hoc parallel work within one machine.

8. Claude Code Multi-Agent Tmux Setup

URL: https://www.dariuszparys.com/claude-code-multi-agent-tmux-setup/ Author: Dariusz Parys (mirror/syndication of Karan Singh’s article)

Note: WebFetch returned identical content to entry #7. Likely a syndicated mirror; treat as duplicate.

Relevance: LOW — duplicate of #7. Captured for completeness only.

9. Agentic Operating System File Structure: A Practical Folder Layout ⭐

URL: https://www.mindstudio.ai/blog/agentic-operating-system-file-structure-context Author: MindStudio Team · Date: 2026-04-26

Thesis: AI work needs an “Agentic Operating System” — a deliberate folder structure with four layers (Rules / Context / Skills / Memory) that store business knowledge and accumulate learnings over time.

Practical advice:

Four-layer model: Rules (claude.md), Context (shared/per-task), Skills (skill.md files chaining workflows), Memory (accumulated learnings.md per skill).

Canonical folder structure:

/business-os/
  claude.md
  shared-brand-context.md
  /context/  (personas, brand-voice, product, competitors)
  /skills/{name}/
    skill.md
    examples.md
    learnings.md
  /outputs/  /drafts/ /approved/

Four operating patterns:
- Business Brain — one shared context file every skill references; prevents drift
- Skill Chaining — output of skill A becomes input of skill B
- Heartbeat — scheduled agents that run proactively, not reactively
- Learnings Loop — post-task review captures insights into per-skill learnings.md
Manage by goals, not terminals — route to the right skill based on outcome, not by manually orchestrating individual agents.

Novel/non-obvious:

Per-skill learnings.md files separated from examples.md — the difference matters. Examples are static reference, learnings are accumulated.
The agentic OS is contrasted explicitly against system prompts (static), KB collections (no process), and RAG (retrieval-only). It’s process + rules + context + accumulated learning, not any one of those.
Success indicators: output consistency = good context layer; measurable improvement over time = working memory layer. If neither: your learnings.md files are empty.

Relevance: HIGH — direct prior art for clean-desk-extract. The 4-layer model and the per-skill learnings.md pattern are the closest match to “what to put where” in our fleet OS design. The “manage by goals not terminals” framing aligns with our topic-router approach.

10. Run an AI Engineering Team in Paperclip With Heartbeats

URL: https://www.mindstudio.ai/blog/how-to-build-multi-agent-company-paperclip-claude-code Author: MindStudio Team · Date: 2026-03-29

Thesis: A 3-agent company (CEO + Engineer + QA) coordinated via file-based handoffs and a heartbeat scheduler can autonomously work through a product backlog with clean role separation.

Practical advice:

Three roles: CEO (reads backlog, writes specs, no code, file-IO only), Engineer (reads spec, writes code, execute_command allowed), QA (reads engineer output, writes tests, no source modification).
File-based handoff via /tasks/: CEO writes current_task.md → triggers Engineer. Engineer writes engineer_output.md → triggers QA. QA writes qa_results.md → CEO reads on next heartbeat.
Heartbeat config: heartbeat_interval: 30m typical (5m fast iter, 2h slow projects), max_concurrent_agents: 2, idle_behavior: wait.
command_allowlist: ["npm install", "npm run build", "npx"] to restrict engineer’s shell access.
After every 5 completed tasks, summarize completed work into a compact changelog — keeps context lean across cycles.
Lock file pattern to prevent heartbeat from starting a new cycle during long-running tasks: skip_if_file_exists: ./tasks/task.lock.

Novel/non-obvious:

The CEO using a higher-capability model (Opus) than the workers (Sonnet) — open-ended planning needs more reasoning than well-scoped implementation.
Backlog as ## TODO / ## IN PROGRESS / ## DONE markdown checkboxes — no DB needed, full git audit trail.
File-based comms is “simple and fully debuggable” — at any point you can open a file in /tasks/ and see exactly where each task sits.

Relevance: MEDIUM — confirms the file-based handoff pattern we already use (handoffs in vault, D1 read model). Heartbeat interval guidance and the model-tier-by-role pattern are applicable. Paperclip itself isn’t a fit since we don’t want to swap our wrapper for theirs.

11. Persistent Memory for Claude Agents (Managed Agents review)

URL: https://www.anothercodingblog.com/p/persistent-memory-for-claude-agents Author: Taylor Ortiz · Date: 2026-05-07

Thesis: Anthropic’s official Managed Agents product with memory stores is production-ready for persistent-agent use cases, but ships with sharp edges (no idempotent upsert, single-line descriptions, agent bash-escaping bugs) that require defensive operator-side tooling.

Practical advice:

Four primitives: Agent (versioned config), Environment (sandbox template), Session (transient run), Memory Store (workspace-scoped persistent file dir, audit-logged).
Critical prompt instruction: “Before researching a topic, check if you’ve already taken notes on it.” — without this, memory is theoretical.
Use the prebuilt agent_toolset_20260401 (bash/read/write/edit/glob/grep/web_search/web_fetch) — don’t roll your own.
Split into control plane (agents/environments/stores in YAML, git-versioned, applied via CLI) and data plane (sessions/events/app code reading IDs from env vars).
Use precondition: {type: "content_sha256", ...} on every memory update for optimistic concurrency — gets 409 conflict instead of silent overwrite.
One shared read-only “house knowledge” store + one per-user read-write store; sessions can mount up to 8 stores simultaneously.
If you call agents.create() more than once for the “same” agent, you’re using the wrong tool.

Novel/non-obvious:

The Session 3 catastrophe is gold: bash escaping bug → empty search result → agent concludes memory is empty → write instead of edit → destroys 7,285 bytes. Defensive prompting helps but doesn’t eliminate it. Agents need to be told “empty search result on a known-good index is suspicious, not authoritative.”
api_actor vs session_actor in audit logs — distinguishes operator-side mutations from agent-side. Critical for forensics.
Memory store description field rejects newlines (single-line only) while system_prompt accepts multi-line — undocumented inconsistency.
Web search results show as empty arrays in the event stream despite the agent using them internally — can’t log URLs without agent citation.

Relevance: MEDIUM — we’re not on Managed Agents (we run Claude Code with custom wrappers + D1), but the patterns are transferable: optimistic concurrency on memory writes, the api_actor/session_actor distinction for our actor_id columns, the “search-result-empty might be wrong” failure mode.

12. Multi-Agent Orchestration — Agentic Systems Book Ch.10

URL: https://gerred.github.io/building-an-agentic-system/second-edition/part-iv-advanced-patterns/chapter-10-multi-agent-orchestration.html Author: Gerred Dillon

Thesis: A reference taxonomy of multi-agent decomposition (Functional/Spatial/Temporal/Data-driven) × coordination (Pipeline/MapReduce/Consensus/Event-driven) patterns with the engineering primitives (file locks, tool registries, retry/fallback) to make them production-grade.

Practical advice:

Decomposition selection: Functional for multi-domain features, Spatial for refactoring across many files, Temporal for migrations (analyze→prep→migrate→verify), Data-driven for batch processing.
Coordination patterns: Pipeline (simple, low fault tolerance), MapReduce (high throughput, needs careful map/reduce design), Consensus (3 agents, requiredAgreement=2, falls back to arbitrator — for security/production-critical work), Event-driven (real-time coordination).

Tool tier presets:

ANALYSIS_TOOLS     = [read, grep, glob, list]
MODIFICATION_TOOLS = ANALYSIS + [edit, create, delete]
EXECUTION_TOOLS    = MODIFICATION + [bash]
DEFAULT_SUBAGENT   = [read, edit, grep]

File-lock registry to prevent two agents editing the same file. beforeFileEdit hook acquires lock, throws if held.
MAX_CONCURRENT_AGENTS cap. Exponential backoff retry with feedback (“previous attempt failed with X, try different approach”).
Implementation roadmap: 8 weeks split into Foundation / Specialization / Advanced Coordination / Production Hardening.

Novel/non-obvious:

Spatial decomposition with dependency grouping — group files by import/call dependency before assigning to agents, so each agent gets a self-consistent subset.
Resource budget allocation: model-tier selection (premium/standard/efficient) chosen per-task based on critical-path detection.
Consensus arbitrator pattern: 3 agents → group by similarity → if no group hits agreement threshold, spawn a 4th arbitrator that reads all proposals.
Reported metrics (single vs multi-agent): completion 65→87%, time 45→28min, quality 7.2→8.8.

Relevance: HIGH — the most rigorous of the orchestration posts. The decomposition × coordination matrix is the cleanest framework I’ve seen for routing fleet work. Tool-tier presets and file-lock pattern are directly adoptable.

13. Multi-agent orchestration for Claude Code in 2026

URL: https://shipyard.build/blog/claude-code-multi-agent/ Author: Shipyard Team · Date: 2026-03-18

Thesis: Three orchestrators (Agent Teams, Gas Town, Multiclaude) follow the same coordinator+subagents pattern; choose by team-vs-solo and review-vs-autoMerge fit; all are expensive and experimental.

Practical advice:

Agent Teams (official, Claude Code v2.1.32+): one session as “team lead,” teammates message each other directly via shared task list. Enable with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: "1". Shift+Down cycles teammates.
Gas Town (Steve Yegge, brew install gastown): “Kubernetes for AI agents” with a “mayor” hierarchy. Better for solo + many parallel agents.
Multiclaude (Dan Lorenc, go install ...multiclaude/cmd/multiclaude@latest): Brownian-ratchet philosophy — “as long as CI tests pass, every PR gets merged.” “Singleplayer” auto-merges, “multiplayer” requires teammate review. Better for teams.
Steve Yegge runs 3 concurrent Claude Max accounts to support his parallel agents — anticipate rapid usage limit consumption.
Prompt more technically; fewer chances to redirect misinterpreting agents at scale.
Validate in ephemeral environments (Shipyard’s pitch) — agents pull logs, run tests, iterate independently.

Novel/non-obvious:

Agent Teams vs. Subagents table: subagents report to main only; teammates message each other directly. Different token cost profile too (each teammate = separate instance = high cost).
Brownian ratchet as a merge philosophy — counterintuitive but Multiclaude has shipped real production code on it.

Relevance: MEDIUM — Agent Teams is the first-party path forward; worth tracking. Gas Town/Multiclaude are external alternatives we don’t need. The “3 Max accounts” tell is consistent with our usage-pacing concerns.

14. How I Finally Sorted My Claude Code Memory ⭐

URL: https://www.youngleaders.tech/p/how-i-finally-sorted-my-claude-code-memory Author: John Conneely · Date: 2026-03-18

Thesis: A flat memory file becomes another bloated CLAUDE.md; the fix is a structured ~/.claude/memory/ (global) + ~/.claude/projects/{p}/memory/MEMORY.md (project) split, with strict separation of routing rules (in CLAUDE.md) from learnings (in memory files), backed by a PreToolUse hook that survives in-session compaction and subagent spawning.

Practical advice:

Auto Memory shipped in Claude Code v2.1.59 on 2026-02-26. Check with claude doctor.

Structure:

~/.claude/memory/
  memory.md          (index, read at session start)
  general.md         (cross-project conventions)
  tools/{tool}.md    (Snowflake, Atlassian, Slack)
  domain/{name}/     (product/project/feature knowledge)

Routing rules go in CLAUDE.md (loads in full), NOT in MEMORY.md (only first 200 lines load). Burning 20 lines of MEMORY.md on routing = 10% of your budget gone.
Domain Knowledge Lifecycle: Staging (in domain/{name}/) → Promotion (package as plugin/skill) → Pointer (memory file becomes 3 lines pointing at the skill).
Standing CLAUDE.md instruction: at session start in any new project, check MEMORY.md exists; if not, create the standard scaffold.
PreToolUse hook (two files: .sh wrapper ~5ms gates .py script) injects project MEMORY.md + global memory.md index before the first tool call of every session, including new subagents.
CLAUDE_SESSION_ID does not exist in hooks — use os.getppid(). The PPID is stable within a session and new for each subagent.
Author’s CLAUDE.md went from 189 → 63 lines after restructuring; project files load on demand.

Novel/non-obvious:

The 200-line MEMORY.md cap means anything in there is competing with actual learnings. Treat MEMORY.md as a sacred budget.
Domain promotion to skill — when a memory file grows beyond a single domain’s worth of detail, promote it to a Claude skill (reusable plugin) and replace the memory entry with a 3-line pointer. This is the only escape from the budget pressure.
PreToolUse hook with PPID flag file (/tmp/claude-memory-loaded-{ppid}) gives per-process, once-per-session injection that survives compaction — critical insight, because session-start hooks don’t fire after in-session compaction.
Banned Atlassian MCP for unreliability + token bloat + corrupted registry; migrated to ACLI + direct REST. Recurring fleet lesson: not all MCPs are net-positive.

Relevance: HIGH — closest 1:1 match to our existing CLAUDE.md architecture (we already use imports, topic router, separate machine doc). The PreToolUse hook pattern + PPID flag pattern is directly adoptable. The “routing rules in CLAUDE.md, not MEMORY.md” rule is one we should audit our setup against.

Top 5 by Signal

#14 youngleaders-memory-sorted — most actionable, closest to our architecture, full hook code with the PPID insight, plus the routing-rules-vs-learnings rule we can audit our setup against today. The Domain Knowledge Lifecycle (Staging → Promotion → Pointer) is a pattern we don’t currently formalize and should.
#9 mindstudio-agentic-os-folder-structure — the cleanest 4-layer model (Rules/Context/Skills/Memory) and the per-skill learnings.md pattern. “Manage by goals, not terminals” matches our topic-router approach. The Heartbeat + Learnings Loop patterns are blueprintable.
#2 milvus-memory-4-layers-5-limits — canonical reference for what Claude Code’s native memory actually does, drawn from the leaked source. Establishes the 200-line cap, grep-only retrieval, and KAIROS as ground truth instead of speculation. Anchor for all other memory discussions.
#12 gerred-multi-agent-orchestration — the most rigorous orchestration taxonomy. Functional × Spatial × Temporal × Data-driven decomposition × Pipeline × MapReduce × Consensus × Event-driven coordination matrix is reusable as a routing framework. Tool-tier presets and file-lock pattern are drop-in primitives.
#5 adolan-persistent-memory (claude-brain) — most complete production-grade implementation, with concrete numbers (1,321 sessions, 67k messages, <1ms FTS5). The six-hook lifecycle, pre/post-compact pair, scoring/tagging dimensions, and verify-at-retrieval pattern are all directly portable to our fleet. The “no DB over cloud sync — only project files” rule confirms our existing .claude-peers.db local-only stance.

Honorable mentions: #1 humanlayer for the “60 lines is enough” calibration target. #3 parreo for the “coordination not personality” reframing. #11 anothercoding for the optimistic-concurrency / actor distinction in the audit log.

Skip: #4 gonewx (mostly confirms what we know), #6 hboon and #7 ksingh (tmux ergonomics; useful but not new), #8 parys (duplicate of #7), #10 mindstudio-multi-agent-company (Paperclip not a fit), #13 shipyard (catalog of orchestrators, not patterns).