Skip to main content
runMemoryEval() tests retrieval, not model quality. It asks the six-layer memory system a set of queries and checks whether the returned records contain the expected evidence.

Eval request

agentWallet and testCases are required. The endpoint also accepts agent_id as an alias for agentWallet.

What the eval does

For each test case, the harness:
  1. Calls searchMemoryLayers() with the requested scope.
  2. Serializes the layer payload.
  3. Marks the case as a hit when the payload contains expected, contains expectedMemoryId, or returns any memory when neither expectation is supplied.
  4. Records returned item count, payload character count, and search latency.
This keeps evals deterministic enough for regression checks. Use concrete substring expectations: stable facts, memory ids, or distinctive phrases.

Metrics

What it does not prove

Use evals as regression tests for indexing, scoping, filtering, and retrieval. Use separate answer-quality evals when you need to measure model behavior after memory is injected.

Useful cases

Comparison notes

Most memory evals end up in app code or in a separate observability product. Manowar keeps a retrieval eval endpoint next to the memory routes because the runtime owns indexing, scoping, cache invalidation, and retrieval. When a user says “the agent forgot,” you can test the memory layer before blaming the model.