Learning and tutoring copilots

A good human tutor's biggest advantage is that they remember the student. They know which topics clicked and which ones didn't, that the student grasps ideas faster through examples than definitions, that the thing they got stuck on three weeks ago is worth circling back to. Most tutoring copilots have none of this. Each session begins as though they've never met the student, so the personalisation that makes tutoring work never gets off the ground.

The model can explain almost anything clearly. What it can't do unaided is remember a particular learner across sessions: what they've covered, where they struggle, how they prefer to be taught. This page is about giving a tutoring copilot per-student memory, so the help it gives adapts to the person rather than resetting every time they show up.

The problem

Personalised learning depends on knowing the learner, and knowing the learner depends on remembering them over time. A stateless tutor can't do that. It can deliver a perfectly good explanation in a single session, but it has no idea whether the student saw the same material last week and still didn't get it, or aced it and is ready to move on. Every session is the first session, which is the opposite of how learning works.

Stuffing prior sessions into the prompt fails the way it always does. A student's history over a term is far more than a context window holds, so the tutor would be dropping context arbitrarily, which for a tutor means forgetting exactly the struggle it should be addressing. Keeping raw session logs in a database gives persistence but not understanding: the tutor needs to know that the student now grasps a concept they previously struggled with, not merely that both statements appear somewhere in the record. Tracking a learner's evolving understanding is an entity resolution problem, and a tutor that keeps treating a mastered topic as a weakness, or a corrected misconception as still held, is suffering memory drift in a way that directly undermines the teaching.

And every student's record has to stay their own. In any real tutoring product there are many learners, and one student's progress, struggles, and history must never bleed into another's session.

What Exabase unlocks

With per-student memory underneath, the copilot starts behaving like a tutor who actually knows the learner.

It adapts to where the student is. Because it remembers what they've covered and how it went, it doesn't re-explain what they've mastered or rush past what they haven't. A concept the student struggled with last session gets revisited, in a different way if the first approach didn't land, rather than being assumed learned and left behind.

It teaches the way the particular student learns. If they've consistently understood better through worked examples than abstract definitions, the copilot leans that way, because it remembers that about them. The style adapts to the person rather than applying one default to everyone.

It builds on what came before. A session picks up with awareness of the last one, so progress accumulates into a path rather than a series of disconnected encounters. The student experiences continuity, which is most of what makes a tutor feel like a tutor rather than a search engine with manners.

How it works

Three primitives carry a tutoring copilot, with Bases doing the per-student isolation that makes individual learning records possible at scale.

Bases

A Base is a fully isolated environment with its own memory, storage, and search. You create one per student, so each learner's record, what they know, what they struggle with, how they learn, lives in a space that contains only them. One student's progress can't surface in another's session, because the isolation is structural rather than a filter applied at query time. You get this per-student separation from a single API call instead of building your own partitioning, which is what makes it practical to run thousands of individual learners. The same isolation pattern underpins any multi-tenant SaaS product.

Memory

Exabase Memory, scoped to each student's Base, holds the evolving picture of the learner: topics covered and how well, recurring sticking points, demonstrated preferences, misconceptions to watch for. You send in the session interactions and Exabase extracts what's worth keeping, so you're not hand-coding a model of each student's progress. The contradiction handling is what makes it pedagogically sound: when a student masters something they once struggled with, the new state supersedes the old, so the tutor stops treating a solved difficulty as an open one. This is the behaviour that turns a memory layer into something that genuinely tracks learning rather than just logging sessions.

Resources

Resources hold the course material the tutor draws on: textbooks, notes, problem sets, reference material. Stored as Resources, they're indexed for Deep Search, so the copilot can find the relevant passage or example by meaning when a student asks about a specific topic. If the material arrives as PDFs, Extract turns it into clean, searchable text first. Course material is typically shared across students, so it usually lives in a common Base that every student's copilot can search, kept separate from the per-student memory.

Example architecture

The structure is simple, and the split between shared material and private progress is the key idea.

One Base per student for their private learning record, plus a shared Base holding the course material every copilot can search.

As sessions happen, send the interactions to Memory within the student's Base, where Exabase extracts and resolves their evolving understanding. Course material is prepared once: run it through Extract if needed and store it as Resources in the shared Base.

On each session, the copilot retrieves memory scoped to the student for their current state, and runs a Deep Search across the shared course material for whatever the session calls for. Both go into the prompt.

Each student's progress flows into and out of their own sealed Base, the course material sits in a shared Base everyone can search, and the copilot reads from both on every session. The picture of each learner deepens on its own.

What compounds over time

Tutoring is close to a pure case of compounding value, because the entire point is that the help improves as the relationship lengthens.

A copilot meeting a student for the first time has nothing to personalise on and behaves like a generic explainer. The same copilot after a term of sessions knows the student's strengths, their recurring difficulties, and how they learn, and tailors accordingly. Because the memory self-organises, that accumulated understanding stays accurate as it grows, mastered topics getting marked as mastered, rather than turning into an unwieldy log. Reliable, current context also keeps the tutor from teaching off a stale picture, and that reliability strengthens as the record fills out.

For a product, the consequence is the same one personalisation always brings: a student who has built up a term of learning history with a copilot has a real reason to keep using it, because that history is what makes it good for them specifically, and it doesn't transfer to a fresh start elsewhere. The memory is what makes the personalisation real, and the personalisation is what makes it stick.

Who's building this

Teams building tutoring copilots, adaptive-learning platforms, language-learning apps, professional-training tools, and any educational product where the agent works with the same learner repeatedly and ought to adapt to them.

For a related pattern, the AI flashcard generator example builds a learning tool on Exabase end to end, and the multi-tenant SaaS use case covers the per-student isolation pattern in general terms.

Get started

Start with the getting started guide, then memory scoping to see how per-student isolation works and creating memories for the core loop. The AI flashcard generator example is a concrete build to learn from, and there's a free tier to start against.

FAQs

How does the tutor know what a student has already learned?

It remembers across sessions. Each session's interactions go to Memory scoped to that student, where Exabase extracts what they covered and how it went. On the next session the copilot retrieves that context, so it knows what's mastered, what's shaky, and what to revisit.

What happens when a student finally masters something they struggled with?

The new state supersedes the old through entity resolution. A topic that moves from struggle to mastery is updated rather than kept as an open difficulty, so the tutor stops drilling something the student already has.

How are different students kept separate?

Each student gets their own Base, which fully isolates their learning record from every other student's. Memory operations scoped to a student's Base can only see that student's data, so one learner's progress never appears in another's session.

Can the copilot use our course material?

Yes. Store textbooks, notes, and problem sets as Resources, typically in a shared Base, and they're indexed for Deep Search. The copilot finds the relevant passage by meaning when a student asks about a topic. PDFs can be run through Extract first.

Does the shared course material mix with a student's private progress?

No. Course material lives in a shared Base that every copilot can search, while each student's progress lives in their own isolated Base. The two are kept separate, so shared content is searchable by all while individual records stay private.

Is retrieval fast enough for a live tutoring session?

Simple memory retrieval runs around 200ms, fast enough to sit inside a back-and-forth tutoring exchange without a noticeable pause.