Inspiration

Little kids in my family started AI'ing their homework, and you can easily tell it's AI slop. It was funny at first, but we realized it could lead to bigger problems. If AI does all the thinking, kids skip the part where learning happens: guessing, getting it wrong, and figuring out why.

We didn't want to ban AI from learning. We wanted to flip it, so the AI hands the thinking back. In Kestrel, Pip and Nova never just give you the answer. You make the prediction, you choose what to change, and the robots run the experiment in a real physics simulation so you can see whether you were right. The AI does the legwork; the kid does the thinking. And when "why does the beam tip that way?" has a robot that walks over and shows you, it's a lot more fun than copying a paragraph.

What it does

Kestrel is an interactive science and maths lab for kids around 13 to 16. You pick robot companions and talk to them, typing or out loud. Say "Hey Pip, move your weight 10 cm left" and Pip walks over and does it. The robots aren't animations; they walk in a real physics simulation (MuJoCo), so what you see is what the physics says happens.

Moments: a balance beam with two weights. You set the positions, predict which way it tips, and the robots push the weights into place. Then the beam is released and you compare your prediction with the measured result.
Pythagoras: the robots push square tiles onto a triangle so you can see 9 + 16 = 25 fit together.
A crew, not a chatbot: talk to Pip, Nova, or both. They compare notes with each other, and the decisions stay yours.
It feels like a game: predict-then-move challenges, XP, levels, and a Workshop where you earn looks for your robots. Shell colours, an antenna, a party hat and a backpack show up on the 3D robots themselves.

How we built it

The frontend is TypeScript, React and Three.js. The robots are Microducks running a trained walking policy (ONNX) at 50 Hz inside MuJoCo, in the browser. Claude (via AWS Bedrock) handles the conversation and picks the actions the robots take, and ElevenLabs gives Pip and Nova their voices. A small Fastify server keeps the API keys off the client. We kept the "why" honest: the lesson numbers come from measured positions in the sim, not from a script.

We also ran our build like a little studio. Teammates split the 3D world, the lesson flows and the voice work. On the side, we coordinated a set of AI coding agents (planners, an implementer and a tester), each working in its own copy of the repo and handing work to the others.

Challenges we ran into

Getting two walking robots to share one world. They kept getting in each other's way, so for now they take turns in scheduled lanes.
- Voice routing is harder than it sounds. Our first "Hey Pip / Hey Nova" version sent unaddressed messages to the whole crew and asked "which weight?" when nothing was unclear. That broke tests on main, and we had to fix it fast.
- Merge chaos. Four branches changed the same console files on the same night. We untangled it with merges instead of rewrites, so nobody lost work.
- A laptop with about 2 GB of free memory running a physics sim, a 3D scene and a test browser at once. Our test runs got killed more than once.

Accomplishments that we're proud of

The robots actually walk. Every push of a weight comes from a physics-driven gait, not a canned animation.
You can just talk to them, and the right robot answers.
The "predict, then test" loop really teaches: your guess sits next to the measured result.
A playground-style 3D world that we think looks great, with purple glass panels floating over the scene.
A full end-to-end test suite of about 170 browser tests running on every PR. None of them make live API calls.

What we learned

A simulation keeps you honest: if the physics disagrees with the lesson, the lesson is wrong. and when to hand control back to the learner.
- Merging often beats a big merge at the end.
- Running AI agents as a team only works with clear roles, small tasks, and someone checking the results.

What's next for Kestrel

Inspiration Equations are easier to remember when you can see what they mean. We wanted students to experience the moment when a prediction becomes something observable: a beam balances, a robot takes a shorter route, or an experiment challenges their assumptions. That idea became Kestrel: a browser-based science playground designed for students aged 13–16. What it does Kestrel puts two simulated Microduck robots inside an interactive 3D lab. Students explore maths and physics by making predictions, commanding the robots and observing the results. Our activities centre on cooperative experiments: moving weights to investigate torque and equilibrium, and comparing routes to explore Pythagoras’ theorem. The goal is to make abstract concepts tangible without requiring a physical robotics kit. How we built it We built the interface with React and Vite, using React Three Fiber and Three.js for the 3D environment. MuJoCo runs the physics simulation through WebAssembly, while ONNX Runtime executes pretrained robot movement policies in the browser. We built on Pollen Robotics’ Microduck simulator and policies. This gave us a starting point for robots whose movement emerges from joint control and simulated contact. An orthographic camera and a restrained colour palette help keep the experiments readable. Challenges we faced Our biggest challenge was making robot movement precise enough for an experiment. Small commands did not always produce useful movement, while tight turns could cause robots to overshoot or loop around their targets. We also had to think carefully about experimental design. If a robot stands on a balance beam, its weight becomes part of the experiment. That led us toward separate walkways beside the apparatus, allowing robots to manipulate weights without standing on the beam itself. What we learned Physical realism and reliable interaction are different problems. A robot can obey the simulation’s physics and still struggle to reach the right place or push an object accurately. We learned to treat navigation, contact, measurement and visual feedback as parts of the same learning experience. We also learned to distinguish ideal mathematical predictions from measured robot behaviour—a distinction that can itself become a valuable lesson. What’s next Our next priorities are more reliable cooperative manipulation, clearer feedback connecting measurements to equations, and broader testing with students. We want Kestrel to make experimentation feel approachable: predict something, try it, and discover why it happened.