← Blog

Engineering · Chapter 3 of 16·3 min read

The Day Nia Learned to Run More Than One of Itself

Named agents. Then agents working in parallel. Then a live panel to watch them think. Then one single day where a sub-agent learned to pause, resume, and pick up exactly where it left off.

Listen to this story

0:00
Nia

One agent wasn't enough

Once the core loop — the brain — could reliably run tools and hold a conversation, a different problem showed up fast: some tasks aren't one train of thought. Research a topic from three angles at once. Review a change for correctness and security separately. Fan a big job out instead of grinding through it one step at a time.

The first real step toward that landed July 11th: named, reusable agents, each with an enforced set of tools and its own memory across runs. Not a generic "assistant" — an actual identity that could be handed a specific job.

Giving agents a face

A day later, a live panel showed up — "Worker A," "Worker B," "Worker C" — so you could actually watch parallel agents think instead of staring at a spinner. It shipped with bugs baked in: the panel flickered, and worse, it would occasionally leak an agent's raw internal text straight onto your screen.

Watching an agent think is only useful if you can trust what you're seeing.

Both got fixed within two days — the flicker, then the raw-text leak closed for good. Small fixes, but the kind that decide whether a feature feels trustworthy or not.

Teaching the swarm to actually understand a codebase

Running several agents at once is only useful if they're not all starting from zero. The shared memory-clustering core that let one agent recall what another had already learned was pulled out into its own layer on July 16th. Five days later, a proper directory brain arrived — scanning a codebase in parallel, hybrid search across it, and commands to control exactly what gets indexed and what doesn't.

From one job to a swarm

By July 25th, agents could queue up goals and broadcast work across a whole swarm instead of running one at a time. The next day, the general "agent" tool split in two — one for focused execution, one purely for exploring a codebase — and the execution side got real, full tool access instead of a restricted subset.

Then came one very long day

August 9th is the date that actually tells this story. In a single day, sub-agents went from "fire and forget" to something with a real lifecycle: spawn, wait, close, list. Send input to one mid-run. Pause it and resume it later with full context intact, exactly as if it had never stopped. Isolate it in its own git worktree. Interrupt it mid-round, cleanly, without corrupting whatever it was in the middle of doing.

Nine separate pieces of that lifecycle shipped the same day. None of them were the easy part.

That's not a coincidence of scheduling — it's what happens when you finally understand the actual shape of the problem you've been circling for a month, and everything that was blocked on that understanding lands at once.

It still runs through the same one loop

Every one of those sub-agents — however many run at once, however long they pause for — still goes through the same permission checks, the same interruption handling, the same self-doubt we wrote about when we talked about the brain. Running more than one of itself didn't give Nia an exception to any of that. It just meant the brain had to do all of it more than once at a time, correctly, without losing track of which agent was which.