# Open call: test your agent memory layer on an adversarial coding benchmark **URL:** \ **Category:** 🤗Datasets\ **Created:** [September 2, 2026, 2:01pm UTC](https://discuss.huggingface.co/t/open-call-test-your-agent-memory-layer-on-an-adversarial-coding-benchmark/179762 "2026-09-02T14:01:04Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Gde05](https://avatars.discourse-cdn.com/v4/letter/g/df788c/32.png) [@Gde05](https://discuss.huggingface.co/u/Gde05)\ **Post date:** [September 2, 2026, 2:01pm UTC](https://discuss.huggingface.co/t/open-call-test-your-agent-memory-layer-on-an-adversarial-coding-benchmark/179762/1 "2026-09-02T14:01:04Z")
I built AMB, an open and preregistered benchmark for memory layers in coding agents. Most memory benchmarks test whether a system retrieves a relevant chunk. AMB tests whether that memory actually helps an agent complete real coding work, or causes a worse change. Claude Code runs inside a sandboxed repository, and executable tests grade the resulting artifact. The benchmark is adversarially constructed with absent, stale, superseded, contradictory, adjacent, and irrelevant memories. The current public feed contains 195 pre-authored session transcripts. A separate hard corpus record scales to 4,900 documents, including 196 real documents and 4,704 synthetic distractors, with roughly 143,000 chunks. I am inviting small memory vendors to test their systems. There is no participation fee. Vendors can review the adapter contract, run with their own credentials, and publish their configuration and results. Negative results are welcome. The current suite mainly measures the read path. It does not yet measure whether a memory layer learns from the agent’s own work across sessions, and no multi product ranking has been published. Repository: > **[GitHub - GiulioDER/agent-memory-bench: A preregistered, execution-graded benchmark of...](https://github.com/GiulioDER/agent-memory-bench)** > > A preregistered, execution-graded benchmark of pluggable memory layers for Claude Code, measured by task success on real coding tasks What would you want this benchmark to measure before trusting its results? ---
**Author:** ![thordata](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/thordata/32/62596_2.png) [@thordata](https://discuss.huggingface.co/u/thordata)\ **Post date:** [September 4, 2026, 9:13am UTC](https://discuss.huggingface.co/t/open-call-test-your-agent-memory-layer-on-an-adversarial-coding-benchmark/179762/2 "2026-09-04T09:13:42Z")
The execution-based evaluation sounds much more useful than measuring retrieval alone. I’d also include a no-memory baseline and a small leakage check, then report stale, contradictory, and irrelevant memory failures separately. That would make the results easier to interpret. ---
**Author:** ![Gde05](https://avatars.discourse-cdn.com/v4/letter/g/df788c/32.png) [@Gde05](https://discuss.huggingface.co/u/Gde05)\ **Post date:** [September 4, 2026, 9:41am UTC](https://discuss.huggingface.co/t/open-call-test-your-agent-memory-layer-on-an-adversarial-coding-benchmark/179762/3 "2026-09-04T09:41:09Z")
Thanks, I changed the benchmark in that direction. It now evaluates whether Claude completes the coding task and passes an executable checker, rather than scoring retrieval alone. I added a `bare` arm with no memory layer, plus a `protocol` arm with the shared instructions but no memory surface, so I can separate memory from generic prompting. I also added leakage audits and sandbox isolation checks. The benchmark now reports absent, stale, contradictory, irrelevant, and present memory conditions separately. ---
**Author:** ![entity002](https://avatars.discourse-cdn.com/v4/letter/e/6f9a4e/32.png) [@entity002](https://discuss.huggingface.co/u/entity002)\ **Post date:** [September 16, 2026, 12:35am UTC](https://discuss.huggingface.co/t/open-call-test-your-agent-memory-layer-on-an-adversarial-coding-benchmark/179762/4 "2026-09-16T00:35:22Z")
I just shipped a causal memory layer with a 246-transcript benchmark called Silent Rotation. Memoryless agents converged on a planted decoy 21/25 times. Our system: 20/23 correct. The mechanism is **retroactive salience backfill** from a 2024 Nature paper, it reaches backward from failures to find causes that similarity search misses. Happy to test against AMB. Repo: [GitHub - samvallad33/vestige: Vestige enhances agents by deterministic root-cause retrieval that reaches backward through time to find the quiet change, decision, or service that caused today’s failure, not the lookalike. · GitHub](http://github.com/samvallad33/vestige) ---
**Author:** ![alikhaters](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/alikhaters/32/61986_2.png) [@alikhaters](https://discuss.huggingface.co/u/alikhaters)\ **Post date:** [September 16, 2026, 10:26am UTC](https://discuss.huggingface.co/t/open-call-test-your-agent-memory-layer-on-an-adversarial-coding-benchmark/179762/5 "2026-09-16T10:26:11Z")
Once the read path is stable, I would add sequence-level scoring: memory should improve outcomes across several linked tasks without accumulating false beliefs. Measure task success, harmful-memory rate, useful-memory precision, and total memory/token overhead. A strong layer should not only rescue failures; it should know when not to write or retrieve. Freezing a held-out corpus before vendor runs would also reduce tuning leakage. ---
**Author:** ![Gde05](https://avatars.discourse-cdn.com/v4/letter/g/df788c/32.png) [@Gde05](https://discuss.huggingface.co/u/Gde05)\ **Post date:** [September 17, 2026, 9:36am UTC](https://discuss.huggingface.co/t/open-call-test-your-agent-memory-layer-on-an-adversarial-coding-benchmark/179762/6 "2026-09-17T09:36:42Z")
I think this is the right next layer. Single task success can show that memory sometimes rescues a failure, but it cannot show whether the system improves over a sequence, without accumulating stale or false beliefs. I would evaluate chain success, harmful memory events, useful memory precision, selective writing and retrieval, and total token and latency overhead separately. The existing longitudinal design is a good foundation, but the held out corpus should be frozen, hashed, and preregistered before vendor runs begin. That would make the result measure generalization and memory discipline, rather than adaptation to the evaluation set.