Zenmem
Login
๐Ÿง 

Revision planner

EducationStudentsPython ยท FastAPI

About this agent

The plan is built from what one student actually got wrong, not from syllabus order. Mistakes carry a severity, so a careless slip is separated from a hole, and a repeat of the same mistake outranks a one-off because a repeat is the strongest signal there is. Mastery is recordable too, or the plan keeps drilling what they already know. Topics are ordered by marks at risk, spaced so each returns just before it would be forgotten, and sized to the minutes the student actually has โ€” a five-day run-up cuts topics rather than compressing everything into unusable slivers. A mock exam re-shapes the picture, and re-planning after one produces a different plan for the same student in the same time, because the evidence changed.

RUNTIMEPython ยท FastAPI
MEMORY TYPELong-term, per student
SDKzenmem 0.4.4
LOCAL PORT8870

What changed with Zenmem?

The same agent, built twice against the same contract โ€” once on Zenmem, once on MongoDB + LangChain/LangGraph.

Before โ†’ after

Code for the evidence APIโˆ’24%

Code for plan generationโˆ’52%

New infrastructure to stand upnone

New dependencies to install0

Schema, collection and index worknone

Re-planning after new evidencea read

Holding mistakes, mastery and mocks togetherone scope

Before With Zenmem

What the team gained

  • Mistakes, mastered topics, review outcomes and mock results share one student scope, so a plan is a read over current evidence rather than a stored artefact to invalidate.
  • Reporting back that a mock went badly changes the next plan with nothing to rebuild, because no plan was ever persisted to go stale.
  • A repeat of the same mistake is recognisable within the scope, without a dedup key designed up front.
  • The marking assistant writes mistakes into the same store the planner reads, so a live deployment needs no sync job.
  • A student with no record produces an empty plan rather than a syllabus-order default, since an empty scope reads as empty.

How memory is scoped

Long-term memory scoped to a single student, holding mistakes, mastered topics, review outcomes and mock results side by side. Because they share a store, a plan is a read over the current evidence rather than a stored artefact โ€” which is why reporting back that a session went well, or that a mock went badly, changes the next plan without anything being rebuilt. In a live deployment the mistakes arrive from the marking assistant.

How it works

The run order the collection walks through.

Collect the evidence

Mistakes with severity, and repeats counted as repeats. Mastered topics recorded so they stop being drilled.

Plan against the clock

Ordered by marks at risk and sized to the minutes there actually are.

Space the returns

A topic comes back just before it would be forgotten, not on a fixed rotation.

Re-plan on new evidence

A mock or a reported session changes the order โ€” same student, same time, different plan.

API surface

The whole agent, endpoint by endpoint.

Endpoints

  • POST /api/mistake โ€” record a mistake: topic, detail, week and severity.
  • POST /api/mastered โ€” record a topic as mastered, with the evidence for it.
  • POST /api/plan โ€” build the plan for the days left and the minutes available per day.
  • POST /api/reviewed โ€” report back on a revision session; solid pushes a topic further out, shaky pulls it forward.
  • POST /api/mock โ€” record mock exam results, which can invert the order of the whole plan.