How a kids' chatbot grew into a home AI architecture

It started as a toy

Earlier I wrote about why the house got its own chatbot: a kid-safe assistant that lives at home and never sends a conversation off to a cloud service. The first version was a weekend project. A friendly voice on a tablet, a splash screen, an answer read aloud. The children loved it, the grown-ups nodded, and for an afternoon it looked finished.

It was not. What follows is the story of what happened next: how a weekend toy turned, over about two months, into a proper piece of engineering. I will start where anyone would, then let the technical side rise slowly. You do not need to be an engineer to follow it.

A demo is easy. The everyday is hard.

A demo only has to work while you are watching. A tool a seven year old opens every day has to work when nobody is watching, including on the day the question is not cute. That gap, between charming on a good day and safe on a bad one, is the entire reason the toy had to grow up.

The trap is that the first version seemed fine. It answered well, it picked a gentle tone, it declined the odd awkward question. Good behaviour on a good day tells you almost nothing, and “almost” is not a word you want anywhere near a child.

Rules you can bend, and rules you cannot

Here is the idea the whole rebuild turned on, in plain terms.

The first version kept its rules as instructions written for the model: be careful about this, avoid that. Think of it as a note on the fridge. A polite, capable reader follows a fridge note nearly every time. Nearly. And the rules that protect a child are exactly the ones that have to hold every single time, not nearly.

So the rules that truly matter were taken off the fridge and built into the walls. A rule written as a sentence is a request. A rule written as code is a wall: the assistant cannot walk through it, cannot be talked around it, cannot have an off day. Instructions still exist, but only for things that are honestly a matter of judgement, like how gently to phrase an answer for a five year old. Anything with a hard edge became a wall.

That one move is what turned a toy into an architecture. Once the important rules live in code rather than in wording, you need real structure around them: something that runs the conversation, separate helpers it can call on, and guards that stand in the way whether the assistant likes it or not.

The shape of it

Here is the request path, with the plumbing left out. Everything below runs on one machine at home. Nothing in this diagram reaches the internet except the safe web search, and even that is stripped of anything personal before it leaves.

The app core is the only part that talks to a child. The model, the image and vision services, the memory, and the voice pipeline are all things the core calls when it decides to, and the guards live inside those calls. That separation is the whole point: the model is a supplier of text, not the thing in charge.

A plain chat turn

Most turns are simple. A child asks something, the assistant remembers a little, thinks, and answers out loud. What you do not see is that the answer is scanned on the way out before a single word reaches the screen.

The age profile is not a personality, it is a dial: same question, different vocabulary and length depending on who is asking, with a firm no baby-talk rule for the oldest bracket. The memory is small on purpose, and I will come back to why it forgets.

A photo, and the guard that will not open

The interesting turns involve a picture. A child points a tablet at a bug in the garden and asks what it is. Now content is coming in from the outside, and this is exactly where a prompt-based system fails quietly. The architecture does not ask the model to be careful with the image. It refuses to let the model see anything that has not passed a gate first.

The gate is fail-closed: if the screening service is unsure or unavailable, the image does not pass, full stop. The same gate stands in front of every picture the assistant generates, so a drawing it makes for a child is checked with the same suspicion as a photo a child uploads. The model never gets to argue with the gate, because the gate is not part of the conversation. It is a wall.

Underneath, the layers stack in a way that is easy to keep honest. Structural guards are code and cannot be bypassed: the image gate, server-side link controls, quotas, a bedtime curfew. Judgment lives in the prompt: tone, declining a subject, nudging toward a parent. Capabilities are the tools the model may call, each one a contract with the guards baked into the executor. When the model improves, the judgment layer gets re-checked and the structural layer does not move. That is what makes a model upgrade a quiet event instead of a fire drill.

It remembers, then sleeps on it

Each child has a private memory, so a dragon named in spring is still known in summer. But the assistant does not hoard transcripts. Every night it re-reads the day, keeps a few small facts per child, and drops the raw conversation. Keep the gist, forget the noise. If that sounds like what a brain does during sleep, that is not a metaphor I reached for, it was simply the correct engineering answer, which is better.

The hardware, kept boring on purpose

The temptation, once a project grows, is to talk about the machine. I will resist it. Everything here runs on a single box at home, on open-weight models, with a running cost that rounds to electricity. The point of the architecture is that the interesting parts are not the silicon, they are the boundaries: what may call what, what is checked before it moves, and what is never allowed to leave. Swap the box for a bigger one and not a single one of those boundaries changes. That is the sign the design is in the right place.

If you want the model-fits-on-a-small-card story, it lives in its own article. Here the hardware is deliberately a footnote.

From a toy to a house rule

The proof of concept took an afternoon. The architecture took two months, and almost none of that time went into making the assistant smarter. It went into making it safe by construction: moving every hard rule out of a sentence and into code, putting guards in the path instead of hopes in a prompt, and drawing a hard line around the house that nothing crosses.

A toy answers questions. An architecture decides what a child is allowed to receive, every time, whether the model cooperates or not. That is the spine the toy grew, and it is the reason it is still running.