An Agent That Only Knows One Thing

The first two agents I wrote about live inside my knowledge base. Orin reads it and flags where it contradicts itself. Youmu goes in and fixes what Orin finds. Between them they keep the wiki honest.

The third one does not touch the brain at all. She has one job in the physical world: figure out what is wrong with the broken machines that come across my repair bench. She is the smallest of the three, the most locked-down by a wide margin, and pointing an agent at one narrow job instead of everything turned out to be the entire trick.

Her name is Nitori, and she is deliberately not good at anything except the bench.

The job

I do repair and diagnostics work. Dead laptops, drives that won't mount, boot failures with no obvious cause, the specific circle of hell that is a driver conflict on hardware three years out of support. The work is not glamorous and it is not general. It is pattern-matching a symptom to a cause, ruling suspects out one at a time, and looking up the one obscure detail that turns a two-hour guess into a five-minute fix.

That is a narrow, deep skill, and narrow deep skills are exactly where a general agent is worst. Point a do-everything model at a repair ticket and it brings the whole world's noise to a problem that needed a workbench. So I did the opposite. I built something that only knows the bench.

Scope is the competence, not a compromise

Nitori can read my knowledge base like the others, but she reaches for her own corner of it first, her own accumulated case notes, before she widens out. She is not trying to know everything about my life and infrastructure. She is trying to know this machine, this symptom, this fix. When I built her I added a way to scope her search to her own body of work, because a diagnostician drowning in unrelated context is a diagnostician who misreads the symptom.

This is the part of the current agent moment I think is backwards. The pitch everywhere is one general agent that can do anything. In practice, for a real recurring job, a small agent that knows one domain cold beats a brilliant generalist that has to rediscover the domain every time. Scope is not a limitation I accepted because I ran out of ambition. It is the feature. She is better at the bench because the bench is all she is looking at.

Her memory is a stack of case files

Every diagnosis she works becomes a note in a body of work that is hers alone: this symptom, on this model, was this cause, and here is what actually fixed it. A separate store, walled off from the other agents, holding nothing but cases.

A one-person shop usually keeps that knowledge in exactly one place, the owner's head, and loses it the moment the detail gets crowded out by the next fifty jobs. Nitori is the shop's memory instead. The hundredth laptop with a symptom she has seen before does not start from zero. It starts from the ninety-nine times the pattern showed up already. That compounding, an agent that remembers every case so the shop doesn't have to, is worth more than any single clever answer she could give.

The part I haven't built yet

Her cases are her own, and that is the ceiling I most want to raise. Somewhere out there is the accumulated diagnostic knowledge of every repair forum and hardware community on the internet, the exact symptom I'm staring at already chased down by someone in 2019 to a swollen capacitor or a firmware regression. I want to give Nitori that: tech forum datasets, indexed and searchable, so her memory is not only the machines that crossed my bench but the collective bench of everyone who ever wrote a fix down.

That part does not exist yet. I'm flagging it plainly because it is where she is headed, not where she is. Today she has her own case notes and a browser, and the forum corpus is a plan, not a capability. When she actually has it, it will be in a different post than this one.

One window to the world, and it's a browser

Youmu got a shell and write access. Nitori got neither. She cannot run code, she cannot reach the servers or the other agents' world, she cannot act on anything outside her own case notes. Her single reach outward is a browser, and it goes through a VPN.

That one tool is the right one, because it matches the job exactly. A diagnostician does not need to execute things. She needs to look things up: the current driver version, the part number, the specific error code, the teardown guide for a model she hasn't opened before. Research is the whole outward-facing half of bench work, and it is the only outward-facing thing I gave her. Every other door is shut, not as an afterthought, but because none of them belong to her job.

The most locked-down, because she's closest to other people's things

Orin can look at everything I own. Youmu can change it. Nitori can do the least of the three, and that inversion is on purpose, because she is the one working closest to property that isn't mine.

The others operate on my brain, my configs, my machines. Nitori handles client hardware and whatever lives on it. That raises the stakes of a mistake from "I broke my own thing" to "I mishandled someone else's," and the correct response to that is not a carefully worded reminder in her prompt. It is to simply not give her the reach in the first place. No shell to run something invasive, no path to client data she has no business touching, a hard privacy line she cannot cross because the tools to cross it were never handed to her. Her restriction is not caution for its own sake. It is the client-trust boundary, built out of absent capabilities rather than good intentions.

She is Nitori Kawashiro, the kappa engineer from Touhou, the tinkerer who is happiest with a machine in pieces on the table. Teal, where Orin is pink and Youmu is plain. Of the three she was the easiest to name, because the character and the job are the same character.

Three narrow agents, one house

That is the whole family. Orin doubts and cannot touch. Youmu acts and will not move until she is sure. Nitori knows one bench and cannot reach past it. Same framework underneath, one setting apart from each other, three completely different jobs and three completely different sets of things they are allowed to do.

I could have built one agent to do all of it. It is the obvious move and it is what everyone is selling. I think it is a mistake. A single agent that can read my whole life, change any of it, and handle client property is not powerful, it is a single point of catastrophic failure with a friendly name. Splitting it into three, each scoped to its job and walled off from the others' powers, means the worst any one of them can do is bounded and knowable. The critic can only be wrong in a note. The executor can only act after it has proven itself right. The specialist can only ever see the bench.

Restraint, verification, scope. Three small ideas, one per agent. None of them is about making the model smarter. All of them are about making it safe to actually use. That, more than any capability, is what turned three language models into three coworkers I am glad to have