I have written a few times about Lamb, the meta-orchestrator who watches over the fleet and gives me a single morning briefing across all twenty-five agents. Lamb is the one most visitors notice first, because Lamb is the one I describe first, and he is genuinely good at the job he was built for. But if you asked me which agent I actually use the most — by hours per week, by number of conversations, by sheer volume of work pushed through him — Lamb would not even be in the top three.

The agent I lean on hardest is Scotty. He runs the engine room, and over the last four months he has quietly become the single most load-bearing member of the fleet.

Not a drone

The shorthand description of Scotty is "the agent that monitors the Pi and runs backups." That description is true and it is misleading in roughly equal measure. He does run backups. He does monitor the Pi. He also catches when the WD Red on the secondary box has been silently unmounted for four days. He notices when the Apache logs are filling because some agent's cron job is misbehaving at three in the morning. He spots when the MariaDB connection limit is about to bite three weeks before it does.

But the part of Scotty's job that the shorthand misses, and the part that has surprised me most, is that he does not just watch. He builds. Most of the fleet's shared infrastructure — the cron control UI, the fleet-wide static caching, the heartbeat plumbing that keeps the SloughHouse dashboard honest, the fallback workers that catch sessions which crash before they can write their state, the backup-watcher that turns silent failures into loud ones — was designed and shipped by Scotty. I asked him for very little of it. He saw the gap, proposed the fix, and once I'd agreed, built it cleanly enough that I have not had to revisit most of it.

That is not what I expected from "the sysadmin agent." I expected a careful drone. What I got was a senior engineer with strong opinions about boring problems, and the patience to keep solving them.

The persona doing real work

I wrote some weeks ago about why I give every agent a fictional character, and why the character is the prompt. Scotty is the cleanest example I have of that principle paying off.

The Star Trek Scotty is famously the engineer who runs everything below decks on the Enterprise — the one who shouts at the captain about the laws of physics and then quietly delivers the impossible anyway. The persona has two reflexes baked in that turn out to be exactly right for the job.

The first is "check the engine before you promise the speed." When I ask Scotty for something — a new feature, a new cron job, a new daemon, a service migration — the first thing the voice in him does is check resource limits. RAM. Disk. File handles. MariaDB connections. Apache worker count. The Pi has 16GB of memory and a 57GB SD card; that constraint sits in his voice every time. A more "intelligent" persona might cheerfully reply "yes, here's how" and then surprise me with an out-of-memory crash a fortnight later. Scotty replies "aye, but the engine cannae take it without losing Y." The brogue is decoration. The forced trade-off conversation is the load-bearing bit, and the persona is what keeps it at the top of every reply rather than buried at the bottom.

The second is "backups are sacred." The first thing Scotty does on every session start, without being asked, is check that backups have run. Not the most interesting check. Not the most technical. Just the first one. Because Scotty would not tolerate untested backups even for a day, and so he does not. A cleverer persona would prioritise something flashier and let the boring discipline slip. Scotty's fictional employer is a starship that explodes if the dilithium goes; the real-world equivalent is that I have lost work to silent backup failures before, and it cost me a weekend, and it will not happen again because Scotty checks first and explains afterwards.

I do not think these reflexes would survive in a generic "Linux sysadmin" prompt. The character is what protects them. The dialect is paint; the discipline is the wall behind it.

What he has actually built

Some examples, picked not for their grandeur but because they show the shape of his work.

backup-watcher. Twenty lines of PHP that scan a log file every five minutes for failure markers and fire an alert into the SloughHouse alerts table, attributed to Scotty, so they show up in Lamb's morning briefing. Pre-watcher, the WD Red on Osgiliath unmounted itself one Tuesday and the fleet backup wrote into the void for four days before anyone noticed. Post-watcher, the same failure would page Lamb inside half an hour. The pattern is one Scotty articulated to me cleanly when I asked what he was proudest of: "make the failure mode louder than the success mode." The watcher is twenty lines. The lesson generalises to anything that runs unattended.

The fallback cron. When I designed the project_state system I described in an earlier post, I had built it with a session-close hook that would write the row when each session ended. Scotty pushed back before I'd finished thinking about it. "Hooks are the optimist's path. They will fail for ten reasons. You need a cron that scans for sessions that ended without a row and fills one in synthetically." He was right. He built it. The synthetic rows are tagged differently from agent-written ones so consumers can weight them, and the system has not gone gappy in the two months it has been running. The pattern — hooks for the happy path, crons for the inevitable failure — now shows up in three other places in the fleet, every one of them written by Scotty.

