Use case · Tutor agent

A tutor that re-discovers your student every Monday is not a tutor

Recurring mistakes, learning style, the explanation that landed last week. Saved per student, read at lesson start. The tutor adapts instead of restarting.

The shape of it

Want to build a tutor agent that actually remembers your student? Here is how

Think about the best human tutor you ever had. The reason they were good was not that they knew the subject. Anyone knows the subject. It was that they remembered you. They knew you always flipped the sign when you moved a term across the equals sign. They knew the one time fractions finally clicked was when they drew it as slices of pizza. They knew you used to freeze up on word problems but you stopped doing that three weeks ago.

So every lesson picked up exactly where the last one left off. A chatbot tutor with no memory is the opposite of that. It is a brilliant stranger who introduces themselves again every single time the student opens the app, and quietly asks them to re-explain who they are and what they are stuck on.

That is the gap Korely fills. It is the notebook the good tutor keeps in their head, except it lives next to your agent and it never forgets.

How you build it

Five steps to a tutor that builds on every lesson

  1. 01

    Pick your model and framework

    You already have Claude Code or Cursor open, so wire up the tutoring loop the normal way: a system prompt that sets the tutor persona, the lesson content, and a chat endpoint your learning app talks to. This part you can build in an afternoon.

  2. 02

    Give each student their own memory scope

    When a student starts, you pass an end_user_id (or agent_id) so their memory never bleeds into another student's. One line. Now every student has a private notebook the tutor can write to and read from.

  3. 03

    Have the tutor write down what it learns as it teaches

    After a session, the agent calls korely.add() with the things worth keeping: the mistake the student keeps making, the analogy that finally landed, the topic they just moved from struggling to confident. The agent decides what matters, not you.

  4. 04

    Read the memory back at the start of every lesson

    Before the tutor says a word, it calls korely.search() for what it knows about this student on this topic. The relevant facts surface in under 50 milliseconds, so the lesson opens with "last time you nailed quadratics, today let us build on that" instead of "hi, what would you like to learn?".

  5. 05

    Let the facts age correctly

    A student who struggled with fractions in March and mastered them in May should not be re-taught fractions. Korely's facts are time-aware, so the tutor answers from what is true now, and the old "struggles with fractions" fact is kept as superseded history, not as a current belief.

  6. 06 · the part you skip

    You do not build the memory infrastructure

    You do not stand up a Postgres vector store, write the bi-temporal fact schema, build contradiction handling so "mastered" overrides "struggled", tune a hybrid retrieval pipeline, or keep a per-student entity graph in sync. That is months of work and the part nobody wants to maintain. Korely is that whole layer behind one API key, the bi-temporal graph-RAG memory, starting at 19 euro a month, so you spend your time on the teaching, not the plumbing.

The shape of the fix

Each lesson writes the timeline, the next lesson reads it back

Lesson 1, March

The student makes a mistake

  • Drops the remainder in long division
  • Agent records the struggle for this student

Korely memory

The student's timeline

  • Bi-temporal facts + entity graph
  • April mastery fact supersedes the March struggle

Lesson N, June

The tutor opens informed

  • Reads only what is true now in under 50ms
  • Builds on mastered division, no re-drill

The write happens after each session, the read happens before each session. The timeline in the middle is what makes lessons build instead of reset.

How Korely fits

The hardest part of a tutor, handed to you behind one API key

What Korely saves you is the entire agent-memory backend, the single hardest and least fun thing to build for a tutor. Anyone can prompt a model to explain quadratics. The hard part is making the tutor remember one specific human across hundreds of sessions, weeks apart, and getting the recall right every time.

To do that yourself you would build a bi-temporal fact store (facts that know when they became true and when they stopped being true), two-stage contradiction resolution (so "student has now mastered long division" correctly overrides "student struggles with long division" instead of the agent believing both), a per-student entity graph linking topics, mistakes, and breakthroughs, and a hybrid retrieval layer (full-text plus vector plus reranking) that pulls the right three facts and not the wrong thirty.

This matters more for tutoring than almost any other use case because learning is cumulative and personal. If the memory is wrong, the tutor either re-teaches something the student already owns (insulting and boring) or builds on a foundation that is not there (confusing and demoralizing).

Korely is all of that, Postgres-only, hosted in the EU, with reads under 50 milliseconds and no LLM on the read path so it is cheap and fast at lesson scale. In our own equal-budget test a reader answered 76 percent of long-horizon memory questions correctly from Korely's selected memory versus 42 percent from a same-size recency window, a 34 point swing, reproducible. That is the difference between a tutor that remembers the student and one that only remembers the last thing they said.

Show me the code

Per-student profile, written and read in two calls

tutor_agent.py python 
# ── End of lesson: the tutor notes what it learned ─────────────
from korely_memory import Korely

korely = Korely(api_key="kor_live_...")

