What building Ziggyloo taught me about designing an AI tutor product for real learners

Here's what most teams miss when they try to build an AI tutor: the model is the least interesting part of the problem. At 10:47 on a Tuesday night, a learner in a kitchen somewhere is staring at a fraction problem while the tutor waits. The learner is tired, the worksheet is half done, and a confident wrong explanation could make tomorrow harder. Building Ziggyloo taught me the central lesson of this whole category: the real product is the system that decides when to explain, when to ask, when to wait, and when to admit it doesn't know.

I learned this by shipping a live AI education platform, not by writing a white paper about one. Real learners don't arrive with clean prompts, unlimited patience, or a reliable sense of what they don't understand. They arrive with partial work, distractions, spelling mistakes, and questions that shift halfway through the answer.

That changes everything about how you should approach building an AI education platform. You're not wrapping a language model in a friendly interface. You're designing a learning environment with an unpredictable reasoning engine inside it.

The first lesson: a correct answer can still be a bad teaching moment

The conventional wisdom says an AI tutor should answer accurately and explain the reasoning. Sounds sensible. Until you watch a learner ask "Why do I carry the one?" and receive a full lecture on place value, addition algorithms, and historical notation.

The response may be correct. It may even be well written. It is still a poor teaching move if the learner only needed one missing step.

When I built Ziggyloo, I had to think about the learner's state before thinking about the answer. A learner who submits "I don't get it" isn't making a normal information request. They may be confused about the concept, embarrassed by a mistake, rushing before bed, or testing whether the tutor will just hand over the answer.

Those states require different actions. A useful tutor might ask for the last step they understood, offer a small hint, or restate the problem with simpler numbers. It might pause and ask whether the learner wants a hint or a worked example.

Learning science has supported this distinction for years. Retrieval practice, described in research by Jeffrey Karpicke and Henry Roediger in 2008, helps learners retain information more effectively than repeatedly rereading material. That doesn't mean every interaction should become a quiz. It means the tutor should create room for the learner to retrieve, predict, and explain.

A useful response policy starts with a few questions:

• What does the learner appear to understand already?
• What is the smallest missing step?
• Is the learner asking for help, reassurance, or an answer?
• Would another explanation help, or would it add more noise?

The answer is not always more content. Often, it's less.

Build the interaction around evidence of learning

An AI tutor product needs a working definition of progress. "The learner had a good conversation" is not enough. A long session can feel helpful while producing no durable understanding.

I think about learning evidence as small signals collected across a session. Did the learner attempt the problem before asking for help? Did they fix the same error after a hint? Can they solve a similar problem with different numbers? Can they explain why their answer works?

These signals are more useful than message count or time spent in the product. A learner who exchanges 30 messages with a tutor may be engaged, confused, or simply asking the model to do the work. You can't tell from activity alone.

This is where a Learning State becomes useful. It's a simple working record of what the system believes the learner knows, doesn't know, and may be ready to practice next. It shouldn't pretend to be a perfect psychological profile. It's a product control surface for making the next interaction more helpful.

For a learner working on fractions, the state might track:

• Recognizes numerator and denominator.
• Can compare fractions with the same denominator.
• Confuses multiplication and addition when finding a common denominator.
• Has succeeded twice with visual hints.
• Has not yet solved a new problem without support.

That record changes the next prompt. Instead of saying "Here is another explanation of fractions," the tutor can ask the learner to compare 3/8 and 5/8, then observe whether the response is independent.

The practical design move is to store claims with evidence. Don't write "understands fractions" because a learner answered one question correctly. Store the example, the support level, and the date. A correct answer after the tutor supplied every step is not the same as an independently correct answer.

And don't hide this state inside a giant prompt. Keep it inspectable. When the tutor behaves badly, you need to see whether the problem came from the model, the learner record, the task design, or the transition between them.

The tutor has to resist the urge to perform

Language models are good at producing smooth explanations. That strength is also a trap. A polished answer can look like teaching while the learner does nothing.

The mistake I keep watching teams make is treating conversational warmth as evidence that learning happened. Friendly wording matters, especially when a learner is frustrated, but warmth can't replace a well-timed demand for thinking.

A tutor should sometimes be a little inconvenient. It should ask "What do you think the next step is?" before explaining. It should request a prediction before revealing the result. It should notice when a learner is copying a pattern without understanding the reason behind it.

Consider a real product scenario. A learner named Jordan is working through a science question about evaporation. Jordan asks, "Does water disappear when it evaporates?" A weak tutor says, "Yes, water turns into vapor and enters the atmosphere." A better tutor asks what Jordan thinks happens to the water particles, then uses that answer to decide whether to introduce particle motion, state change, or a simple kitchen example involving a wet towel.

