Evaluate Memtru against your system

Memtru runs locally or in your CI. The dashboard receives explicitly uploaded, sanitized reports. It does not automatically connect to your agents or run arbitrary remote workloads when you register.

Start independently

Follow Test your first real AI agent for a standalone example download and the concrete mapping needed to test your own sandbox. Use the evaluation worksheet to measure setup effort and useful outcomes rather than counting a synthetic demonstration as adoption.

pip install memtru
memtru demo --afterlife

This runs the built-in synthetic demonstration. It proves the scenario on that store, not your application. Review the HTTP integration proof for an example of crossing an application boundary.

Connect an authorized sandbox

Choose one workflow, test owner and isolated test namespace. Use only synthetic data. Your team supplies scoped access to the sandbox and confirms which memory copies deletion is intended to cover. Do not send credentials or customer records through contact email.

An adapter maps existing Memtru operations to your application's write, search, read and delete interfaces. The delayed-write scenario additionally needs a controlled way to hold and resume an actual pending update. Observation endpoints must be read-only: searching for the fixture must not create a new copy of it. See adapter contracts and Afterlife.

The reference HTTP customer example has two deterministic agent handlers and a separate worker process with persistent jobs. A real application's scheduling, identity model and storage paths need their own mapping. A chat-only endpoint does not establish visibility into hidden stores, caches or downstream copies.

Agree acceptance before testing

• Application workflow and memory provider/version.
• Principals, allowed namespace, retrieval surfaces and deletion scope.
• Lifecycle event and consistency window, including provider deadlines.
• Cleanup and recovery owner if a call cannot be cancelled.
• Reports, reproduction instructions and any agreed verification after a fix.
• Scope, price and access arrangements confirmed in writing before paid work.

The deliverable is an observed result, including PASS, FAIL, ERROR, INCONCLUSIVE or SKIPPED when appropriate. There is no guarantee a defect will be found. Infrastructure failure and missing positive controls must not become PASS.

Run repeatedly

Keep the reviewed adapter and config in your repository. Run memtru test in CI against the sandbox with provider deadlines and clean up only the test namespace. Use a project-scoped dashboard token supplied through your CI's secret store if you explicitly choose to upload. Do not put keys in a command, report or repository.

Review the result

A FAIL documents visibility of the synthetic fixture on an exercised path. After your team changes the application, repeat the same scenario and compare reports. A PASS describes the tested surfaces, principals and timing. It does not prove physical erasure, regulatory compliance or absolute security.

To discuss fit, use the evaluation contact page. No automatic hosted scan, card payment or customer-data transfer occurs on that page.