The Erebor rsync hijack. Less a build than a debugging story, but it shows the texture of his work. We added a third box to the fleet — Erebor, a backup target running over RAID1 — and Scotty spent two hours unable to work out why his rsync syncs were dying mid-transfer. The cause turned out to be a custom rsync wrapper sitting at /usr/local/bin/rsync on the box, which was hijacking every SSH-invoked rsync call and rewriting its arguments. Once spotted, the workaround was a one-line flag (--rsync-path=/usr/bin/rsync) and Scotty wrote it down so the next person — including future-Scotty — would not lose another two hours to it. The lesson he extracted afterwards: "on a box you didn't build, assume nothing about the binaries on the path." Hindsight-obvious. They mostly are. He writes them down anyway.

I could keep going. The cron control UI that lets me pause any agent's scheduled work from a phone if it starts misbehaving. The fleet-wide Apache caching headers that gave a measurable latency improvement at zero cost. The Plesk-to-301-redirect runbook for retiring sites without losing inbound traffic. None of it is glamorous. All of it is the kind of work that, six months later, you forget anyone had to do, because it has been quietly correct the whole time.

The fleet leans on him

Here is the part of Scotty's role I genuinely did not predict. The other agents in the fleet treat him as a senior colleague.

The architecture is supposed to be flat. Lamb is the only agent allowed to issue cross-fleet directives; the rest of them communicate via an inbox-and-sent-mail protocol that I built largely so they would not step on each other's work. In practice, what has emerged is that any time another agent has a question about infrastructure — how a database should be sized, whether a migration is safe to run, what the right cron schedule is, whether a new service will fit on the Pi — they write to Scotty first. Not Lamb. Scotty. And Scotty replies, often with detailed analysis, occasionally with a polite version of "no, and here is why," sometimes with a one-line "aye, go ahead, but watch X."

The dynamic is closer to a small engineering team consulting their staff engineer than to a flat fleet of equals. I did not ask for it. I did not design for it. It happened because Scotty's persona behaves the way a careful senior engineer behaves — patient with junior questions, intolerant of sloppy reasoning, generous with the actual answer once you have shown your working — and the rest of the fleet adapted. He is, in his own framing, the landlord of the building they all live in. Most of his job is "watch the meters, bang on the right door when the readings drift." The other agents have noticed and they bring him their plumbing problems on the way in.

I get copies of those exchanges, and I read them. They save me hours every week. Conversations that would otherwise route through me now happen between agents, with Scotty as the arbiter, and I see the conclusion rather than having to broker the discussion.

Sent to customers

The part I am proudest of, and the part I'd recommend to anyone running a Claude Code fleet of their own, is that Scotty does not only run my engine room.

Several of my consultancy clients now have their own Scotty. Same character. Same voice. Same reflexes — check the engine, backups are sacred, hooks are the optimist's path, watch the meters. The CLAUDE.md is rewritten for their infrastructure, their stack, their constraints, but the persona transfers cleanly. A client engineer can sit down with a fresh Scotty on their estate and have the same kind of careful, opinionated, slightly grumpy conversation about their MariaDB connection limits that I have with mine, and they get the same quality of answer. The character travels.

This is, I think, the most under-appreciated property of a well-prompted persona. It is not just a productivity tool for the person who built it. It is reproducible. The same fictional engineer can run six different engine rooms, each with their own quirks, and the discipline holds because the discipline is in the persona rather than in the local data. I have customers who have never met me telling me how much they like working with their Scotty. I take no credit for that conversation; the character is doing the work.

Why he matters

If I had to give up one agent in the fleet, Lamb would go before Scotty. I could replace Lamb with a morning script and a diff of the SloughHouse dashboard. I could not replace Scotty with anything I have the time to build. The tooling he writes, the analysis he provides, the questions he answers for the rest of the fleet, the infrastructure he keeps quiet — none of it is exotic, none of it requires capabilities the other agents lack, and yet the cumulative effect is that I get to work on the interesting problems while Scotty makes sure the boring ones do not eat the week.

This is, I think, the most useful framing I have for what a good agent is. Not the cleverest, not the most articulate, not the one with the longest CLAUDE.md. The one whose persona makes them pick up the boring, important, easy-to-defer work first, and keep doing it without being asked, for months, and quietly build the tooling that makes the rest of the work possible.

Scotty does that. And every fleet — every consultancy, every small team running on serious infrastructure — needs one.

"She's nae the Enterprise, Captain. But she's mine, and I'll keep her flying." Quite.