-
-
Earlier prototype: a synthetic memory session and the actual MCP handshake.
-
Earlier prototype: explicit lease correction, preserved history and an unrelated fact left unchanged.
-
Earlier prototype: choosing the memory and version before a correction.
-
Current version 1.2: a real workshop plan calculated from the stored brief, with twelve participants.
-
Room reduced to six seats: choose two groups or an explicit waiting list; nobody is silently removed.
-
Current version 1.2: two groups of six, checked export, current brief version and both declared sources.
An assistant can remember a corrected fact and still hand over a decision made from the old one. I built Mnemo for a concrete decision: helping a recurring workshop organizer understand what a changed constraint breaks, choose an adaptation and receive the current running order.
See the decision change
In the fictional example, I am preparing a workshop for twelve people. The first 45-minute session fits a twelve-seat room. Then the room changes to six seats.
Mnemo marks the previous plan obsolete and asks me to choose: keep everyone in two consecutive groups, or keep one group and a visible waiting list. Keeping everyone now takes 105 minutes, an extra hour; keeping one 45-minute session leaves six people waiting. Mnemo shows those consequences before asking me to decide. It does not quietly remove participants. In this walkthrough, I choose two groups. The new running order schedules six people at 10:00–10:45 and six at 11:00–11:45, including the fifteen-minute transition within the available window. A window that cannot fit the sessions is refused.
The result is a usable text run sheet carrying the brief version and the sources I declared. The same screen lets the judge edit the constraints, inspect the earlier version and try another decision.
The check belongs to the server
Preparing a plan produces an inspectable preview and an opaque receipt. Downloading calls a separate MCP tool. That tool checks the current brief version, its hash and the local history, then generates the official file under the same lock used by corrections.
This matters even when a client has checked the memory correctly: a correction can arrive between that read and its local export. I reproduced that sequence. The cached preview still describes twelve seats; requesting its old receipt from Mnemo returns an explicit version conflict. An unchanged plan and a plan prepared from the new version both export successfully. There is no silent recalculation of the user's decision.
Versioned memory is an established idea. My contribution in this prototype is the working connection between a remembered fact, a prepared decision and the server operation that hands it over.
How I built it
For the Alexa+ track, I built a self-hosted MCP server and a browser simulation of the assistant interaction. The browser makes real Streamable HTTP requests using the tested Python SDK. Its secondary protocol panel exposes initialization, eight discovered tools and their actual responses. The planner is deterministic; the demonstration needs no model key or paid inference.
SQLite stores facts, declared references and versioned corrections. Trusted local mode preserves facts across reconnects and restarts. The public demo gives each visitor a separate temporary store for fictional examples. The interface is available in English and French, with explicit choices, connection recovery and visible obsolete results.
What changed during the hackathon
The early prototype foregrounded a memory chat and protocol messages. Testing exposed ambiguous recall, confusing correction targets and a weak explanation of usefulness. I made memory selection explicit, kept correction and search-index updates in one transaction, and rebuilt the experience around a task with an observable consequence. The new export check addresses a separate read-to-action race.
The server version passed 61 Python tests and 78 subtests; targeted JavaScript checks cover the interface and its conflict recovery. I also exercised the actual browser and the public HTTP endpoint, including valid exports, a direct request with a stale receipt and a separate visitor who cannot access it. The repository includes the tests and friction log.
I also compared the same five conditions with an independently implemented deterministic tool that correctly checks version and hash at export. Both tools tied all five, including the impossible window and a change after a correct fresh read. That result matters: the contribution I need to defend is the specialized MCP experience and the explanation of the decision, rather than a new scheduling algorithm. User time savings and demand have not been measured.
Try it
Public synthetic demonstration: https://yannabadie-mnemo-review-before-acting.hf.space/?lang=en
Choose Prepare a workshop, then Change room: 6 seats, make an adaptation decision and download the current plan. The details show the current version and declared sources.
Source, MIT license and local instructions: https://github.com/yannabadie/mnemo
Run python server.py --demo after installing the pinned requirements, then open http://127.0.0.1:8799/. The hosted demo now runs independently of my Mac on CPU Basic in an existing Hugging Face account. Free hardware can sleep; open https://huggingface.co/spaces/yannabadie/mnemo-review-before-acting and allow startup if needed. The original Mac tunnel remains a secondary route, and the local instructions are the reproducible fallback. No continuous uptime is guaranteed.
Scope
The check concerns the brief stored in Mnemo at the instant of export. A change in an external email becomes visible only after that brief is corrected. Downloaded copies cannot be revoked, and sources remain declarations rather than authenticated evidence. The experience is a browser simulation with real MCP tools; no native Alexa device connection, room booking or invitation sending is claimed. Customer demand and time savings remain to be established.
Log in or sign up for Devpost to join the conversation.