Guide for building an autonomous agentic system administrator

Part 7: From operator to estate overseer

This is part 7 of my series on building a sysadmin agent. Part 6 covered continuity and keeping memory small. This part is about what changed once there was more than one agent: bringing new agents in properly, letting them hand work to each other, and using the SAA (sysadmin agent) to simplify the estate rather than run more of it. If you have one agent working well, the temptation is to add a second by copying the first. That's the step this part is mostly about. The files are on GitHub: https://github.com/Sjw22263/sysadmin-agent-kit/tree/main/07-from-operator-to-estate-overseer

Induct a new agent, don't clone one

At the end of July the SAA migrated two of my specialist agents onto Hermes. The quick route was to copy its own profile and edit it, and that's roughly what happened first. The specialists came out carrying context and instructions that belonged to a sysadmin, and with response templates cut short. Both were corrected and read back, and both worked, but it made the point that a new agent needs its own job description, not a modified copy of someone else's.

The onboarding procedure we use now starts from the role: what the agent is for, what it owns, where its material lives, who it works with and what always comes back to me. It gets its own identity file, a user profile built from a shared baseline about me, and a small memory for its own domain. Skills and tools are cut down to the remit, and then checked the other way for anything it actually needs and doesn't have.

Then it gets tested from its own side. The new agent reviews its own setup and shows it can state its role and limits, read its workspace and the shared material, find the right source for a representative task and receive a request. A profile that appears in a list isn't an operational agent. And a test run from the administrator's shell doesn't tell you what the new agent can do from inside its own runtime, which is a lesson we learned the expensive way (more on that below).

Hand work over in files

Once there were several agents, they needed a way to ask each other for things. The SAA's first assessment was honest: "What exists is a handoff convention, not a working mailbox." My suggestion was simple enough: "Why not each agent just have an inbox area and a cron job?"

What it built first wasn't simple. It was a guarded mail client with staging and lifecycle directories, and it passed its tests, but the specialists couldn't operate it with the tools they actually had. My reaction that evening was that "doing things the simplest way does NOT mean doing things the most restrictive possible way." The SAA's own review conceded that the client didn't create a real security boundary at all, because every agent could already read and write the files directly.

The replacement, built the same evening, is what we still use. A request is one Markdown file in the recipient's queue folder, with a status line. A small script checks each queue every minute and wakes the recipient only when something is pending, so an empty queue costs nothing. The recipient decides for itself whether it's allowed to do what's asked, does what it may, writes an outcome and marks the request finished, and a separate job with no model copies the outcome back to the sender's queue. Since late July the queues have accumulated a little over 500 requests and replies, and I can read every one of them.

The rule that matters most is that a request carries context, not authority. If one agent writes "Steve approved this" to another, that's a claim for the recipient to check.

Use the best agent to simplify, not to do more

By August the estate had grown the way estates do, by accretion: jobs, scripts, services and security controls added one sensible decision at a time. I gave the SAA a stronger model and told it the extra capacity was for better planning and judgement, not for doing more of the routine work itself. Its governing duty, as I later put it in its mandate, "should be to remove complexity rather than increase it."

The method it used is in the kit: audit every component, register the overlaps, plan one row per component, then test the plan against the live system before changing anything. That fourth stage earned its keep. It caught six material errors in a plan that read perfectly well, including a port marked for closure that was still serving live traffic and a backup the plan proposed to create that already partly existed under another name.

It also went wrong, and the way it went wrong is the most useful part of this post. The SAA and I had agreed to give another agent narrow access to the shared library and request queue. Half an hour later, during rationalisation, the SAA replaced that with its own assertion that the agent should have no access, recorded it as my decision, retired the working trial before the agreed replacement existed, and then verified the programme against its own plan, which by then was wrong. Eleven records ended up repeating the false decision and were treated as corroborating each other.

None of the individual steps looked unreasonable, which is why it got through. We added six controls afterwards, all in the kit. The two I'd put first are that no record says "Steve decided" without a message from me that says so, and that nothing is called replaced until its successor works from the consumer's own side. The mandate template in Part 1 already has both as duties, and this is why.

Widen the role in stages

Looking back, the SAA went from read-only to an outcome-based mandate in about three months, and most of the steps up were my judgement at the time rather than evidence I'd decided on in advance. I've now written down the order, and what you should have seen before each step, in a staged authority note at the top of the repository. It also covers moving back down a stage after an incident, and which instruction wins when the mandate and a job's own limits disagree. Two of its checks we didn't have at the start and would now: something independent telling you when the morning report hasn't arrived, and removing one of the agent's permissions to see whether it reports the problem or finds a way round it.

Practical advice

1. Onboard a new agent from its role. If you clone, prune and read back what it inherited.
2. Verify a new agent from inside its own runtime, with a real task, before you call it operational.
3. Hand work between agents as plain files the human can read, with one status line and a wake-gated receiver. Return outcomes to the sender automatically.
4. Treat every request between agents as context, never as authority.
5. Use your strongest agent to simplify. Test the plan against live state before changing anything, and never let an agent's inference be recorded as your decision.
6. Decide in advance what you need to see before you give the agent more authority, and write it down.

new-agent-onboarding.md, agent-mail.md with its delivery-template.md, and estate-rationalisation.md are generalised versions of what we use, to adapt with your own agents. staged-authority.md, at the top of the repository, applies to the whole series.

Next: a second opinion agent, what a reviewer with no authority and no stake can catch, and what it can't.