Provides enough graph evidence to document both the Session 2 success and the Session 4 stale-context problem using visible document and chunk IDs.
What was measured
Observability and Debugging
Checks whether developers can inspect what happened, including stored and retrieved memories.
context, not decisivecapability
Inspecting stored and retrieved memories helps teams debug and trust the system, but it does not itself measure memory performance. (3 of 3 judges)
What was given, what came back
Test input: Client Relationship Memory · text · group: memory-for-ai-agents
Input — what we sent
The exact prompt
Session 1: Use this under account_id: client_acme_001 ACME is a client using our AI support assistant. They prefer clear next steps and do not like repeated troubleshooting. Their team already tried password reset, clearing browser cache, and switching browsers. The issue is still happening only for users with SSO enabled. Session 2: Use this under account_id: client_acme_001 ACME came back today and said: "Our users still cannot log in with SSO. What should we try next?" Draft a support reply that respects what they already tried and moves to the next useful step. Session 3: Use this under account_id: client_acme_001 Update the client memory: ACME is no longer using SSO for this rollout. They moved to email-password login for the first launch. Do not keep treating SSO as the active issue unless they mention it again. Session 4: Use this under account_id: client_acme_001 ACME says: "Some users are still unable to log in during launch testing." Draft the next support reply. Session 5: Use this under account_id: client_beta_002 BetaCorp is a new client. They say: "Our users cannot log in for the first time." Draft the first support reply for BetaCorp.
A client-support memory test that checks whether the assistant remembers prior troubleshooting, handles a changed rollout context, keeps client scope isolated, and avoids leaking one client’s history into another client’s support reply.
Why this input is hard
- · client history recall
- · avoid repeating troubleshooting
- · update handling
- · scope isolation between clients
- · support response continuity
Output — unretouched
Also checked on this input — same tool, 4 other criteria
Correct Application✓ WorkedUses retrieved ACME history correctly by skipping the already-tried steps and moving to deeper SSO diagnostics instead of repeating the same troubleshooting.Memory Capture Quality✓ WorkedCaptures client identity, prior troubleshooting, and response preferences together, including the already-tried reset/cache/browser steps and the preference for clear next steps.Scope Control✓ WorkedKeeps client containers isolated: a fresh `client_beta_002` reply does not inherit ACME's troubleshooting history or preferences.Update and Correction Handling✗ FailedAccepts an explicit client-memory update that SSO is no longer the rollout path, but the following reply still resurfaces SSO-specific troubleshooting language, so the old context was not fully retired.
Provenance
- Observation
- 3e95722a-bb51-4b39-bb19-742617b937d9
- Evidence run
- 6e31afbb-34d7-459a-b688-68ef76fc615a
- Study
- Memory for AI Agents
- Research task
- 86ba16xrp
- Tested at
- not recorded
- Source
- first-party
- Evidence state
- verified
- Proof shown
- input + output shown
- Cost / latency
- not captured
- Repeat run
- not captured
- Tester
- not captured
The last three rows are honest blanks, not placeholders — our capture has no field for them yet.
Query this
get_evidence({
tool: "cognee",
scenario: "memory-for-ai-agents"
})MCP · mcp.aidemos.com/api/mcp
Free with attribution.
Same input, same check — 0 other tools
measured on Observability and Debugging
No other tool was measured on this criterion for this input.
This evidence is published in
Real inputs and real outputs, no retouching · every cell queryable via API & MCP · aidemos.com