Revision planner
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.
What changed with Zenmem?
The same agent, built twice against the same contract โ once on Zenmem, once on MongoDB + LangChain/LangGraph.
Before โ after
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.