Phi Memory Prior Art: Is a Golden-Ratio Memory Governance Layer Actually Novel?

This post is adapted from a Deep Research pass on Phi Memory: the idea of using phi/golden-ratio thresholds and Fibonacci-style review cadence as a governance policy for long-term AI-agent memory. The narrow question was not “does agent memory exist?” It obviously does. The question was whether this particular framing — a portable memory-governance layer organised around phi/Fibonacci policies — has a defensible novelty angle.

Short answer: I found no public exact match for a phi/golden-ratio AI memory-governance system, but most of the non-mathematical pieces already exist elsewhere. The strongest position is therefore narrow: Phi Memory as a backend-agnostic governance layer for deciding what memory should be kept, compressed, archived, deleted, or proceduralised.

Update: Phi Memory now exists as a Hermes plugin

Since the original research note, I have built and pushed a working Phi Memory plugin for Hermes Agent. That matters because it moves the idea out of the “interesting category thesis” bucket and into something closer to a real implementation path: a plugin that can be installed into an existing Hermes setup and used to inspect, review, recall, compress, and govern the built-in memory files.

The plugin lives on the feature/phi-memory branch of my Hermes Agent fork. The current installer is intentionally curl-style, because the target user is someone who already has Hermes installed and wants to try Phi Memory without replacing their whole agent setup.

curl -fsSL https://raw.githubusercontent.com/alienfrenZyNo1/hermes-agent/feature/phi-memory/scripts/install-phi-memory.sh | bash

To force an update of already-copied plugin files:

curl -fsSL https://raw.githubusercontent.com/alienfrenZyNo1/hermes-agent/feature/phi-memory/scripts/install-phi-memory.sh | bash -s -- --force

To install into a non-default Hermes home:

curl -fsSL https://raw.githubusercontent.com/alienfrenZyNo1/hermes-agent/feature/phi-memory/scripts/install-phi-memory.sh | bash -s -- --hermes-home /path/to/.hermes

What the installer does

1. Requires an existing hermes CLI on PATH.
2. Clones the Phi Memory branch.
3. Copies only plugins/phi-memory/ into ~/.hermes/plugins/phi-memory/.
4. Enables the plugin with hermes plugins enable phi-memory.
5. Runs a smoke check with hermes phi-memory status --target memory.
6. Does not edit MEMORY.md or USER.md.

What the plugin currently exposes

The README describes Phi Memory as an optional Hermes plugin/add-on that provides golden-ratio memory governance for the built-in MEMORY.md and USER.md files. It is not a replacement memory provider backend. It layers review, scoring, recall, CLI and slash commands, a model tool, metadata sidecars, Fibonacci review scheduling, and optional deterministic write governance over the existing files.

Example CLI commands include:

hermes phi-memory status --target memory
hermes phi-memory review --target user
hermes phi-memory compress --target memory
hermes phi-memory compress --target memory --apply-safe
hermes phi-memory explain "User prefers concise deployment summaries" --target user
hermes phi-memory recall "deployment coolify" --target memory --include-session
hermes phi-memory dashboard --target memory
hermes phi-memory review-due --target memory
hermes phi-memory schedule --target memory
hermes phi-memory skills candidates --target memory

The plugin also registers a model tool named phi_memory with actions such as status, review, compress, explain, recall, dashboard, review_due, schedule, and skill_candidates.

The safety model is conservative

This is important: default compression is proposal-only. It does not mutate MEMORY.md or USER.md. The automatic apply path is deliberately narrow: --apply-safe may remove exact or normalised duplicates, trim whitespace, remove empty/broken fragments, and redact obvious sensitive values or .secrets paths. It does not use an LLM to rewrite memory, merge unrelated facts, or delete unique project facts.

Before any safe cleanup write, the plugin creates a timestamped backup beside the original file. That turns the original product-positioning claim in this article into a concrete design constraint: memory governance should be auditable and reversible where possible.

So the novelty assessment below still stands, but the product position is now sharper. Phi Memory is no longer just a proposed category. It is a Hermes plugin prototype for governed long-term memory hygiene, with a curl installer and a smoke-tested path into a real agent runtime.

The core finding

The strongest novelty claim is not “persistent memory for agents” and not “memory consolidation”. Those are already well explored. Current systems already do long-term storage, retrieval, summarisation, compaction, deduplication, decay, expiration, temporal invalidation, reflection, and skill extraction in various forms.

The more defensible claim is this:

Phi Memory is a memory-governance layer for AI agents.
It helps long-term memory stay useful by reviewing, consolidating, compressing, archiving, retiring, and proceduralising memories over time. It is designed to sit above existing memory backends and answer a different question from retrieval systems: should this memory still exist, and in what form?

That is meaningfully narrower than claiming to have invented agent memory. It also maps better to the direction the field is moving: from “how do I store and retrieve agent memory?” toward “how do I keep persistent memory accurate, safe, compact, useful, auditable, and reversible over time?”

What appears genuinely differentiated

The research did not find a mainstream public paper, product, patent, or framework that says, in effect: “we govern agent memory using golden-ratio thresholds such as 0.618, 0.809, and 0.95, combined with Fibonacci review intervals.”

There are close neighbours:

• Forgetting curves and spaced-repetition-like memory reinforcement.
• Importance scoring, recency, relevance, and confidence thresholds.
• Age-dependent decay and archival movement in patents and older lifecycle systems.
• Fibonacci-like decay in adjacent open-source memory tools.

But the exact combination of phi thresholds, Fibonacci review intervals, and explicit keep/compress/archive/delete/proceduralise governance was not found as a public exact match.

