The operator reports accepted deployment on 1.14.72 / 612dc458.
Deployment receipt rec_fba7350aa0b4 records successful installation, binding
refresh and health checks, with active RPC and matching current/target releases.
Nightly ref_d6eb0f6e9c6f ran 02:15:05–02:23:40 on October 13, 2026
(Asia/Shanghai) and exited 0 with no failed steps.
Controlled memory checks passed 7 of 8 cases. The failed known-item case returned no final records. Its completed native trace shows an available SQLite source without fallback: the expected target was absent from the complete, untruncated source-returned window of 14 candidates and subsequent candidate stages. This excludes rejection of that target by the selector in this run. It does not establish an absent index entry; query generation, source matching and source-internal filtering remain distinct possible causes. Collection created five cases and found 164 existing cases, with no collection skips; all five new cases had empty candidates. Reviews total 365, with zero pending/open reviews and 0/3 formally accepted cases. Formal recall remains unaccepted. Nine evolution results each have zero candidate hypotheses; an applicable knowledge link for the current gap revision is still missing.
Version 1.14.71 repairs durable-memory input filtering, role parsing, authoritative source binding and ordering of already related states, with reference-only extraction diagnostics. A participant's small 1.14.69 Hermes readback reported retained sources but two empty memory queries. Their exact scope/source/stage binding and recovery remain unverified. Successful deployment and nightly execution do not certify these queries, model factual truth or team recall quality.
Version 1.14.72 adds a private, single-target native trace, now observed in the supplied controlled readback. It records actual stage presence and target-specific drops; missing observations remain unknown. The original query, case ID, expected record, selector, grounding and thresholds stay unchanged, with no extra search, record read or candidate injection. Query-generation metadata contains only field, length and truncation. The new trace does not backfill 1.14.71 membership, determine a historical production query type or certify recovery or formal quality.
Mainline 1.14.74 repairs the October 13 business-closure audit: trusted host identity, recoverable Hermes capture and delivery evidence, formal acceptance summaries, negative capability evidence and protected patch feedback, complete archived-payload backups, and idempotent knowledge/persona processing. Review coverage is resumable, Chinese query features retain privacy checks, and ordinary memory evaluation follows the configured runtime. Long-query term selection now covers the full question within existing bounds; ambiguous identity windows do not certify uniqueness. Grounding, label trust, release authority and the v5 three-case floor remain required. These source repairs do not certify a production deployment, recovery of the older controlled miss, or team-wide recall quality.
eimemory is a local-first memory and evidence-gated learning runtime for long-running AI agents. It provides:
- Durable memory: Store and retrieve agent experiences, not just chat history
- Smart recall: Hybrid indexing using lexical, semantic, graph, quality, and recency signals
- Safe learning: Governance gates for autonomous improvement without unlimited authority
- Operations tooling: JSONL records, SQLite projections, authenticated RPC, immutable releases and systemd templates. Deployment health and business recall acceptance are separate checks.
- Teams building long-running AI agents that need persistent learning
- Organizations requiring safe, auditable agent self-improvement
- Projects using Codex, Hermes Agent, optional OpenClaw, eibrain or custom Python/RPC clients
- Anyone needing local-first agent memory with governance controls
| Aspect | Chat History | eimemory |
|---|---|---|
| What's stored | Messages only | Outcomes, corrections, incidents, learned rules |
| Retrieval | Linear, dump all | Hybrid recall, scoped, ranked by relevance |
| Learning | None (or external) | Built-in governance loops |
| Authority | Not applicable | Tiered (L0-L3), safe by default |
| Storage | Ephemeral | Persistent, indexed, analyzable |
The runtime includes immutable releases, systemd templates, health checks, rollback and audit evidence. Readiness must be assessed for the actual workload, release, scope and host channels.
The earlier version-identified production run was 1.14.57 / eab88240. Deployment and
nightly execution succeeded; known-item smoke passed 10/10. Formal business
recall acceptance did not pass because qualifying evidence was incomplete.
Memory evaluation had no dataset, nine evolution items awaited hypotheses and
model review was unavailable. See receipt-based acceptance status.
The later reported 1.14.58 / 534bb2f0 receipt ref_4cc83efb2f5d failed at
research_closure_review. Detailed records report
research_review_llm_unconfigured: the managed review route was missing.
The earlier deployment attempt was 1.14.64 / f61487e2: the release link
switched, installer and binding refresh exited 0, but the final receipt has
ok=false, health_exit_code=1 and TimeoutError. Nightly did not start.
At that failed attempt, health and the timeout's cause were unverified.
Mainline 1.14.65 bounds storage/retrieval health snapshot waits, isolates caches
by runtime and refuses readiness when storage status cannot be checked;
it has no reported production acceptance.
An earlier completed nightly is 1.14.63 / 4fbcbbc9:
deployment receipt acceptance and service checks passed at that time, and the
October 11 nightly succeeded with no failed steps. Smoke passed 10/10, with
error rate 0.00 and hit@1 / hit@5 both 1.00. Formal recall remains 0/15;
321 reviews produced zero passes and zero pending conclusions. The memory
benchmark has zero retrieval cases, and all nine evolution results have zero
candidate hypotheses. The formal gate remains blocked by
recall_quality_evidence_incomplete.
Version 1.14.63 repairs digest identity collisions and preserves diagnostic
IDs/counts. The new aggregate smoke result supports smoke recovery; it does not
identify the historical loss stage or certify natural-query quality.
Since 1.14.60, research review automatically discovers installed Hermes and reads its current
review provider/model when no explicit command is set. It also retains the
1.14.59 durable failure diagnostics and deployment preflight. Production acceptance still
requires verified evidence. No blanket production-quality or L5 claim follows
from installation, tests or service health.
Install from a reviewed source checkout:
git clone https://github.com/darrowz/eimemory.git
cd eimemory
python -m venv .venv
source .venv/bin/activate
python -m pip install -e .For reproducibility, select an exact reviewed commit before installing. Use
immutable releases for production and verify the installed
package version with python -c "from eimemory import __version__; print(__version__)"
and deployed commit identity through RPC health.
Python 3.11 or higher.
eimemory initThis creates the local JSONL and SQLite storage structure.
eimemory has zero runtime dependencies by default. Optional features may require additional packages (specified in [project.optional-dependencies] in pyproject.toml).
# Add general memories
eimemory ingest "Remember concise replies" --title "Concise reply style"
# Ingest papers/URLs
eimemory paper ingest --url https://example.com/paper --title "Example Paper"
# Run knowledge intake pipeline
eimemory intake run --source-kind paper --limit 10# Retrieve relevant context for a query
eimemory recall "how should this agent reply?"
# Get quality statistics
eimemory quality statsMemory and evidence bind to an exact owner tuple: tenant_id, agent_id,
workspace_id, and user_id, with source and visibility policies. Project
separation can be represented by workspace identity; it is not an additional
implicit hierarchy. Host adapters also retain separate channel authority.
A query must use the intended owner/source/channel context; scopes do not grant
cross-user or cross-channel access.
Evaluation in eimemory:
- Recall quality: Did the right memory get retrieved?
- Living memory: Is retrieved memory still accurate?
- Regression cases: Do recalled rules still work?
- Task outcomes: Did memory help achieve the goal?
- Capability evidence: Did one exact revision/provider binding pass its sealed catalog case with independently persisted evidence?
Executable evaluators are loaded only from installed Python entry points in
eimemory.capability_catalog.bootstrap.v1. The bootstrap accepts trusted Python
callables and typed CatalogCase descriptors, then seals the catalog. YAML,
JSON, database rows, and adapter advertisements cannot register executable code.
An absent catalog leaves ordinary memory available but blocks dynamic evaluation
with catalog_not_configured.
The maintained Hongtu build ships its catalog from the main eimemory package.
It evaluates scoped recall independently for Hermes and OpenClaw; it does not
activate the other seeded capabilities without their own bindings and evidence.
L5 v3 reports four independent axes: loop maturity, capability readiness,
adapter readiness, and deployment assurance. ready means the selected profile
has no blocking gap under those contracts. It does not mean every discovered
capability is active, every original criterion has fresh production proof, or
the loop has reached compounding.
The historical 2026-08-22 Hongtu reference state was ready at loop stage evolving:
Hermes and OpenClaw recall bindings are reliable, and a canonical knowledge
link/hypothesis/evaluation/feedback chain is live. A fresh production
code-evolution transaction with regression, commit, push, deployment, and
rollback evidence remains outstanding. See
the dated closure record.
That historical assessment does not certify the latest release or the formal
business recall gate. See current acceptance status.
eimemory learn cycle --dry-run # See what would be learned
eimemory learn cycle # Apply learning with gates
eimemory learn ledger --limit 50 # View learning history
eimemory learn dashboard # Visualize learning progressVersion 1.14.69 connects three governed paths: a controlled recall baseline from existing authorized records after an explicitly successful empty replay; tool-free Hermes review of approved canonical knowledge against an exact capability gap; and official Hermes v2 maintenance proposals under registered bounds and a trusted machine policy. Missing evidence or authority stays blocked. Isolated evaluation and the existing transaction owner govern permitted effects and recovery. A known or user-reported problem cannot certify autonomous discovery, L5 or formal business recall. See the maintenance contract.
Governance gates ensure safe learning:
- Evidence gate: Learning must be backed by data
- Health gate: Learned rules must pass health checks
- Canary gate: Small rollout before full deployment
- Rollback gate: Previous behavior available if issues occur
| Tier | Examples | Authority |
|---|---|---|
| L0 | Records, reports, dashboards | Read-only analysis |
| L1 | Memory rules, playbooks, eval fixtures | Local low-risk changes |
| L2 | Gated rollout | Requires evidence + eval + health + canary checks |
| L3 | External sends, spending, auth changes | Blocked by default, requires explicit adapter |
Use --dry-run to preview a CLI cycle. To stop scheduled work, disable the
specific timers enabled in your deployment; nightly and learning companion
timers are documented in the systemd guide.
A dry run of one command does not disable other running services. Deployment
machine policy separately controls automatic code apply, commit and deployment.
Follow the Deployment Guide and systemd installation instructions. Install an exact commit into an immutable release, configure credentials outside the checkout, and start the user services. Then verify release identity, channel write/readback, managed services and the task-specific persisted acceptance receipts.
deploy/install_immutable_release.sh <full-40-character-commit>
/opt/eimemory/current/.venv/bin/python -c "from eimemory import __version__; print(__version__)"
curl -fsS http://127.0.0.1:8091/healthThose checks verify installation and health. They do not replace the formal recall gate or memory benchmark.
Persist the runtime root outside the container and supply credentials through the deployment environment. The maintained production runbook uses Linux immutable releases and user systemd services; this repository does not provide an equivalent container acceptance runbook.
The maintained store uses local JSONL records and SQLite. Optional PostgreSQL/ pgvector serves retrieval projections; it does not replace the authoritative record or capability-domain storage. See architecture and vector candidates.
Check:
- Run
eimemory doctorfor diagnostics - Verify memories exist:
eimemory recall "test" - Check scoping settings match your query
- Review quality stats:
eimemory quality stats
An empty current candidate list alone cannot establish recall quality. The
model may already have received those memories, or an earlier decision may
still be in flight. not_used after injection means delivered without recorded
actual use. Closed never-injected items without host used/rejected feedback
remain eligible under the existing rule.
Since 1.14.66, new decisions record the removed candidate IDs and qualifying historical item references with their observed states. Old count-only records cannot identify those links retrospectively. An empty-case automatic review completes as not evaluable without a label; it does not certify correct no-answer. See the diagnostic contract and the four-record readback.
Known-item smoke verifies that fixed entries can be found. Formal acceptance
requires qualifying natural production cases, trusted labels, exact source/scope
boundaries, release authorization and unchanged ranking/noise standards. The
historical 1.14.63 run has 0/15 accepted cases and zero passing reviews out of 321,
with zero pending conclusions. Its smoke passed 10/10 and nightly succeeded,
but the formal gate remains blocked by recall_quality_evidence_incomplete.
Smoke recovery does not supply the missing formal evidence. The later detailed
1.14.66 readback reports 0/3 accepted cases and zero passes out of 343 reviews.
The latest 1.14.72 readback still reports 0/3 formal cases and 365 reviews with
no pending/open work. Its controlled baseline passed seven of eight cases;
the failed target was absent from the source's complete 14-candidate returned
window, before the selector. This excludes selector grounding rejection of that
target in this run, without identifying the upstream cause. Generated questions
cannot supply the missing formal labels.
Scanned reviews can include previously captured cases. Repeating unchanged evidence does not restore a missing decision or provide independent proof of actual use. A large review total therefore does not establish that new usable production cases arrived. Nine new semantic observations likewise cannot stand in for nine newly collected production cases.
The 1.14.67 report ref_5df3562505ca and original logs lack
production_recall_collection, so that batch's new/existing counts and exact
new IDs remain unknown. Mainline 1.14.68 retains bounded collection and
same-run review diagnostics to follow a new case through its recorded signals,
semantic verdict and native receipt. Missing signals remain unknown, and
existing acceptance is distinguished from a newly created receipt. See
the diagnostic contract.
This repair does not guarantee the first trusted case or relax approval rules.
The earlier 1.14.69 collection reported four new cases and 156 existing cases,
with empty candidates and non-certifying no_candidate_refs conclusions.
The earlier 1.14.71 collection reported four new cases and 160 existing cases.
The latest 1.14.72 collection reports five new cases and 164 existing cases,
with no collection skips; all five new cases have empty candidates.
The review summary has no pending/open work, but formal acceptance remains 0/3.
Traceable collection counts do not establish successful natural recall or
independently justified no-answer.
No participant-level acceptance is established by those checks. The operator reports that earlier controlled checks for 鸿泰、鸿欣、小马哥 returned empty results, but their actual session identities and environments were not fully verified. This does not establish a current fault for any participant. Verify each real Feishu conversation's effective identity and host, then test natural questions about known memories, no-answer near neighbors, cross-member permission boundaries and authorized source readback. See team recall acceptance.
Conversation capture, durable-memory extraction and recall delivery are separate stages. Healthy queuing and a retained L0 source do not prove that the source was admitted to extraction, produced an L1 candidate, survived filtering or was queried under the participant's actual authorized scope. Here L0/L1 name data stages, rather than governance authority tiers.
Version 1.14.71 repairs mixed-statement filtering, formatted role boundaries,
current source binding and atomic observation-time ordering. Reference-only
extraction diagnostics distinguish actual input/model/filter/write outcomes;
old atom counts cannot establish those stages retrospectively. These changes do
not independently verify every model-derived fact or bulk replay historical
NoMemory records. The small 1.14.69 participant readback lacks exact
source/scope/stage binding, so it cannot be assigned to a particular defect or
used as a team result. See
capture and extraction.
Cases provide query observations; trusted labels identify the relevant records used to score them. Mainline 1.14.64 changes the floor from 15 to 3 at the operator's explicit request. This is an engineering prerequisite, not a statistical accuracy guarantee. Every eligible case already needs at least one accepted label, so the two floors do not represent six independent observations. Extra labels cannot replace missing or unlabelled cases. Current policy v5 covers observed dataset hosts with no fixed client quota; Hermes-only use does not require unused-client samples. Team member coverage and cross-client product coverage must still be assessed separately. See evidence count interpretation.
Existing authorized memories can supply the positive targets and source readbacks. Three positive relevance labels can support the case minimum; no-answer neighbors and cross-member permissions need additional contrast probes and their own outcomes. Generated paraphrases remain controlled acceptance, not natural-production cases. Member scopes cannot be pooled to fill another user's gate. See using existing memory.
The diagnostic metric counts cases that return items while missing their expected
item, plus erroneous returns on no-answer cases, divided by all evaluated cases.
For ref_a2dee7107fde, the operator read back one known-item miss with results
and zero no-answer returns, over ten cases. The failed case returned two items
and matched neither to its expectation. This is a measured gate violation, but
it does not establish natural-query or no-answer quality. The ≤0.05 threshold
remains unchanged. Version 1.14.63 retains expected record IDs and explicit
counts in newly persisted diagnostic reports; older receipts are not rewritten.
It also repairs deduplication that merged different dated digest pages sharing
a summary prefix. Local native regression checks retain the original target.
The later 1.14.63 readback reports smoke 10/10 and error rate 0.00, without a
per-case identity comparison or the historical failed run's stage trace.
Formal business recall remains unaccepted.
From 1.14.61, each scanned case receives a durable pass or fail conclusion. Unavailable semantic review or insufficient independent signals means fail, with recorded reasons and no trusted relevance label. Original captures remain active; new evidence can trigger automatic reevaluation. A completed review does not by itself meet the business gate or release-authorization requirement.
memory_eval_dataset_empty means no usable retrieval benchmark ran. A separate
code or capability case pass cannot substitute for memory evaluation. That error
was supplied for the earlier 1.14.57 run. The October 11 1.14.61 readback
reports replay_dataset, zero retrieval cases and memory_eval_dataset_empty.
The historical 1.14.63 run still has zero retrieval cases with the same empty-dataset
reason; its dataset-source field was not supplied. The later 1.14.66 readback
also reports zero retrieval cases from replay_dataset. The later 1.14.69
readback supplies a controlled baseline: 10 samples, nine passes and one
known_item_missing with zero returned records. This is an executed controlled
check, not formal memory acceptance or proof of correct no-answer.
The earlier 1.14.71 controlled run passed 8/9. Its empty known-item case reports an available source, no fallback and rejection of all 14 selector inputs for grounding; whether the expected record was among them is unknown. These new measurements do not reconstruct the earlier miss or justify relaxing grounding.
The latest 1.14.72 run passed 7/8. Its completed, untruncated target trace finds the expected record absent from the SQLite source-returned 14-candidate window and subsequent candidate stages. This excludes that target's selector rejection in this run, but does not prove a missing index entry or distinguish query generation from source matching/internal filtering. The old 1.14.71 membership remains unknown; neither run certifies formal memory quality.
From 1.14.69, an unconfigured replay that explicitly succeeded with zero retrieval
cases can derive controlled known-item checks from current authorized memories.
The actual runtime recall path is measured, but
controlled_benchmark_passed_threshold=true never changes that path's
memory_benchmark_accepted=false. Configured input failures, missing authority
and unconfirmed replay success cannot be concealed by this fallback. It creates
neither natural-production labels nor correct-no-answer evidence. See
controlled baselines.
Supply an
independent retrieval dataset and inspect its persisted verdict. Mainline repairs
keep catalog execution separate and persist explicit not-run receipts; those
repairs began in 1.14.58; mainline 1.14.59 also preserves research-review failure
reasons in durable nightly receipts. Formal recall quality remains unaccepted. See evaluation.
It combined codes omitted from the safe diagnostic list. Follow-up readback of the per-case receipts found capture boundary rejection (10), no matching authoritative capture decision (186) and semantic items not delivered (5), totaling 201 and matching the summary, with 201 distinct affected receipts. Missing matching decisions can reflect lost evidence or mismatched boundaries; the code alone does not prove pruning or algorithm failure. Version 1.14.62 preserves those exact codes and other fixed review failure reasons, while continuing to redact arbitrary text. The later 1.14.62 summary confirms direct counts of 10, 186 and 6 for those codes; the historical 1.14.61 third count remains 5. The initial 1.14.63 readback does not supply its review reason counts.
No. With neither research-specific nor shared command configured, version 1.14.60 discovers the service user's Hermes installation and follows its current provider/model configuration. Explicit commands and protected installation/profile overrides remain supported. Invalid runtime contracts, model mismatch and failed completion keep the review unavailable. See automatic Hermes review.
# Diagnose learning pipeline
eimemory learn cycle --dry-run
# Check ledger for recent activity
eimemory learn ledger --limit 10
# View service logs
journalctl --user -u eimemory-nightly.service -n 50# Check health endpoint
curl http://127.0.0.1:8091/health
# Review logs
journalctl --user -u eimemory-rpc.service -n 100 --no-pager
# Run diagnostics
eimemory doctor --json- Review stored memories:
eimemory quality stats - Archive old memories if needed
- Consider scoping to reduce active set
- Check for circular dependencies in rules
Use the optional external bridge and systemd adapter guide. It exposes eight lifecycle hooks and a status tool through the configured external plugin path. OpenClaw is optional; an enabled but incomplete integration fails closed.
Codex uses hooks and MCP tools. Hermes uses its native memory provider plus the host hook bridge. Install a matching reviewed runtime and configure authenticated RPC outside tracked plugin files. Each host retains its own channel authority. Trusted task receipts require an operator-separated producer profile; recall alone cannot mint that evidence. See operations.
eimemory's core runtime is framework-agnostic. HTTP/RPC interfaces allow integration with:
- LangChain
- LlamaIndex
- Custom agent frameworks
See integration architecture for an overview.
eibrain is the cognition layer that uses eimemory for context. eimemory handles memory, while eibrain handles decision-making.
Depends on memory volume:
- Small agents: MB range
- Medium deployments: GB range
- Large systems: Depends on indexing strategy
Use eimemory quality stats to monitor growth.
Measure the actual workload, memory size, source/scope policy, payload budget, embedding route and host timeout. The earlier 1.14.57 fixed-item smoke had P95 340.8 ms, but it is not a general latency guarantee or a natural-query benchmark. See evaluation and acceptance status.
Yes, through:
- Scoping (reduce search space)
- Index strategy tuning
- Memory archival
- Custom retrieval adapters
Open a GitHub Issue with:
- Steps to reproduce
- Expected vs actual behavior
- Python version and OS
- Relevant logs
Absolutely! See CONTRIBUTING.md for guidelines.
See L5 Roadmap for planned features and improvements.
Didn't find your answer? Open an issue or check the documentation.