audrey 0.21.0 → 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +238 -0
- package/LICENSE +21 -21
- package/README.md +281 -33
- package/SECURITY.md +30 -0
- package/benchmarks/adapter-kit.mjs +20 -0
- package/benchmarks/adapter-self-test.mjs +166 -0
- package/benchmarks/adapters/example-allow.mjs +28 -0
- package/benchmarks/adapters/mem0-platform.mjs +267 -0
- package/benchmarks/adapters/registry.json +51 -0
- package/benchmarks/adapters/zep-cloud.mjs +280 -0
- package/benchmarks/baselines.js +169 -0
- package/benchmarks/build-leaderboard.mjs +170 -0
- package/benchmarks/cases.js +537 -0
- package/benchmarks/create-conformance-card.mjs +139 -0
- package/benchmarks/create-submission-bundle.mjs +176 -0
- package/benchmarks/dry-run-external-adapters.mjs +165 -0
- package/benchmarks/guardbench.js +1035 -0
- package/benchmarks/output/adapter-self-test/guardbench-adapter-self-test.json +50 -0
- package/benchmarks/output/external/guardbench-external-dry-run.json +69 -0
- package/benchmarks/output/external/guardbench-external-evidence.json +56 -0
- package/benchmarks/output/guardbench-conformance-card.json +63 -0
- package/benchmarks/output/guardbench-manifest.json +414 -0
- package/benchmarks/output/guardbench-raw.json +1171 -0
- package/benchmarks/output/guardbench-summary.json +1981 -0
- package/benchmarks/output/leaderboard/guardbench-leaderboard.json +93 -0
- package/benchmarks/output/leaderboard/guardbench-leaderboard.md +7 -0
- package/benchmarks/output/submission-bundle/guardbench-conformance-card.json +63 -0
- package/benchmarks/output/submission-bundle/guardbench-manifest.json +414 -0
- package/benchmarks/output/submission-bundle/guardbench-raw.json +1171 -0
- package/benchmarks/output/submission-bundle/guardbench-summary.json +1981 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-adapter-registry.schema.json +69 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-adapter-self-test.schema.json +156 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-conformance-card.schema.json +184 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-external-dry-run.schema.json +74 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-external-evidence.schema.json +108 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-external-run.schema.json +160 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-leaderboard.schema.json +179 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-manifest.schema.json +213 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-publication-verification.schema.json +47 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-raw.schema.json +164 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-submission-manifest.schema.json +151 -0
- package/benchmarks/output/submission-bundle/schemas/guardbench-summary.schema.json +228 -0
- package/benchmarks/output/submission-bundle/submission-manifest.json +131 -0
- package/benchmarks/output/submission-bundle/validation-report.json +31 -0
- package/benchmarks/output/summary.json +2354 -0
- package/benchmarks/perf-snapshot.js +304 -0
- package/benchmarks/perf.bench.js +161 -0
- package/benchmarks/public-paths.mjs +78 -0
- package/benchmarks/reference-results.js +70 -0
- package/benchmarks/report.js +259 -0
- package/benchmarks/run-external-guardbench.mjs +281 -0
- package/benchmarks/run.js +682 -0
- package/benchmarks/schemas/guardbench-adapter-registry.schema.json +69 -0
- package/benchmarks/schemas/guardbench-adapter-self-test.schema.json +156 -0
- package/benchmarks/schemas/guardbench-conformance-card.schema.json +184 -0
- package/benchmarks/schemas/guardbench-external-dry-run.schema.json +74 -0
- package/benchmarks/schemas/guardbench-external-evidence.schema.json +108 -0
- package/benchmarks/schemas/guardbench-external-run.schema.json +160 -0
- package/benchmarks/schemas/guardbench-leaderboard.schema.json +179 -0
- package/benchmarks/schemas/guardbench-manifest.schema.json +213 -0
- package/benchmarks/schemas/guardbench-publication-verification.schema.json +47 -0
- package/benchmarks/schemas/guardbench-raw.schema.json +164 -0
- package/benchmarks/schemas/guardbench-submission-manifest.schema.json +151 -0
- package/benchmarks/schemas/guardbench-summary.schema.json +228 -0
- package/benchmarks/snapshots/perf-0.22.2.json +123 -0
- package/benchmarks/snapshots/perf-0.23.0.json +123 -0
- package/benchmarks/validate-adapter-module.mjs +104 -0
- package/benchmarks/validate-adapter-registry.mjs +134 -0
- package/benchmarks/validate-adapter-self-test.mjs +96 -0
- package/benchmarks/validate-guardbench-artifacts.mjs +343 -0
- package/benchmarks/verify-external-evidence.mjs +296 -0
- package/benchmarks/verify-publication-artifacts.mjs +286 -0
- package/benchmarks/verify-submission-bundle.mjs +167 -0
- package/dist/mcp-server/config.d.ts +5 -4
- package/dist/mcp-server/config.d.ts.map +1 -1
- package/dist/mcp-server/config.js +6 -8
- package/dist/mcp-server/config.js.map +1 -1
- package/dist/mcp-server/index.d.ts +281 -23
- package/dist/mcp-server/index.d.ts.map +1 -1
- package/dist/mcp-server/index.js +1186 -82
- package/dist/mcp-server/index.js.map +1 -1
- package/dist/src/action-key.d.ts +9 -0
- package/dist/src/action-key.d.ts.map +1 -0
- package/dist/src/action-key.js +49 -0
- package/dist/src/action-key.js.map +1 -0
- package/dist/src/adaptive.d.ts.map +1 -1
- package/dist/src/adaptive.js +8 -6
- package/dist/src/adaptive.js.map +1 -1
- package/dist/src/affect.d.ts +4 -1
- package/dist/src/affect.d.ts.map +1 -1
- package/dist/src/affect.js +14 -12
- package/dist/src/affect.js.map +1 -1
- package/dist/src/audrey.d.ts +57 -4
- package/dist/src/audrey.d.ts.map +1 -1
- package/dist/src/audrey.js +512 -65
- package/dist/src/audrey.js.map +1 -1
- package/dist/src/capsule.d.ts +2 -1
- package/dist/src/capsule.d.ts.map +1 -1
- package/dist/src/capsule.js +18 -8
- package/dist/src/capsule.js.map +1 -1
- package/dist/src/causal.d.ts.map +1 -1
- package/dist/src/causal.js +23 -5
- package/dist/src/causal.js.map +1 -1
- package/dist/src/confidence.d.ts.map +1 -1
- package/dist/src/confidence.js +3 -0
- package/dist/src/confidence.js.map +1 -1
- package/dist/src/consolidate.d.ts +1 -0
- package/dist/src/consolidate.d.ts.map +1 -1
- package/dist/src/consolidate.js +70 -54
- package/dist/src/consolidate.js.map +1 -1
- package/dist/src/controller.d.ts +94 -0
- package/dist/src/controller.d.ts.map +1 -0
- package/dist/src/controller.js +350 -0
- package/dist/src/controller.js.map +1 -0
- package/dist/src/db.d.ts.map +1 -1
- package/dist/src/db.js +181 -169
- package/dist/src/db.js.map +1 -1
- package/dist/src/decay.d.ts.map +1 -1
- package/dist/src/decay.js +62 -55
- package/dist/src/decay.js.map +1 -1
- package/dist/src/embedding.d.ts +2 -1
- package/dist/src/embedding.d.ts.map +1 -1
- package/dist/src/embedding.js +60 -22
- package/dist/src/embedding.js.map +1 -1
- package/dist/src/encode.d.ts +9 -2
- package/dist/src/encode.d.ts.map +1 -1
- package/dist/src/encode.js +25 -12
- package/dist/src/encode.js.map +1 -1
- package/dist/src/export.d.ts.map +1 -1
- package/dist/src/export.js +5 -3
- package/dist/src/export.js.map +1 -1
- package/dist/src/feedback.d.ts +35 -0
- package/dist/src/feedback.d.ts.map +1 -0
- package/dist/src/feedback.js +129 -0
- package/dist/src/feedback.js.map +1 -0
- package/dist/src/forget.d.ts.map +1 -1
- package/dist/src/forget.js +68 -60
- package/dist/src/forget.js.map +1 -1
- package/dist/src/fts.js +1 -1
- package/dist/src/fts.js.map +1 -1
- package/dist/src/hybrid-recall.d.ts +2 -1
- package/dist/src/hybrid-recall.d.ts.map +1 -1
- package/dist/src/hybrid-recall.js +41 -32
- package/dist/src/hybrid-recall.js.map +1 -1
- package/dist/src/impact.d.ts +47 -0
- package/dist/src/impact.d.ts.map +1 -0
- package/dist/src/impact.js +146 -0
- package/dist/src/impact.js.map +1 -0
- package/dist/src/import.d.ts +177 -1
- package/dist/src/import.d.ts.map +1 -1
- package/dist/src/import.js +235 -46
- package/dist/src/import.js.map +1 -1
- package/dist/src/index.d.ts +5 -1
- package/dist/src/index.d.ts.map +1 -1
- package/dist/src/index.js +3 -1
- package/dist/src/index.js.map +1 -1
- package/dist/src/interference.d.ts +5 -2
- package/dist/src/interference.d.ts.map +1 -1
- package/dist/src/interference.js +39 -32
- package/dist/src/interference.js.map +1 -1
- package/dist/src/introspect.js +18 -18
- package/dist/src/llm.d.ts.map +1 -1
- package/dist/src/llm.js +1 -0
- package/dist/src/llm.js.map +1 -1
- package/dist/src/migrate.d.ts.map +1 -1
- package/dist/src/migrate.js +21 -9
- package/dist/src/migrate.js.map +1 -1
- package/dist/src/preflight.d.ts +2 -1
- package/dist/src/preflight.d.ts.map +1 -1
- package/dist/src/preflight.js +66 -5
- package/dist/src/preflight.js.map +1 -1
- package/dist/src/profile.d.ts +23 -0
- package/dist/src/profile.d.ts.map +1 -0
- package/dist/src/profile.js +51 -0
- package/dist/src/profile.js.map +1 -0
- package/dist/src/promote.d.ts.map +1 -1
- package/dist/src/promote.js +8 -9
- package/dist/src/promote.js.map +1 -1
- package/dist/src/prompts.d.ts.map +1 -1
- package/dist/src/prompts.js +165 -136
- package/dist/src/prompts.js.map +1 -1
- package/dist/src/recall.d.ts +9 -6
- package/dist/src/recall.d.ts.map +1 -1
- package/dist/src/recall.js +204 -62
- package/dist/src/recall.js.map +1 -1
- package/dist/src/redact.d.ts +7 -1
- package/dist/src/redact.d.ts.map +1 -1
- package/dist/src/redact.js +94 -11
- package/dist/src/redact.js.map +1 -1
- package/dist/src/reflexes.d.ts +1 -0
- package/dist/src/reflexes.d.ts.map +1 -1
- package/dist/src/reflexes.js +3 -0
- package/dist/src/reflexes.js.map +1 -1
- package/dist/src/rollback.d.ts.map +1 -1
- package/dist/src/rollback.js +13 -8
- package/dist/src/rollback.js.map +1 -1
- package/dist/src/routes.d.ts +1 -0
- package/dist/src/routes.d.ts.map +1 -1
- package/dist/src/routes.js +251 -6
- package/dist/src/routes.js.map +1 -1
- package/dist/src/rules-compiler.d.ts.map +1 -1
- package/dist/src/rules-compiler.js +36 -6
- package/dist/src/rules-compiler.js.map +1 -1
- package/dist/src/server.d.ts +2 -1
- package/dist/src/server.d.ts.map +1 -1
- package/dist/src/server.js +42 -4
- package/dist/src/server.js.map +1 -1
- package/dist/src/tool-trace.d.ts.map +1 -1
- package/dist/src/tool-trace.js +42 -29
- package/dist/src/tool-trace.js.map +1 -1
- package/dist/src/types.d.ts +28 -1
- package/dist/src/types.d.ts.map +1 -1
- package/dist/src/ulid.d.ts.map +1 -1
- package/dist/src/ulid.js +52 -2
- package/dist/src/ulid.js.map +1 -1
- package/dist/src/utils.d.ts.map +1 -1
- package/dist/src/utils.js +8 -1
- package/dist/src/utils.js.map +1 -1
- package/dist/src/validate.d.ts +2 -0
- package/dist/src/validate.d.ts.map +1 -1
- package/dist/src/validate.js +77 -46
- package/dist/src/validate.js.map +1 -1
- package/docs/AUDREY_PAPER_OUTLINE.md +175 -0
- package/docs/MEMORY_BENCHMARKING.md +59 -0
- package/docs/PRODUCTION_BACKLOG.md +304 -0
- package/docs/paper/00-master.md +48 -0
- package/docs/paper/01-introduction.md +27 -0
- package/docs/paper/02-related-work.md +47 -0
- package/docs/paper/03-problem-definition.md +108 -0
- package/docs/paper/04-design.md +164 -0
- package/docs/paper/05-guardbench-spec.md +412 -0
- package/docs/paper/06-implementation.md +113 -0
- package/docs/paper/07-evaluation.md +168 -0
- package/docs/paper/08-discussion-limitations.md +61 -0
- package/docs/paper/09-conclusion.md +11 -0
- package/docs/paper/SUBMISSION_README.md +162 -0
- package/docs/paper/appendix-a-demo-transcript.md +114 -0
- package/docs/paper/arxiv-compile-report.schema.json +116 -0
- package/docs/paper/arxiv-source.schema.json +61 -0
- package/docs/paper/audrey-paper-v1.md +1106 -0
- package/docs/paper/browser-launch-plan.json +209 -0
- package/docs/paper/browser-launch-plan.schema.json +100 -0
- package/docs/paper/browser-launch-results.json +86 -0
- package/docs/paper/browser-launch-results.schema.json +66 -0
- package/docs/paper/claim-register.json +138 -0
- package/docs/paper/claim-register.schema.json +81 -0
- package/docs/paper/evidence-ledger.md +103 -0
- package/docs/paper/output/arxiv/README-arxiv.txt +8 -0
- package/docs/paper/output/arxiv/arxiv-manifest.json +41 -0
- package/docs/paper/output/arxiv/main.tex +949 -0
- package/docs/paper/output/arxiv/references.bib +222 -0
- package/docs/paper/output/arxiv-compile-report.json +24 -0
- package/docs/paper/output/submission-bundle/LICENSE +21 -0
- package/docs/paper/output/submission-bundle/README.md +533 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/adapter-self-test/guardbench-adapter-self-test.json +50 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/external/guardbench-external-dry-run.json +69 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/external/guardbench-external-evidence.json +56 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/guardbench-conformance-card.json +63 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/guardbench-manifest.json +414 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/guardbench-raw.json +1171 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/guardbench-summary.json +1981 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/leaderboard/guardbench-leaderboard.json +93 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/leaderboard/guardbench-leaderboard.md +7 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/submission-bundle/submission-manifest.json +131 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/submission-bundle/validation-report.json +31 -0
- package/docs/paper/output/submission-bundle/benchmarks/output/summary.json +2354 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-adapter-registry.schema.json +69 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-adapter-self-test.schema.json +156 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-conformance-card.schema.json +184 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-external-dry-run.schema.json +74 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-external-evidence.schema.json +108 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-external-run.schema.json +160 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-leaderboard.schema.json +179 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-manifest.schema.json +213 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-publication-verification.schema.json +47 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-raw.schema.json +164 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-submission-manifest.schema.json +151 -0
- package/docs/paper/output/submission-bundle/benchmarks/schemas/guardbench-summary.schema.json +228 -0
- package/docs/paper/output/submission-bundle/docs/AUDREY_PAPER_OUTLINE.md +175 -0
- package/docs/paper/output/submission-bundle/docs/paper/00-master.md +48 -0
- package/docs/paper/output/submission-bundle/docs/paper/01-introduction.md +27 -0
- package/docs/paper/output/submission-bundle/docs/paper/02-related-work.md +47 -0
- package/docs/paper/output/submission-bundle/docs/paper/03-problem-definition.md +108 -0
- package/docs/paper/output/submission-bundle/docs/paper/04-design.md +164 -0
- package/docs/paper/output/submission-bundle/docs/paper/05-guardbench-spec.md +412 -0
- package/docs/paper/output/submission-bundle/docs/paper/06-implementation.md +113 -0
- package/docs/paper/output/submission-bundle/docs/paper/07-evaluation.md +168 -0
- package/docs/paper/output/submission-bundle/docs/paper/08-discussion-limitations.md +61 -0
- package/docs/paper/output/submission-bundle/docs/paper/09-conclusion.md +11 -0
- package/docs/paper/output/submission-bundle/docs/paper/SUBMISSION_README.md +162 -0
- package/docs/paper/output/submission-bundle/docs/paper/appendix-a-demo-transcript.md +114 -0
- package/docs/paper/output/submission-bundle/docs/paper/arxiv-compile-report.schema.json +116 -0
- package/docs/paper/output/submission-bundle/docs/paper/arxiv-source.schema.json +61 -0
- package/docs/paper/output/submission-bundle/docs/paper/audrey-paper-v1.md +1106 -0
- package/docs/paper/output/submission-bundle/docs/paper/browser-launch-plan.json +209 -0
- package/docs/paper/output/submission-bundle/docs/paper/browser-launch-plan.schema.json +100 -0
- package/docs/paper/output/submission-bundle/docs/paper/browser-launch-results.json +86 -0
- package/docs/paper/output/submission-bundle/docs/paper/browser-launch-results.schema.json +66 -0
- package/docs/paper/output/submission-bundle/docs/paper/claim-register.json +138 -0
- package/docs/paper/output/submission-bundle/docs/paper/claim-register.schema.json +81 -0
- package/docs/paper/output/submission-bundle/docs/paper/evidence-ledger.md +103 -0
- package/docs/paper/output/submission-bundle/docs/paper/output/arxiv/README-arxiv.txt +8 -0
- package/docs/paper/output/submission-bundle/docs/paper/output/arxiv/arxiv-manifest.json +41 -0
- package/docs/paper/output/submission-bundle/docs/paper/output/arxiv/main.tex +949 -0
- package/docs/paper/output/submission-bundle/docs/paper/output/arxiv/references.bib +222 -0
- package/docs/paper/output/submission-bundle/docs/paper/output/arxiv-compile-report.json +24 -0
- package/docs/paper/output/submission-bundle/docs/paper/paper-submission-bundle.schema.json +70 -0
- package/docs/paper/output/submission-bundle/docs/paper/publication-pack.json +81 -0
- package/docs/paper/output/submission-bundle/docs/paper/publication-pack.schema.json +60 -0
- package/docs/paper/output/submission-bundle/docs/paper/references.bib +222 -0
- package/docs/paper/output/submission-bundle/package.json +212 -0
- package/docs/paper/output/submission-bundle/paper-submission-manifest.json +379 -0
- package/docs/paper/paper-submission-bundle.schema.json +70 -0
- package/docs/paper/publication-pack.json +81 -0
- package/docs/paper/publication-pack.schema.json +60 -0
- package/docs/paper/references.bib +222 -0
- package/package.json +103 -26
- package/scripts/audit-release-completion.mjs +362 -0
- package/scripts/create-arxiv-source.mjs +362 -0
- package/scripts/create-paper-submission-bundle.mjs +210 -0
- package/scripts/finalize-release.mjs +526 -0
- package/scripts/prepare-release-cut.mjs +269 -0
- package/scripts/publish-release-bundle.mjs +209 -0
- package/scripts/publish-release-github-api.mjs +429 -0
- package/scripts/run-vitest.mjs +34 -0
- package/scripts/smoke-cli.js +72 -0
- package/scripts/sync-paper-artifacts.mjs +109 -0
- package/scripts/verify-arxiv-compile.mjs +440 -0
- package/scripts/verify-arxiv-source.mjs +194 -0
- package/scripts/verify-browser-launch-plan.mjs +237 -0
- package/scripts/verify-browser-launch-results.mjs +285 -0
- package/scripts/verify-paper-artifacts.mjs +338 -0
- package/scripts/verify-paper-claims.mjs +226 -0
- package/scripts/verify-paper-submission-bundle.mjs +207 -0
- package/scripts/verify-publication-pack.mjs +196 -0
- package/scripts/verify-python-package.py +201 -0
- package/scripts/verify-release-readiness.mjs +741 -0
- package/docs/assets/benchmarks/local-benchmark.svg +0 -45
- package/docs/assets/benchmarks/operations-benchmark.svg +0 -45
- package/docs/assets/benchmarks/published-memory-standards.svg +0 -50
- package/docs/audrey-for-dummies.md +0 -670
- package/docs/benchmarking.md +0 -151
- package/docs/future-of-llm-memory.md +0 -452
- package/docs/mcp-hosts.md +0 -206
- package/docs/ollama-local-agents.md +0 -128
- package/docs/production-readiness.md +0 -128
package/docs/benchmarking.md
DELETED
|
@@ -1,151 +0,0 @@
|
|
|
1
|
-
# Benchmarking Audrey
|
|
2
|
-
|
|
3
|
-
Audrey now ships with a memory benchmark harness that does three different jobs:
|
|
4
|
-
|
|
5
|
-
1. It runs Audrey against a local retrieval suite inspired by LongMemEval, plus privacy and abstention checks that matter in production.
|
|
6
|
-
2. It runs Audrey against an operation-level suite for update, overwrite, delete, merge, and abstain behavior.
|
|
7
|
-
3. It overlays published leaderboard numbers from leading memory systems on LoCoMo so you can place Audrey in the current market and research landscape without pretending the measurements are identical.
|
|
8
|
-
|
|
9
|
-
That split is deliberate. A lot of memory tooling mixes internal demos with external benchmark claims. Audrey should not do that.
|
|
10
|
-
|
|
11
|
-
## Run It
|
|
12
|
-
|
|
13
|
-
```bash
|
|
14
|
-
npm run bench:memory
|
|
15
|
-
```
|
|
16
|
-
|
|
17
|
-
The package script is the intended operator entrypoint:
|
|
18
|
-
|
|
19
|
-
```bash
|
|
20
|
-
npm run bench:memory
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
Artifacts are written to `benchmarks/output/`:
|
|
24
|
-
|
|
25
|
-
- `summary.json`
|
|
26
|
-
- `report.html`
|
|
27
|
-
- `local-overall.svg`
|
|
28
|
-
- `retrieval-overall.svg`
|
|
29
|
-
- `operations-overall.svg`
|
|
30
|
-
- `published-locomo.svg`
|
|
31
|
-
|
|
32
|
-
For CI, JSON-only output is available:
|
|
33
|
-
|
|
34
|
-
```bash
|
|
35
|
-
npm run bench:memory:json
|
|
36
|
-
```
|
|
37
|
-
|
|
38
|
-
For regression gating, use:
|
|
39
|
-
|
|
40
|
-
```bash
|
|
41
|
-
npm run bench:memory:check
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
That command fails if Audrey falls below its minimum local score, pass rate, or required lead over the strongest naive baseline.
|
|
45
|
-
|
|
46
|
-
To refresh the committed SVGs used in the README:
|
|
47
|
-
|
|
48
|
-
```bash
|
|
49
|
-
npm run bench:memory:readme-assets
|
|
50
|
-
```
|
|
51
|
-
|
|
52
|
-
That writes stable chart assets to `docs/assets/benchmarks/` so the GitHub repo surface shows the same benchmark posture as the generated report.
|
|
53
|
-
|
|
54
|
-
To run a single local track:
|
|
55
|
-
|
|
56
|
-
```bash
|
|
57
|
-
npm run bench:memory:retrieval
|
|
58
|
-
npm run bench:memory:operations
|
|
59
|
-
```
|
|
60
|
-
|
|
61
|
-
## What The Local Retrieval Benchmark Measures
|
|
62
|
-
|
|
63
|
-
The retrieval suite covers eight memory families:
|
|
64
|
-
|
|
65
|
-
- `information_extraction`
|
|
66
|
-
- `knowledge_updates`
|
|
67
|
-
- `multi_session_reasoning`
|
|
68
|
-
- `temporal_reasoning`
|
|
69
|
-
- `abstention`
|
|
70
|
-
- `conflict_resolution`
|
|
71
|
-
- `procedural_learning`
|
|
72
|
-
- `privacy_boundary`
|
|
73
|
-
|
|
74
|
-
This is intentionally closer to how operators evaluate memory in production than a single retrieval-accuracy number. Audrey should not only retrieve facts. It should:
|
|
75
|
-
|
|
76
|
-
- prefer fresh state over stale state
|
|
77
|
-
- avoid leaking private memory
|
|
78
|
-
- consolidate repeated episodes into reusable procedures
|
|
79
|
-
- handle conflict without amplifying low-reliability noise
|
|
80
|
-
|
|
81
|
-
## What The Local Operations Benchmark Measures
|
|
82
|
-
|
|
83
|
-
The operations suite covers four lifecycle families:
|
|
84
|
-
|
|
85
|
-
- `update_overwrite`
|
|
86
|
-
- `delete_and_abstain`
|
|
87
|
-
- `semantic_merge`
|
|
88
|
-
- `procedural_merge`
|
|
89
|
-
|
|
90
|
-
This suite exists because leading memory systems are often compared on offline recall, while real agent memory succeeds or fails on memory operations:
|
|
91
|
-
|
|
92
|
-
- can a newer fact overwrite stale state without leaking both
|
|
93
|
-
- can a delete actually prevent future recall
|
|
94
|
-
- can repeated raw events merge into reusable semantic knowledge
|
|
95
|
-
- can repeated events merge into an actionable procedure instead of another inert blob of text
|
|
96
|
-
|
|
97
|
-
Those are not implementation details. They are the actual product surface of memory.
|
|
98
|
-
|
|
99
|
-
## What The Published Leaderboard Means
|
|
100
|
-
|
|
101
|
-
The LoCoMo chart in the generated report is a research context layer, not a claim that Audrey has already reproduced those exact scores.
|
|
102
|
-
|
|
103
|
-
Current published anchors included in the report:
|
|
104
|
-
|
|
105
|
-
- MIRIX: LoCoMo `85.4` from the MIRIX paper
|
|
106
|
-
- Letta Filesystem: LoCoMo `74.0` from Letta's benchmark write-up
|
|
107
|
-
- Mem0 Graph Memory: LoCoMo `68.5` from the Mem0 paper
|
|
108
|
-
- Mem0: LoCoMo `66.9` from the Mem0 paper
|
|
109
|
-
- OpenAI Memory baseline: LoCoMo `52.9` as reported in the Mem0 paper
|
|
110
|
-
|
|
111
|
-
Use this chart to answer: "Where is the frontier today?" not "Has Audrey already matched that exact benchmark protocol?"
|
|
112
|
-
|
|
113
|
-
## March 23, 2026 Research Readout
|
|
114
|
-
|
|
115
|
-
The most important memory trends right now:
|
|
116
|
-
|
|
117
|
-
1. Typed memory systems are replacing flat retrieval.
|
|
118
|
-
MemOS frames memory as an operating system concern with scheduling and memory-object abstractions, not just vector lookup.
|
|
119
|
-
|
|
120
|
-
2. Realistic long-horizon benchmarks are replacing toy recall tests.
|
|
121
|
-
LongMemEval emphasizes multi-session reasoning, temporal updates, abstraction, and knowledge revision.
|
|
122
|
-
|
|
123
|
-
3. Context engineering is now a first-class competitor to retrieval-only memory.
|
|
124
|
-
Letta's filesystem and memory-block work argues that editable context structure can outperform simpler retrieval-only designs.
|
|
125
|
-
|
|
126
|
-
4. Production memory is now judged on latency and token cost too.
|
|
127
|
-
Mem0 explicitly reports quality alongside lower token and latency overhead.
|
|
128
|
-
|
|
129
|
-
5. Temporal and multimodal memory are moving into the frontier.
|
|
130
|
-
MIRIX pushes beyond text-only episodic recall into typed multimodal memory with compression.
|
|
131
|
-
|
|
132
|
-
## What Audrey Should Do Next
|
|
133
|
-
|
|
134
|
-
The benchmark highlights the next credible roadmap for Audrey:
|
|
135
|
-
|
|
136
|
-
- first-party LoCoMo and LongMemEval adapters so Audrey can publish directly reproducible external benchmark numbers
|
|
137
|
-
- contradiction-state and truth-resolution benchmark cases, not just retrieval outcomes
|
|
138
|
-
- cost, latency, and storage curves against long-context baselines and simpler memory systems
|
|
139
|
-
- a typed memory graph layer for cross-memory state transitions and time-aware reasoning
|
|
140
|
-
|
|
141
|
-
## Source Links
|
|
142
|
-
|
|
143
|
-
- LongMemEval: [arXiv 2410.10813](https://arxiv.org/abs/2410.10813)
|
|
144
|
-
- Mem0: [arXiv 2504.19413](https://arxiv.org/abs/2504.19413)
|
|
145
|
-
- MIRIX: [arXiv 2507.07957](https://arxiv.org/abs/2507.07957)
|
|
146
|
-
- MemOS: [arXiv 2507.03724](https://arxiv.org/abs/2507.03724)
|
|
147
|
-
- MemGPT: [arXiv 2310.08560](https://arxiv.org/abs/2310.08560)
|
|
148
|
-
- Letta memory blocks: [Letta blog](https://www.letta.com/blog/memory-blocks)
|
|
149
|
-
- Letta benchmarking: [Letta benchmark write-up](https://www.letta.com/blog/benchmarking-ai-agent-memory)
|
|
150
|
-
- LoCoMo benchmark repo: [snap-research/locomo](https://github.com/snap-research/locomo)
|
|
151
|
-
- LongMemEval repo: [xiaowu0162/LongMemEval](https://github.com/xiaowu0162/LongMemEval)
|
|
@@ -1,452 +0,0 @@
|
|
|
1
|
-
# The Future of LLM Memory
|
|
2
|
-
|
|
3
|
-
Date: 2026-04-24
|
|
4
|
-
Audience: Audrey product strategy, technical roadmap, launch content
|
|
5
|
-
|
|
6
|
-
## Thesis
|
|
7
|
-
|
|
8
|
-
The next serious AI platform will not win because it has the longest context window. It will win because it remembers the right things, forgets the wrong things, proves why a memory matters, and carries learned behavior across tools, hosts, teams, and time.
|
|
9
|
-
|
|
10
|
-
The market has already accepted memory as a product category. Claude has project-scoped memory and Managed Agents memory. ChatGPT has saved memories and chat-history reference. Gemini has saved info and past-chat reference. Letta, Mem0, Zep/Graphiti, MemOS, and MIRIX all point toward the same conclusion: stateless agents are not enough.
|
|
11
|
-
|
|
12
|
-
Audrey's opening is not "we also have memory." The opening is:
|
|
13
|
-
|
|
14
|
-
> Audrey is the local-first memory control plane for every agent you run.
|
|
15
|
-
|
|
16
|
-
That means Audrey should become the inspectable, portable, host-neutral layer that turns work into durable memory, and memory into better behavior.
|
|
17
|
-
|
|
18
|
-
## What The Field Already Has
|
|
19
|
-
|
|
20
|
-
### Platform Memory
|
|
21
|
-
|
|
22
|
-
Claude introduced memory for teams and projects, with optional controls, editable summaries, incognito chats, and project separation. Anthropic also announced built-in memory for Claude Managed Agents on April 23, 2026, with filesystem-backed memories, exports, API management, audit logs, rollback, scoped stores, and multi-agent sharing.
|
|
23
|
-
|
|
24
|
-
OpenAI's ChatGPT memory exposes saved memories, chat-history reference, temporary chats, deletion controls, memory prioritization, and memory history/restore controls for supported plans.
|
|
25
|
-
|
|
26
|
-
Google Gemini has saved info and can reference past chats in supported accounts and contexts.
|
|
27
|
-
|
|
28
|
-
The user-facing lesson: users now expect assistants to remember.
|
|
29
|
-
|
|
30
|
-
The product gap: these memories are mostly locked inside each platform.
|
|
31
|
-
|
|
32
|
-
### Agent Framework Memory
|
|
33
|
-
|
|
34
|
-
Letta frames agents as stateful systems with memory blocks, archival memory, messages, tools, runs, and shared blocks. Mem0 focuses on scalable extraction and retrieval for production agents. Zep/Graphiti uses temporal knowledge graphs to track changing entity relationships. MemOS frames memory as an OS-managed resource with provenance and versioning. MIRIX uses multiple memory types and a multi-agent controller, including multimodal screen memory.
|
|
35
|
-
|
|
36
|
-
The infrastructure lesson: memory is becoming its own layer.
|
|
37
|
-
|
|
38
|
-
The product gap: no simple open standard lets a normal developer connect Codex, Claude Code, Claude Desktop, Cursor, Ollama, and internal agents to one controllable local memory runtime.
|
|
39
|
-
|
|
40
|
-
### Benchmarks
|
|
41
|
-
|
|
42
|
-
LoCoMo tests very long, multimodal conversations across sessions, temporal event graphs, and causal consistency. LongMemEval tests information extraction, multi-session reasoning, temporal reasoning, knowledge updates, and abstention. Mem0's public benchmark work emphasizes token efficiency, latency, and cost, not just raw accuracy. New 2026 benchmarks like MemoryCD and Mem2ActBench push the field toward cross-domain lifelong personalization and memory-driven tool action.
|
|
43
|
-
|
|
44
|
-
The benchmark lesson: "it remembered a fact" is too shallow.
|
|
45
|
-
|
|
46
|
-
The product gap: operators need memory tests and regression gates they can run before trusting an agent with real workflows.
|
|
47
|
-
|
|
48
|
-
## What Humans Have Not Really Done Yet
|
|
49
|
-
|
|
50
|
-
This section is not claiming nobody has written a paper or prototype. It means these ideas are not yet common, packaged, trusted, and easy enough for normal teams to use.
|
|
51
|
-
|
|
52
|
-
### 1. A User-Owned Memory Passport
|
|
53
|
-
|
|
54
|
-
Current memory is platform-bound. ChatGPT remembers inside ChatGPT. Claude remembers inside Claude. A local Ollama agent remembers only if a developer builds memory for it.
|
|
55
|
-
|
|
56
|
-
Audrey can turn memory into a portable "passport":
|
|
57
|
-
|
|
58
|
-
- One user or team memory store that travels across Codex, Claude, Ollama, IDEs, and internal agents.
|
|
59
|
-
- Export/import as a first-class workflow, not an afterthought.
|
|
60
|
-
- Host-specific agent identities layered on top of shared memory.
|
|
61
|
-
- A visible "what this agent knows about me and this project" control panel.
|
|
62
|
-
|
|
63
|
-
Feature candidate:
|
|
64
|
-
|
|
65
|
-
- `npx audrey passport export`
|
|
66
|
-
- `npx audrey passport import`
|
|
67
|
-
- `npx audrey passport inspect --agent codex`
|
|
68
|
-
- `npx audrey passport diff --host claude-code --host codex`
|
|
69
|
-
|
|
70
|
-
Why it could be viral:
|
|
71
|
-
|
|
72
|
-
People are already frustrated that each AI starts over. "Bring your AI memory with you" is instantly understandable.
|
|
73
|
-
|
|
74
|
-
### 2. Git For Memory
|
|
75
|
-
|
|
76
|
-
Claude Managed Agents now highlight file-backed memories, audit logs, rollback, and redaction. That is a strong signal. But the broader agent ecosystem still lacks a developer-native model for memory branching and review.
|
|
77
|
-
|
|
78
|
-
Audrey can make memory feel like git:
|
|
79
|
-
|
|
80
|
-
- Diff memories before and after an agent session.
|
|
81
|
-
- Commit a memory state before risky work.
|
|
82
|
-
- Branch memory per project or customer.
|
|
83
|
-
- Merge lessons from one agent into another.
|
|
84
|
-
- Roll back bad memories without destroying the whole store.
|
|
85
|
-
- Review memory writes like code review.
|
|
86
|
-
|
|
87
|
-
Feature candidate:
|
|
88
|
-
|
|
89
|
-
- `npx audrey memory diff`
|
|
90
|
-
- `npx audrey memory commit -m "learn Windows EPERM workaround"`
|
|
91
|
-
- `npx audrey memory branch customer-acme`
|
|
92
|
-
- `npx audrey memory rollback <checkpoint>`
|
|
93
|
-
|
|
94
|
-
Why it matters:
|
|
95
|
-
|
|
96
|
-
The more powerful memory gets, the more teams need change control.
|
|
97
|
-
|
|
98
|
-
### 3. Memory As A Preflight Safety System
|
|
99
|
-
|
|
100
|
-
Most memory systems retrieve context after the user asks a question. The bigger opportunity is to use memory before the agent acts.
|
|
101
|
-
|
|
102
|
-
Audrey already has the seed of this with tool-trace memory. Repeated failures should become warnings before the agent retries the same risky operation.
|
|
103
|
-
|
|
104
|
-
Now shipping as the first concrete slice:
|
|
105
|
-
|
|
106
|
-
- MCP tool `memory_preflight`.
|
|
107
|
-
- MCP tool `memory_reflexes`.
|
|
108
|
-
- REST route `POST /v1/preflight`.
|
|
109
|
-
- REST route `POST /v1/reflexes`.
|
|
110
|
-
- SDK method `audrey.preflight(action, options)`.
|
|
111
|
-
- SDK method `audrey.reflexes(action, options)`.
|
|
112
|
-
- Response fields for decision, risk score, warnings, recommendations, evidence IDs, health, recent failures, optional event recording, and optional capsule context.
|
|
113
|
-
- Reflex reports that convert warnings into trigger-response rules an agent can automate before tool use.
|
|
114
|
-
|
|
115
|
-
Follow-on candidates:
|
|
116
|
-
|
|
117
|
-
- Before shell commands: "Have we broken this repo with this command before?"
|
|
118
|
-
- Before migrations: "Does memory say this environment lacks `wmic` or blocks temp writes?"
|
|
119
|
-
- Before package publishing: "What are the known release gates for this repo?"
|
|
120
|
-
- Before editing config: "Has this host config path been stale or write-protected?"
|
|
121
|
-
|
|
122
|
-
Why it could be viral:
|
|
123
|
-
|
|
124
|
-
A demo where Audrey stops an agent from repeating a known failure is more compelling than a chatbot remembering a favorite color.
|
|
125
|
-
|
|
126
|
-
### 4. Action Memory, Not Just Answer Memory
|
|
127
|
-
|
|
128
|
-
Mem2ActBench explicitly calls out a gap: benchmarks often test passive fact retrieval, while real agents need to apply memory to select tools and ground parameters. This is the difference between "I remember your CRM is HubSpot" and "I will call the HubSpot tool with the right pipeline, property names, and customer scope because that is how your business works."
|
|
129
|
-
|
|
130
|
-
Audrey should feature action memory:
|
|
131
|
-
|
|
132
|
-
- Tool preferences.
|
|
133
|
-
- Environment quirks.
|
|
134
|
-
- Known-safe command patterns.
|
|
135
|
-
- API parameter conventions.
|
|
136
|
-
- Repeated manual fixes.
|
|
137
|
-
- Customer-specific operational workflows.
|
|
138
|
-
|
|
139
|
-
Feature candidate:
|
|
140
|
-
|
|
141
|
-
- `memory_procedure_suggest`
|
|
142
|
-
- `memory_preflight`
|
|
143
|
-
- `memory_reflexes`
|
|
144
|
-
- `memory_action_context`
|
|
145
|
-
- "Before using this tool, Audrey recommends..."
|
|
146
|
-
|
|
147
|
-
Why it matters:
|
|
148
|
-
|
|
149
|
-
Small businesses do not need AI that remembers trivia. They need AI that remembers how work actually gets done.
|
|
150
|
-
|
|
151
|
-
### 5. Memory Regression Tests
|
|
152
|
-
|
|
153
|
-
Memory can silently get worse. A new embedding provider, schema migration, pruning rule, or prompt change can cause an agent to forget the exact thing that made it valuable.
|
|
154
|
-
|
|
155
|
-
Audrey should treat memory like tested infrastructure:
|
|
156
|
-
|
|
157
|
-
- Memory fixtures.
|
|
158
|
-
- Recall assertions.
|
|
159
|
-
- Capsule assertions.
|
|
160
|
-
- "Should not recall" tests for privacy and stale facts.
|
|
161
|
-
- Budget tests for token cost.
|
|
162
|
-
- Temporal tests for changed facts.
|
|
163
|
-
|
|
164
|
-
Feature candidate:
|
|
165
|
-
|
|
166
|
-
```bash
|
|
167
|
-
npx audrey eval add "What is the deploy command?" --expect "npm run deploy"
|
|
168
|
-
npx audrey eval run
|
|
169
|
-
npx audrey eval ci --fail-under 0.90
|
|
170
|
-
```
|
|
171
|
-
|
|
172
|
-
Why it matters:
|
|
173
|
-
|
|
174
|
-
This turns Audrey from a feature into infrastructure that teams can trust.
|
|
175
|
-
|
|
176
|
-
### 6. Permission-Aware Shared Memory For Teams
|
|
177
|
-
|
|
178
|
-
Research on collaborative memory is moving toward multi-user, multi-agent memory with dynamic access control, provenance, private fragments, shared fragments, and time-varying permissions.
|
|
179
|
-
|
|
180
|
-
Audrey's local-first story should include this, especially for small businesses:
|
|
181
|
-
|
|
182
|
-
- Owner memory.
|
|
183
|
-
- Employee memory.
|
|
184
|
-
- Customer memory.
|
|
185
|
-
- Project memory.
|
|
186
|
-
- Agent memory.
|
|
187
|
-
- Read/write scopes by host and role.
|
|
188
|
-
|
|
189
|
-
Feature candidate:
|
|
190
|
-
|
|
191
|
-
- `audrey://scopes`
|
|
192
|
-
- `memory_share --scope team --redact private`
|
|
193
|
-
- `memory_policy test --agent codex --user owner`
|
|
194
|
-
|
|
195
|
-
Why it matters:
|
|
196
|
-
|
|
197
|
-
Shared memory without access control becomes a liability. Access control without usability becomes shelfware.
|
|
198
|
-
|
|
199
|
-
### 7. A Preference Model That Learns From Weak Feedback
|
|
200
|
-
|
|
201
|
-
The 2026 VARS paper argues that agents need persistent user models and can learn retrieval preferences from weak scalar feedback, not just explicit "remember this" commands.
|
|
202
|
-
|
|
203
|
-
Audrey can support this without fine-tuning:
|
|
204
|
-
|
|
205
|
-
- Track when retrieved memories helped.
|
|
206
|
-
- Track when a user corrected the agent.
|
|
207
|
-
- Boost memories that reduce retries or shorten sessions.
|
|
208
|
-
- Decay memories that repeatedly fail to help.
|
|
209
|
-
- Separate long-term preferences from session-specific context.
|
|
210
|
-
|
|
211
|
-
Feature candidate:
|
|
212
|
-
|
|
213
|
-
- `memory_feedback`
|
|
214
|
-
- `memory_recall --learn-from-outcome`
|
|
215
|
-
- `memory_status --preference-drift`
|
|
216
|
-
|
|
217
|
-
Why it matters:
|
|
218
|
-
|
|
219
|
-
Good memory is not only what was said. It is what repeatedly proved useful.
|
|
220
|
-
|
|
221
|
-
### 8. Temporal Truth, Not Flat Facts
|
|
222
|
-
|
|
223
|
-
Zep/Graphiti's temporal graph work is a strong signal: real memory needs to know when a fact was true, what replaced it, and what evidence supports it.
|
|
224
|
-
|
|
225
|
-
Audrey should make this obvious:
|
|
226
|
-
|
|
227
|
-
- "Customer uses Stripe" may be true until they migrate to Square.
|
|
228
|
-
- "Run tests with Vitest" may be true in CI but false on a locked-down Windows host.
|
|
229
|
-
- "The README says `/docs` exists" may be stale after routes changed.
|
|
230
|
-
|
|
231
|
-
Feature candidate:
|
|
232
|
-
|
|
233
|
-
- `valid_from`, `valid_until`, `supersedes`, `superseded_by`.
|
|
234
|
-
- Memory conflict timelines.
|
|
235
|
-
- Capsule sections for "current truth" and "stale but relevant history."
|
|
236
|
-
|
|
237
|
-
Why it matters:
|
|
238
|
-
|
|
239
|
-
The most dangerous memory is a true fact from the wrong time.
|
|
240
|
-
|
|
241
|
-
### 9. Multimodal Operational Memory
|
|
242
|
-
|
|
243
|
-
MIRIX shows the importance of multimodal memory, including screenshots and visual context. Most practical agents still remember text far better than UI state, screenshots, invoices, dashboards, browser flows, and design assets.
|
|
244
|
-
|
|
245
|
-
Audrey could target operational multimodal memory:
|
|
246
|
-
|
|
247
|
-
- Website screenshots before and after optimization.
|
|
248
|
-
- CRM screenshots and field mappings.
|
|
249
|
-
- Error dialogs.
|
|
250
|
-
- Browser traces.
|
|
251
|
-
- Invoice images and extracted fields.
|
|
252
|
-
- Design screenshots tied to implementation notes.
|
|
253
|
-
|
|
254
|
-
Feature candidate:
|
|
255
|
-
|
|
256
|
-
- `memory_encode_asset`
|
|
257
|
-
- `memory_recall_assets`
|
|
258
|
-
- `audrey://recent-screens`
|
|
259
|
-
- Visual evidence inside Memory Capsules.
|
|
260
|
-
|
|
261
|
-
Why it matters:
|
|
262
|
-
|
|
263
|
-
Small-business work is visual and operational, not just chat text.
|
|
264
|
-
|
|
265
|
-
### 10. Memory Capsules As A Standard Handoff Artifact
|
|
266
|
-
|
|
267
|
-
Audrey's Memory Capsule is the right product surface: a compact, ranked, evidence-backed briefing for a specific task.
|
|
268
|
-
|
|
269
|
-
The opportunity is to make capsules portable:
|
|
270
|
-
|
|
271
|
-
- A Codex capsule before coding.
|
|
272
|
-
- A Claude capsule before planning.
|
|
273
|
-
- An Ollama capsule before a local answer.
|
|
274
|
-
- A CRM capsule before customer follow-up.
|
|
275
|
-
- A support capsule before replying to a ticket.
|
|
276
|
-
|
|
277
|
-
Feature candidate:
|
|
278
|
-
|
|
279
|
-
- `.audrey/capsules/<task>.md`
|
|
280
|
-
- `npx audrey capsule "shipping release" --format md`
|
|
281
|
-
- Capsule links in PRs, tickets, and handoff docs.
|
|
282
|
-
|
|
283
|
-
Why it could be viral:
|
|
284
|
-
|
|
285
|
-
"Paste this Memory Capsule into any LLM and it works like it knows the project" is a simple hook.
|
|
286
|
-
|
|
287
|
-
### 11. Memory Economics
|
|
288
|
-
|
|
289
|
-
Mem0 is pushing token efficiency as a production concern. Audrey should make memory economics visible:
|
|
290
|
-
|
|
291
|
-
- Tokens avoided.
|
|
292
|
-
- Repeated user explanations avoided.
|
|
293
|
-
- Failures prevented.
|
|
294
|
-
- Time saved by not rediscovering setup.
|
|
295
|
-
- Cost difference between full-context replay and selective recall.
|
|
296
|
-
|
|
297
|
-
Feature candidate:
|
|
298
|
-
|
|
299
|
-
- `npx audrey roi`
|
|
300
|
-
- `memory_status` with saved-token estimates.
|
|
301
|
-
- Tool-trace reports showing prevented repeat failures.
|
|
302
|
-
|
|
303
|
-
Why it matters:
|
|
304
|
-
|
|
305
|
-
Business buyers need a reason to pay. "Audrey saved 40 minutes and avoided three failed deploys this week" is a reason.
|
|
306
|
-
|
|
307
|
-
### 12. Sleep That Produces New Working Knowledge
|
|
308
|
-
|
|
309
|
-
Many systems summarize. Humans consolidate. Audrey's "dream" concept is stronger if it becomes visibly useful:
|
|
310
|
-
|
|
311
|
-
- Detect repeated failures.
|
|
312
|
-
- Turn patterns into procedures.
|
|
313
|
-
- Find contradictions.
|
|
314
|
-
- Promote stable lessons into rules.
|
|
315
|
-
- Archive low-value memories.
|
|
316
|
-
- Produce a morning briefing.
|
|
317
|
-
|
|
318
|
-
Feature candidate:
|
|
319
|
-
|
|
320
|
-
- `npx audrey dream --report`
|
|
321
|
-
- `npx audrey promote --target codex-rules`
|
|
322
|
-
- "Last night Audrey learned..."
|
|
323
|
-
|
|
324
|
-
Why it matters:
|
|
325
|
-
|
|
326
|
-
The public understands "AI that dreams on your work and wakes up smarter." The engineering version must stay honest: it is consolidation, contradiction detection, procedural learning, and decay.
|
|
327
|
-
|
|
328
|
-
## Audrey's Best Feature Bet
|
|
329
|
-
|
|
330
|
-
The single best over-the-top feature now shipping is:
|
|
331
|
-
|
|
332
|
-
> Memory Reflexes: before an agent acts, Audrey checks prior memories, tool traces, environment quirks, and project rules, then returns trigger-response guidance the host can automate.
|
|
333
|
-
|
|
334
|
-
Why this is the right bet:
|
|
335
|
-
|
|
336
|
-
- It uses Audrey's existing differentiators: tool traces, procedural memory, Memory Capsules, confidence, tags, and local host identity.
|
|
337
|
-
- It is easy to demonstrate.
|
|
338
|
-
- It works across Codex, Claude, and Ollama.
|
|
339
|
-
- It solves a real pain: agents repeat mistakes.
|
|
340
|
-
- It is more defensible than generic chat memory.
|
|
341
|
-
|
|
342
|
-
Demo script:
|
|
343
|
-
|
|
344
|
-
1. Run a command that fails on this Windows host because of a known `spawn EPERM`, temp-dir, or config-path issue.
|
|
345
|
-
2. Encode the failure through Audrey's tool trace path.
|
|
346
|
-
3. Start a new agent session.
|
|
347
|
-
4. Ask the agent to run the risky workflow again.
|
|
348
|
-
5. Audrey returns a reflex: "Before using npm test, review the prior EPERM failure path."
|
|
349
|
-
6. The agent avoids the repeated failure or switches to the known fallback validation path.
|
|
350
|
-
|
|
351
|
-
Tagline:
|
|
352
|
-
|
|
353
|
-
> Audrey gives AI agents memory before they act.
|
|
354
|
-
|
|
355
|
-
## Launch-Ready Content Angles
|
|
356
|
-
|
|
357
|
-
### Post 1: "Your AI Has Amnesia"
|
|
358
|
-
|
|
359
|
-
Hook:
|
|
360
|
-
|
|
361
|
-
Your AI can write code, call tools, browse docs, and deploy software. Then tomorrow it forgets the lesson it learned today.
|
|
362
|
-
|
|
363
|
-
Audrey angle:
|
|
364
|
-
|
|
365
|
-
Memory should be local, inspectable, portable, and testable.
|
|
366
|
-
|
|
367
|
-
### Post 2: "Context Windows Are Not Memory"
|
|
368
|
-
|
|
369
|
-
Hook:
|
|
370
|
-
|
|
371
|
-
A million-token context window is a bigger backpack. It is not a brain.
|
|
372
|
-
|
|
373
|
-
Audrey angle:
|
|
374
|
-
|
|
375
|
-
Real memory needs write policy, retrieval policy, forgetting, contradiction handling, source lineage, and regression tests.
|
|
376
|
-
|
|
377
|
-
### Post 3: "The Agent Black Box"
|
|
378
|
-
|
|
379
|
-
Hook:
|
|
380
|
-
|
|
381
|
-
When an AI agent makes a mistake, where does that mistake go?
|
|
382
|
-
|
|
383
|
-
Audrey angle:
|
|
384
|
-
|
|
385
|
-
Tool traces become procedural memory so agents avoid repeating preventable failures.
|
|
386
|
-
|
|
387
|
-
### Post 4: "Bring Your Memory"
|
|
388
|
-
|
|
389
|
-
Hook:
|
|
390
|
-
|
|
391
|
-
Every AI platform wants to remember you. None of them want your memory to leave.
|
|
392
|
-
|
|
393
|
-
Audrey angle:
|
|
394
|
-
|
|
395
|
-
Audrey is the local-first memory passport across Codex, Claude, Ollama, and internal agents.
|
|
396
|
-
|
|
397
|
-
### Post 5: "The Small Business Brain"
|
|
398
|
-
|
|
399
|
-
Hook:
|
|
400
|
-
|
|
401
|
-
Every small business has invisible operating knowledge: how quotes are written, which customers need special handling, what breaks on the website, and how the owner likes decisions made.
|
|
402
|
-
|
|
403
|
-
Audrey angle:
|
|
404
|
-
|
|
405
|
-
Audrey turns that invisible knowledge into a local memory layer for websites, CRMs, support agents, and back-office automation.
|
|
406
|
-
|
|
407
|
-
## Near-Term Audrey Roadmap
|
|
408
|
-
|
|
409
|
-
### 30 Days
|
|
410
|
-
|
|
411
|
-
- Add `npx audrey install --host codex|claude-code|claude-desktop|generic` with dry-run and backups.
|
|
412
|
-
- Add `npx audrey capsule "task" --format md|json`.
|
|
413
|
-
- Add richer Memory Preflight demos, policy modes, and tool classifiers.
|
|
414
|
-
- Add a Memory Capsule file exporter.
|
|
415
|
-
- Add docs and demos for "agent avoids repeated failure."
|
|
416
|
-
|
|
417
|
-
### 60 Days
|
|
418
|
-
|
|
419
|
-
- Add memory diff/checkpoint/rollback commands.
|
|
420
|
-
- Add memory eval fixtures and CI gates.
|
|
421
|
-
- Add temporal validity fields and supersession UI/API.
|
|
422
|
-
- Add first LoCoMo and LongMemEval adapters.
|
|
423
|
-
- Add a small-business CRM demo with customer memory, workflow memory, and tool preflight.
|
|
424
|
-
|
|
425
|
-
### 90 Days
|
|
426
|
-
|
|
427
|
-
- Add permission scopes for shared memory.
|
|
428
|
-
- Add feedback learning over recall outcomes.
|
|
429
|
-
- Add capsule sharing and signed export bundles.
|
|
430
|
-
- Add multimodal asset memory prototype.
|
|
431
|
-
- Add dashboard/reporting for ROI, failures prevented, and token budget.
|
|
432
|
-
|
|
433
|
-
## References
|
|
434
|
-
|
|
435
|
-
- Anthropic, "Bringing memory to Claude" (2025): https://claude.com/blog/memory
|
|
436
|
-
- Anthropic, "Built-in memory for Claude Managed Agents" (2026): https://claude.com/blog/claude-managed-agents-memory
|
|
437
|
-
- OpenAI Help, "Memory FAQ": https://help.openai.com/en/articles/8590148-memory-faq/
|
|
438
|
-
- Google Gemini Help, "Save info and reference past chats": https://support.google.com/gemini/answer/15637730
|
|
439
|
-
- Letta Docs, "Introduction to Stateful Agents": https://docs.letta.com/guides/core-concepts/stateful-agents
|
|
440
|
-
- Mem0, "Memory Evaluation": https://docs.mem0.ai/core-concepts/memory-evaluation
|
|
441
|
-
- Chhikara et al., "Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory" (2025): https://arxiv.org/abs/2504.19413
|
|
442
|
-
- Rasmussen et al., "Zep: A Temporal Knowledge Graph Architecture for Agent Memory" (2025): https://arxiv.org/abs/2501.13956
|
|
443
|
-
- Li et al., "MemOS: A Memory OS for AI System" (2025): https://arxiv.org/abs/2507.03724
|
|
444
|
-
- Wang and Chen, "MIRIX: Multi-Agent Memory System for LLM-Based Agents" (2025): https://arxiv.org/abs/2507.07957
|
|
445
|
-
- Wu et al., "LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory" (2025): https://arxiv.org/abs/2410.10813
|
|
446
|
-
- Maharana et al., "Evaluating Very Long-Term Conversational Memory of LLM Agents" (LoCoMo, 2024): https://arxiv.org/abs/2402.17753
|
|
447
|
-
- Hao et al., "User Preference Modeling for Conversational LLM Agents" (2026): https://arxiv.org/abs/2603.20939
|
|
448
|
-
- Zhang et al., "MemoryCD" (2026): https://openreview.net/forum?id=Lpq4aEqvmg
|
|
449
|
-
- Rezazadeh et al., "Collaborative Memory" (2026 submission): https://openreview.net/forum?id=pJUQ5YA98Z
|
|
450
|
-
- "Mem2ActBench" (2026 submission): https://openreview.net/forum?id=hiRJ90xzJY
|
|
451
|
-
- Ollama OpenAI compatibility: https://docs.ollama.com/api/openai-compatibility
|
|
452
|
-
- Ollama tool calling: https://docs.ollama.com/capabilities/tool-calling
|