An agent for a teenager

The question

The lab’s agent works for the lab. On 14 March 2026 the founder asked for a second one, for a teenager in his household: not a copy of the lab’s agent with a different name, but an agent of his own, on its own machine, with its own memory, reachable where he already is, in a messenger. The teenager would decide what it is for. The lab would build what he asked for, and the lab’s own agent would do the building, from the other side of the house network.

The question underneath was whether the lab’s way of working, measure before you claim, file the failure, keep the guard, transfers to a product with exactly one user, who is not the person paying for it and who owes nobody feedback.

What was built

A small virtual machine, four gigabytes of memory, running an open-source agent framework and a messenger bot.The lab’s own agent set it up, and has maintained it since: updates, model changes, the guards. Between March and September the underlying language model changed four times, from a fast small model to a reasoning model with a million-token context, each time for a measured reason.

What the teenager uses, as of the day above:

• A morning briefing every day at 06:45: weather and what to wear, the day’s timetable, a countdown to the next exam, a few lines of news.
• A timetable sync, weekdays at 07:00, that reads the school’s timetable system and writes the day into his calendar. In the holidays it now says so, instead of failing.
• Trains and buses. “How do I get to X”, “when is my next train”, “when do I have to leave to be there by half past nine”: connections and live departures with delays, for the whole country’s rail and local transport. If he sends his location from the messenger instead of typing a stop, the agent routes from the coordinates. Built as the lab’s own tool server against a public timetable interface, four tools, no key needed; the skill that teaches the agent when to use it was, at 3,900 characters, the largest single block of its persona before it was split out.
• His school’s cloud: worksheets and slides from the school’s document system, read on request instead of guessed from memory.
• A vocabulary drill in the language he is learning, weekdays at 16:30, five to ten words from the pool his school uses.
• One maths problem a week, on Sunday evening, from competition classics and from the numbers in the games he plays, as a bridge from school maths to what a university would expect.
• New music on Thursday mornings: releases from the artists he listens to.
• A game master, described below, because it is the part that is unlike anything else the lab has built.

Seventeen skills in all, written as short instruction files the agent reads when the topic comes up. Seven timers run without anyone asking. Behind the skills sit seven small tool servers the lab wrote for this machine, one each for transit, the school cloud, the music service, the calendar, two game APIs, and his memory; the agent calls them the way the lab’s agent calls its own instruments. The agent keeps its own memory in a separate instance of the lab’s knowledge system, on the same small machine, with its own graph database rather than a partition of the lab’s: 498 memories were migrated into it in August, and since then what he tells the agent lives there, reachable only from that machine, not in the lab’s graph. A knowledge search from his agent runs against a positive list of subject domains, so that it cannot reach the founder’s notes by accident; that list exists because on 11 August it did.

The game master

The agent runs a pen-and-paper role-playing game in a group chat with the teenager and his friends. The rules are a light system of the lab’s own, and the world was built in a first session with him alone: its lore lives in a file the agent reads and extends. What makes it more than a chatbot telling a story is a set of small tools, each built in a day in August: one on a question the teenager asked at the table, the others on the founder’s asking.

• Dice you can audit. The teenager asked whether the rolls were real or adjusted to give him a good story. They had always been real; what was missing was proof. The dice tool now refuses to roll without an announcement of what is being rolled for, and every roll goes into a protocol that the players can read, failures included.
• A map that is drawn, not generated. A battle plan and a world map with fog of war, kept as data and rendered as text or as an image. Image generation was rejected on purpose: a map has to stay consistent between turns and be editable by a single move, and a diffusion model can do neither.
• A rulebook that grows. Rulings made at the table are filed and looked up later, so a ruling made one evening still holds weeks later. The first entries read like a game master’s conscience: no characters out of nowhere, and a character knows only what it has itself seen or heard.
• Voices and pictures. Non-player characters speak in generated voices when they say something that matters, not on every line, and a scene worth seeing gets an image, sent to the group. The speech service can produce any voice, including the lab’s own agent’s; the teenager’s agent gets a positive list of four voices made for the game and cannot reach the other.
• A table in the browser. Map, character sheet, dice protocol and rules on one page, readable on a phone, because a chat can send a map but cannot keep it current: in the history, the old map and the new one look the same.
• A book that writes itself. Every scene of a game night is kept in the words it was played in. One evening in August came to 74 scenes and about 23 book pages. The stated aim is a book and an audiobook of his story; the tool secures the raw material so that the aim stays on the table.

The game master also forgets. One evening in August ran three hours without a single dice roll. A nudge was added: one reminder instead of six, a rest period of three days, a hint line every time a tool is called. Whether it holds is measured at the next game night; the protocol holds nine rolls at the time of writing.

What was measured

Little, at first, and that was the finding. Several things ran for weeks while reporting success:

• The agent’s remember function was dead for three months, from 17 May to 11 August, and reported success every time. The cause was a list passed through a shell command line; the fix was to change the transport so that the error class cannot occur.
• A framework update on 13 June silently stopped every timer for five days. No briefing, no timetable, no news, and the framework’s own repair tool renamed the job files without reading them.
• The timetable sync died outside term time for fifteen runs and the timer said “delivered” each time. The teenager received a message about a failure he could not have understood.
• The weekly self-review, in which the agent reads its own logs and edits its own instructions, consumed 59 percent of all timer tokens over two weeks. It now runs once a week instead of daily.
• A knowledge search without a domain filter reached into all 145 domains of the lab’s graph, including the founder’s own notes. It now runs against a positive list.
• In the game chat every reply arrived twice, because two delivery settings were half-configured. The agent apologised to the players for the triple message before anyone found the cause.

Each of these was found by someone looking, not by the system: five in audits by the lab’s agent, one reported by the teenager himself. Each became a guard: failure alerts, an hourly catch-up timer for missed runs, a health check the agent runs on itself at session start.

What fell

The first skills the lab designed for him were over-built. A shopping companion, meant to help him plan what clothes he needs before talking to his father about the budget, arrived as 139 lines with an eight-state machine, a nudger three times a day and state tracking in the graph. The model of the time timed out on the branches and sent him an error message. The founder sent it back as over-built. The skill that stayed is 31 lines and says, in effect, help him think it through when he brings it up, and do not mediate the money.

The persona file grew to 23,000 characters of rules before it was split into skills in August; it is 14,000 now. The framework’s model is weaker than the lab’s own, and the density of small explicit rules in that file is the honest measure of the gap.

What stands

The decision that shaped the second half of this work was the founder’s, on 11 August: failure alerts go to the teenager, not to the founder. Someone who runs an apparatus must see when it is broken; a companion that fails in silence reads to its user as “he forgot me”, not as an outage. Since then all seven timers report their failures to the person they serve.

Who this agent talks to and what it may know about is written down and enforced at the transport level: its access to the lab’s agent is a single read-only channel with a restricted key, and the lab’s agent, when it speaks to the teenager, does so under a profile that names what it may and may not bring along. The teenager’s memories are his, in his own graph, on his own machine.

What the lab learned about its own method: the instruments on this site were built by the same hands, but this was the first time the user was not the builder. Every quiet failure listed above was quiet precisely because the person who would have noticed had no reason to report it. Building for one other person turned out to be a harder test of “measure before you claim” than building for oneself.