The second tutor doesn't merely deliver more accurate text. It creates an opportunity for retrieval and explanation.

Research by Dunlosky and colleagues in 2013 ranked practice testing and distributed practice among the more useful learning techniques, while highlighting the limits of passive rereading. That has a direct product implication: the tutor should not make every turn an explanation turn.

A strong interaction may follow this pattern:

1. Ask the learner to attempt or predict.

2. Identify the smallest error or missing idea.

3. Give a hint rather than the whole solution.

4. Ask for a similar attempt.

5. Check whether the learner can transfer the idea.

This is not a rigid script. It's a bias toward learner action. If the learner is stuck, the tutor can provide more support. If the learner is guessing well, it can step back.

Once you frame it this way, the interface matters less than the turn-taking policy. A beautiful chat screen can still produce passive learners.

Safety means managing confidence, not just blocking content

When people discuss safety in generative AI learning tools, they usually focus on prohibited content and inappropriate language. That work matters. It's not the whole problem.

For an AI tutor, a confident wrong answer is a safety issue because it can install a misconception while sounding authoritative. The risk sharpens when the learner has no adult nearby to push back.

Here's the part most people miss. In one design scenario, a learner asks whether heavier objects fall faster than lighter ones. The tutor gives a simple but inaccurate answer because it confuses everyday air resistance with the underlying physics principle. The learner remembers the explanation, repeats it in class, and now carries a tidy misconception that is harder to remove than an unanswered question would have been.

An AI tutor needs a Trust Boundary around its claims. That boundary doesn't mean the system refuses every uncertain question. It means the product decides where the model can answer directly, where it should qualify, and where it should point toward a teacher, parent, or other human review.

For each subject area, define:

• Claims the tutor can explain from approved reference material.
• Questions that require a clarifying question before an answer.
• Situations where the tutor must say it is unsure.
• Signals that suggest the learner needs a human adult.
• A way to report and review incorrect explanations.

The 2023 UNESCO guidance on generative AI in education called for human-centered use, age-appropriate safeguards, and attention to data privacy. Those ideas become practical only when they show up in product behavior.

Don't tell learners the tutor is "always right." Don't let confidence sound like competence. Show uncertainty in plain language: "I may be mixing up two ideas here. Let's check the definition before we continue."

Then log the moment. A safety review should include wrong answers, overconfident answers, repeated confusion, and failures to ask for clarification. A blocked harmful request is only one slice of the record.

Personalization needs limits and a reason

Personalization is one of the most repeated promises in AI education. The pitch is attractive: every learner gets an experience matched to their level, pace, and interests.

But personalization can become a pile of guesses. If the product infers that a learner is "bad at math" because they struggled during one late-night session, the system may lower the challenge when the learner actually needs rest, a clearer example, or a different representation.

Real personalization should answer a specific product question. What decision changes because the system knows this about the learner?

For example, if a learner named Priya solves visual geometry problems but stumbles on text-heavy prompts, the tutor might present the same concept with a diagram before introducing formal language. If Priya then succeeds, the product has evidence that representation affected performance. That's more useful than storing a broad label like "visual learner." (And yes, the difference between those two things is the whole ballgame.)

The system should also forget or weaken old assumptions. A learner can improve. A learner can have a bad day. A learner can move from needing worked examples to needing challenge. Stale memory turns yesterday's support into today's ceiling.

A practical learner record can include:

• Recent demonstrated skills, not permanent labels.
• The type of support used in each successful attempt.
• Errors that have repeated across different tasks.
• Topics the learner chose to revisit.
• Evidence that an earlier difficulty has changed.

Privacy matters here. Collect the minimum information needed for the teaching decision, separate account identity from learning records where possible, and make deletion understandable. The U.S. Department of Education's 2023 report on artificial intelligence and the future of teaching and learning emphasized privacy, transparency, and human oversight. Those aren't policy words that belong only in a compliance document. They should shape the data model.

What I'm telling you is simple: personalization is not the number of fields in a learner profile. It's the quality of the next teaching decision.

Shipping means observing learning, not just uptime

A normal software dashboard can tell you whether requests succeeded, how fast pages loaded, and whether errors spiked after a release. An AI tutor product needs those signals plus evidence about the interaction itself.

When I shipped Ziggyloo, the hard questions weren't just about whether the model responded. I needed to know whether it answered too quickly, gave away solutions, repeated an explanation that already failed, or missed that the learner was stuck.

That requires an Eval Loop connected to real product behavior. Start with a small set of representative sessions. Include a learner who gives incomplete answers, a learner who changes subjects mid-conversation, a learner who asks for the final answer, and a learner who repeats the same misconception across three turns.

