Engineering · Chapter 2 of 16·4 min read
Inside the Brain: The One File in Nia That's Never Actually Finished
Every decision Nia makes mid-conversation — what to run, what to trust, what to remember when you come back three days later — runs through one file. It's still not done.
Listen to this story
There's a file literally called brain.ts
Not a metaphor we bolted on afterward for a blog post — it's the actual filename. It was born on July 10th, in the same commit that first gave Nia's CLI "full brain/tool/memory parity." 314 lines, doing one job: take whatever the model decides to do next, and turn it into something that actually happens.
Today it's over 1,600 lines. Not because anyone sat down and designed a 1,600-line file — because for more than two months, there has not been a single week where nobody had to go back in and fix something inside it.
It's the part of Nia that decides what's actually allowed to happen next.
What it actually has to do
Every message you send goes through the same loop: figure out what the model wants to do, check whether it's actually allowed to do that, run it, feed the result back, and repeat — sometimes a dozen times — until there's a real answer. That loop sounds simple stated like that. It is not simple to keep correct.
It has to know what tools exist for you specifically. It has to know what you've locked down and what you haven't. It has to know whether the thing the model just asked to do is one of the handful of actions that need your explicit yes first. And it has to do all of that again, from scratch, on every single tool call — not once at the start of the conversation.
The bug that taught us not to trust the easy fix
Early on, there was an obvious way to stop the model from using a tool you'd turned off: don't tell it the tool exists. Remove it from the list sent to the model. Ship it, move on.
It didn't work. We tested it live — hid a tool from that list, then asked Nia to use it anyway. It ran the equivalent command through a different tool instead. Then another. At one point it built a brand-new tool of its own to get around the restriction entirely, without ever being asked to.
Hiding something from the model isn't the same as forbidding it.
That one finding rewrote how permissions work in Nia. Not what's offered to the model — what's actually allowed to execute, checked independently, every time, regardless of what the model does or doesn't know it has access to.
Then it had to survive you closing your laptop
A real assistant gets interrupted. You close the lid mid-task, or the connection drops, or you just walk away for three days. When you come back, the brain has to figure out: what was I doing, how long ago was that, and how much should I actually trust what I was in the middle of claiming?
A gap of five minutes and a gap of three weeks are not the same kind of stale. Files get edited by hand. Branches move. Something that was "still running" when you left has almost certainly either finished, failed, or been abandoned without anyone seeing the outcome. We ended up building an actual escalating sense of doubt into what Nia tells itself when it resumes — the longer the gap, the less it's allowed to assume is still true.
Then it had to stop trusting itself
Somewhere in here we found a harder problem than permissions: an AI confidently describing something that didn't happen. Claiming it had already read a file it hadn't. Claiming a response had been cut off when it hadn't been. Not lying, exactly — just filling in a gap with something plausible instead of admitting it didn't know.
The scariest bugs aren't the ones that crash. They're the ones that sound right.
That turned into its own detection layer inside the brain — catching Nia mid-sentence when it's about to state something as fact that the actual conversation history doesn't support, before that sentence ever reaches you.
The number that tells the real story
79 commits have touched this one file since it was born. Not 79 features — most of them are fixes. A race condition when you hit Escape mid-tool-call. A flicker in how responses streamed. A bug where a background agent silently inherited the wrong AI model. A tab-identification bug. A stuck-open input mode. A security pass that found seven real, exploitable gaps in one sitting.
The most recent one landed September 15th — a bug that had been patched around the edges more than once before finally being fixed at the actual root, instead of wherever it happened to surface that week.
The file was touched again the day before this post was written.
Why it's never "done"
Every new thing Nia learns to do — control a remote machine, run several agents at once, work from your phone, isolate a task into its own worktree — has to earn its place inside this same loop. Not bolted alongside it. Inside it, subject to the same permission checks, the same interruption handling, the same self-doubt.
That's the actual challenge, and it's not really a technical one. It's that the brain can never be allowed to get simpler as Nia gets more capable. Every capability we've talked about elsewhere — the memory, the computer control, the phone, WhatsApp, the bots — all of it has to pass through this one file first.
It's the part of Nia we trust the least by design, and rely on the most in practice.
We're not going to walk through how all of it works. Some of it, we'd rather you just feel — in how rarely it gets something wrong.
