Zenmem
Login
๐Ÿ“š

Syllabus coverage auditor

EducationSchoolsPython ยท FastAPI

About this agent

A syllabus is loaded once as the yardstick โ€” topics, weeks expected, and the share of board marks each topic carries. Against it sits the teaching record: what was covered, in which week, and for how long. The audit reports three states rather than two โ€” covered, covered in name only, and not touched โ€” because twenty-five minutes on a topic worth twelve marks is the failure a tick-box tracker misses entirely. Gaps are ordered by marks at risk, not alphabetically, and the same gaps read as more urgent late in the term than early, because they are.

RUNTIMEPython ยท FastAPI
MEMORY TYPELong-term, per class
SDKzenmem 0.4.4
LOCAL PORT8860

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 teaching record APIโˆ’24%

Code for the coverage auditโˆ’52%

New infrastructure to stand upnone

New dependencies to install0

Schema, collection and index worknone

Sharing the teaching record with the classroom agentsame store

Reading one syllabus across every sectionone query

Before With Zenmem

What the team gained

  • The classroom agent writes the teaching record into the same store the audit reads, so a live deployment imports nothing and nobody enters a topic twice.
  • The department view is the same syllabus read across sections โ€” a filter, not a second aggregate table kept in step by a nightly job.
  • Marks weights sit on the syllabus record itself, so ordering gaps by marks at risk needs no join.
  • Three coverage states rather than two costs a comparison, not a schema column and a migration.
  • A class with no teaching record reads as covering nothing without any special-casing, because an empty scope is simply empty.

How memory is scoped

Long-term memory, filtered to one class. The syllabus and the teaching record live in the same store, which is what makes the audit a lookup rather than an import: in a live deployment the classroom agent has already written the teaching record there, so nothing has to be entered twice. The department view is the same syllabus read across every section.

How it works

The run order the collection walks through.

Load the yardstick

Topics with the weeks they need and the marks they carry. Without weights, an uncovered heavy topic looks the same as an uncovered light one.

Collect the record

In a live deployment this arrives from the classroom agent rather than being typed in.

Audit the gap

Three states, ordered by marks at risk. A thin pass is named as one instead of counting as covered.

Watch the clock

Same gaps, less term left โ€” the urgency rises even when nothing else has changed.

API surface

The whole agent, endpoint by endpoint.

Endpoints

  • POST /api/syllabus โ€” load the syllabus: topics, weeks expected, and the marks weight of each.
  • GET /api/syllabus/{syllabusId} โ€” read the syllabus back.
  • POST /api/taught โ€” record a topic as taught: class, topic, week, minutes, detail.
  • GET /api/taught/{classId} โ€” the teaching record for one class.
  • POST /api/audit โ€” covered, covered in name only, or not touched โ€” ordered by marks at risk for the current week.
  • GET /api/department/{syllabusId} โ€” the same syllabus across every section, for the head of department.

Other agents

View all