Review each session for concrete outcomes:

• Did the tutor identify the learner's actual question?
• Did it preserve an opportunity for the learner to think?
• Was the explanation factually correct?
• Did the next task test transfer rather than repetition?
• Did the interaction end with evidence of progress?

Use model-based grading carefully. A second model can help sort obvious failures, but human review is still needed for subtle teaching errors. A response can be factually correct and educationally poor. Automated scoring often misses that distinction.

Track product metrics that connect to learning behavior:

• Independent success rate after a hint.
• Rate of repeated errors across similar tasks.
• Percentage of sessions that end in a learner attempt.
• Hint-to-answer ratio.
• Teacher or parent reports of incorrect explanations.

Don't optimize for session length without a reason. A long session may signal interest, but it may also mean the tutor is failing to resolve confusion. Don't optimize for message volume either. More turns can mean the system is making the learner work too hard for a simple clarification.

The practical move is to review a fixed set of sessions every week, label failures by type, and connect each label to a product change. That's how shipping AI products becomes a learning process for the team, not just for the learner.

Design for the adult who is nearby, too

A learner may be the person typing, but the product often exists inside a larger relationship. A parent may be paying for access. A teacher may have recommended the tool. An administrator may worry about privacy, accuracy, and whether the system encourages shortcuts.

Ignore those people and the product loses trust, even when the learner likes the chat.

Imagine a parent in Columbus opening a session summary after their child has gone to bed. They don't need a transcript full of model jargon. They need to know what the learner practiced, where the system was uncertain, and what question might be useful tomorrow morning.

A teacher in Phoenix may need a different view entirely. They may want to see whether several learners are making the same mistake with decimals, without reading every private exchange. The product should support that need without turning the learner into a surveillance record.

Design the surrounding experience with clear boundaries:

• Give adults a concise progress view, not an overwhelming conversation archive.
• Explain when the tutor was uncertain or corrected itself.
• Make it easy to report a bad answer.
• Provide suggested offline questions that continue the learning.
• Avoid presenting inferred traits as facts.

This is where building an AI education platform becomes a full systems problem. The chat is the visible surface, but trust is built through reporting, correction, permissions, privacy, and support.

I've spent years shipping technical programs across complex organizations, and the same pattern keeps returning: the visible feature gets all the attention while the handoffs determine whether the feature survives contact with real use. In education, those handoffs include learner to adult, model to product logic, and product team to correction process.

So the deeper lesson is that an AI tutor isn't finished when it can explain a topic. It's finished when learners can use it safely, adults can understand it, and the team can improve it without guessing.

Practical next steps for your AI tutor product

If you're building generative AI learning tools, start with one narrow learning task. Not "teach every subject to every learner." Choose a specific skill: comparing fractions, identifying the main idea in a paragraph, explaining the water cycle.

Then write 20 representative learner scenarios. Include correct attempts, partial attempts, copied answers, frustration, silence, and requests for the final answer. Run those scenarios through the product before you add another subject.

Your first release should answer five questions:

• What does the tutor do before giving an answer?
• How does it record evidence of learning?
• How does it handle a confident mistake?
• How does a learner or adult report a problem?
• What does the team review after a real session?

Build the correction path early. A tutor that can improve after a reported error is more useful than one that merely sounds polished on launch day.

Start small. Watch real sessions with permission. Change one teaching behavior at a time. Then measure whether learners can do more without help.

The model is not the tutor. The learning loop around the model is the product.

FAQ

What makes an AI tutor product different from a chatbot?

An AI tutor product tracks learning evidence, manages hints and explanations, and adapts the next task based on demonstrated understanding. A chatbot can answer questions without checking whether the learner can apply the idea independently.

How should an AI tutor handle a learner who asks for the answer?

It should usually offer a hint or ask what the learner has tried before giving the full solution. If the learner remains stuck, the tutor can show the solution in steps and then provide a similar problem that the learner solves independently.

What should teams measure when building an AI education platform?

Measure independent success after support, repeated errors, factual corrections, hint-to-answer ratio, and the percentage of sessions that end with a learner attempt. Session length and message count are useful context, but neither proves learning.

How can AI learning tools avoid teaching incorrect information?

Use approved reference material where appropriate, define topics that require extra caution, test representative questions, and make uncertainty visible. Give learners and adults a simple way to report wrong answers, then review those reports in a recurring evaluation process.

What is the best first step for shipping an AI tutor?

Choose one narrow skill and write 20 realistic learner scenarios before expanding the product. Use those scenarios to test teaching behavior, safety, learner progress, and correction paths from the first release.