What is already anticipated

Most of the underlying mechanics are not novel individually. That matters for positioning. A serious Phi Memory pitch should not overclaim.

The systems Phi Memory must be compared against

The competitive set is broad. Some systems are memory stores. Some are context layers. Some are research prototypes. Some are governance or security papers. Phi Memory sits in the overlap.

Letta / MemGPT

Letta and MemGPT popularised an OS-like view of agent memory, separating in-context memory blocks from searchable archival memory and compacting older context when needed. That is strong prior art for tiered memory and compaction, but it is not the same as a cross-backend governance layer that audits memories after the fact.

Mem0

Mem0 is highly relevant because it focuses on extracting, consolidating, deduplicating, scoring, expiring, and retrieving memory. It already handles many memory-hygiene concerns inside an integrated memory engine. Phi Memory should therefore avoid sounding like “Mem0 with a different metaphor”. The difference has to be governance across backends, auditability, and explicit lifecycle decisions.

Zep / Graphiti

Zep and Graphiti are probably among the strongest production-grade analogues for temporal validity and governed context. They preserve historical state, invalidate outdated facts, merge evidence, and use temporal graphs to keep context fresher. Phi Memory’s distinction would be less “we know facts change” and more “we provide a portable policy engine that can govern memory wherever it lives”.

LangGraph, LangMem, and LlamaIndex

These frameworks already provide memory concepts, namespaces, background memory managers, fact extraction, memory blocks, summarisation, prioritisation, and truncation. They prove that memory management belongs in the agent stack. They also make it harder to claim broad novelty. Phi Memory has to be complementary: a governance plane rather than a replacement framework.

Academic memory systems

Generative Agents, MemoryBank, RMM, FSFM, Voyager, ProcMEM, ReMe, and Anything2Skill cover importance scoring, reflection, forgetting, memory refinement, and procedural skill conversion. That research makes the general lifecycle story well anticipated. The opportunity is packaging these concerns into an operational policy layer developers can actually plug into production agents.

The governance angle is the real category

The more interesting market category is not “AI memory database”. That space is already crowded with vector stores, graph memories, retrieval systems, context platforms, and framework-native memory tools.

A better category is one of these:

• AI agent memory governance
• LLM memory lifecycle management
• agent memory hygiene
• governed context layer
• persistent memory maintenance for AI agents
• memory consolidation and forgetting layer
• backend-agnostic agent memory policy API

That category asks a different set of questions from retrieval:

• Is this memory still true?
• Is it duplicated by a better memory?
• Should it remain pinned, be compressed, be archived, or be deleted?
• Should it be turned into a procedural skill?
• What evidence created it?
• When should it be reviewed again?
• Can a destructive memory action be audited or reversed?

That is a real problem. Agents accumulate cruft. They remember stale preferences. They keep outdated project facts. They overfit to temporary context. They preserve things that should have been procedures. They retrieve old state after the world has changed. A governance layer is the part that says memory has a lifecycle, not just a vector embedding.

How the phi/Fibonacci policy could be framed

The phi part is interesting, but it needs careful language. It should not sound mystical. The strongest framing is:

Phi/Fibonacci scheduling is a simple, memorable policy heuristic for memory review and compaction. It gives a structured cadence and threshold vocabulary, but it should be tunable, measurable, and replaceable.

Possible policy layers might look like this:

The important caveat: those thresholds need empirical feedback. If a simpler policy performs better, the product should allow it. The phi language can make the system memorable, but measurable outcomes make it trustworthy.

Risks and objections

The biggest objection is obvious: Phi Memory could be dismissed as a collection of known memory techniques with a golden-ratio wrapper. That objection is fair unless the architecture is genuinely governance-first.

There are four risks I would take seriously:

1. Overclaiming novelty. Do not claim to have invented agent memory, consolidation, forgetting, or procedural memory.
2. Decorative math. Phi thresholds must be useful policy defaults, not numerology.
3. Bad forgetting. Incorrectly retiring memories can damage continuity, safety, and user trust.
4. Category confusion. Buyers will ask whether Mem0, Zep, Letta, or LangMem already do this. The answer is “partly, but not as a portable governance layer.”

The safest product position

The strongest product order looks like this:

1. Best: backend-agnostic governance API or plugin.
2. Second-best: framework feature inside an agent stack.
3. Third-best: managed governance service for enterprise agent fleets.
4. Weakest: another standalone memory store.

The storage layer is crowded. The retrieval layer is crowded. The governance layer is less settled. That is where Phi Memory has the cleanest wedge.

Suggested positioning copy

If I were describing Phi Memory publicly, I would use something like this:

Phi Memory is a governance layer for long-term AI-agent memory. It reviews, consolidates, compresses, archives, retires, and proceduralises memories over time, using explicit lifecycle policies and optional phi/Fibonacci-inspired review thresholds. It works above existing memory backends and focuses on the question retrieval systems usually skip: should this memory still exist, and in what form?

That is specific enough to be differentiated, but careful enough not to overclaim.

Bottom line

No public exact match was found for a phi/golden-ratio AI agent memory-governance system. But the general ingredients — persistent memory, compaction, decay, stale detection, deduplication, reflection, and procedural skill extraction — are all substantially anticipated.

The novelty case is therefore narrow and practical: Phi Memory as a governance-first, backend-agnostic lifecycle layer with an explicit phi/Fibonacci policy engine.

That is a plausible wedge. The Hermes plugin is the first concrete implementation step: enough to install, inspect, smoke-test, and start measuring, but still intentionally conservative about automatic memory mutation.