korely.add(
    "Student struggles with sign flips on negative numbers. "
    "The pizza-slice analogy made fractions click. "
    "Best engagement in 25-minute chunks.",
    agent_id=f"school-acme/class-7a/student-{student_id}",
)

# ── Start of the next lesson: the tutor reads the profile ──────
profile = korely.search(
    "current learning gaps and what explanations work",
    agent_id=f"school-acme/class-7a/student-{student_id}",
)
# profile → "Fractions mastered (pizza-slice). Watch sign flips."

# The tutor prepends this before its first sentence, so the lesson
# opens building on what the student already owns.
ai_tutor.set_context(profile)

The same memory is reachable from any agent, Claude Code, Cursor, n8n, LangGraph, or a plain HTTP client. One agent_id per student keeps each learner's record private and easy to erase.

When a student grows

The tutor answers from what is true now, not from everything ever true

A student, Maya, spent six weeks early in the term getting long division wrong the same way every time: she kept dropping the remainder. The tutor logged it. Then one Tuesday in April it finally clicked, she solved three in a row clean, and the tutor logged that too. Now jump to June. Maya opens the app to start fractions, which lean on division.

A memoryless tutor would either ignore her history entirely, or, worse, dredge up that old "struggles with long division, drops the remainder" note and slow the whole lesson down re-drilling something she already owns. Korely's time-aware memory handles this correctly. The "struggles with long division" fact is still in the timeline, but it is marked superseded by the April "mastered long division" fact, so when the tutor asks what is true about Maya and division right now, it gets back "confident, mastered in April" and not the stale March worry.

The lesson opens with "you are solid on division now, so fractions are going to feel natural," which is exactly what a great human tutor would say, and exactly what the student needs to hear to keep her confidence. The agent answered from what is true now, not from everything that was ever true.

timeline.py python 
korely.add(
    "Maya struggles with long division, drops the remainder.",
    agent_id=f"school-acme/class-7a/student-{student_id}",
    metadata={"effective_from": "2026-03-04"},
)

# April: the concept clicks, three clean solves in a row
korely.add(
    "Maya has mastered long division.",
    agent_id=f"school-acme/class-7a/student-{student_id}",
    metadata={"effective_from": "2026-04-21"},
)

korely.search("long division", agent_id=f"school-acme/class-7a/student-{student_id}")
# → "mastered" (current). March struggle marked superseded in the graph.

# Retrieve the full arc for a parent-teacher review:
# GET /v1/memories/{id}/history  -> full timeline with effective_from dates

Frequently asked

Tutor memory, common questions

How does the tutor remember a student between sessions that are weeks apart? +

Each student gets their own memory scope, passed as an end_user_id. After a lesson the agent writes what it learned with korely.add(), and at the start of the next lesson it reads it back with korely.search(). The gap between sessions does not matter. Whether it is the next day or six weeks later, the tutor opens the lesson already knowing where the student left off.

What stops the tutor from re-teaching something the student already mastered? +

This is exactly what time-aware facts are for. When a student moves from struggling to confident on a topic, that mastery fact supersedes the old struggle fact in the timeline. The old one is kept as history for an audit trail, but when the tutor asks what is true now, it gets the current state. So the lesson builds on what the student owns instead of drilling it again.

Do I have to build the memory store myself? +

No, that is the whole point. You build the tutor, which you can already do with Claude Code or Cursor. Korely is the memory layer behind one API key: a bi-temporal fact store, contradiction handling, a per-student entity graph, and hybrid retrieval, all hosted for you. You skip months of backend work and the part nobody enjoys maintaining.

Is it fast enough to read memory on every single lesson open? +

Yes. Reads run in under 50 milliseconds because there is no LLM on the read path, just hybrid search over an indexed store. The tutor can pull the relevant facts about this student before it generates its first sentence, with no noticeable wait, even across thousands of students.

Where is student data stored, and can I delete it? +

In a managed Postgres store hosted in the EU, with a vector and graph index. You read and write it over the REST API or the Python and Node SDKs, nothing to host yourself. Every student's memory is scoped to their own end_user_id, and you can export or erase a student's entire memory with one call, which matters when you are handling learner data.

How is this different from just stuffing the chat history into the context window? +

A context window is a same-size recency window: it holds the last things said and drops everything older. In our own equal-budget test, a reader answered 76 percent of long-horizon questions correctly from Korely's selected memory versus 42 percent from a recency window of the same size. For a tutor that is the difference between remembering a breakthrough from two months ago and only remembering this morning's chat.

Build the tutor, let Korely remember the student

The Python and Node SDKs are live and the Hobby tier is free, so sign up, grab an API key, and run your first memory write in minutes. Paid plans start at 19 euro a month when you outgrow it.

See pricing and start free

Looking for a different shape? See the other nine use cases →