Helpers and agents: the things that run on their own
● Current as at 3 September 2026, AEST
Most of Station sits there until I ask it something. Some of it doesn’t wait to be asked, and some of it will take an instruction and go away and do the work.
I call both sorts helpers. A helper is a small piece of Station with a written remit: a job it is meant to do, a time it does it, a list of things it is allowed to touch, and a place it has to report back to. The remit is written down before the helper exists, and it’s the remit — not the helper’s own judgement — that decides what it may do.
There are 24 of them as at 3 September 2026: twenty that run on a clock without being asked, and four you talk to. This page is about eight I’d actually miss, and it asks each of them the same four questions.
The four questions
Every helper below answers the same four, in the same order. I’d rather one were boring and answerable than clever and vague.
- What does it watch, or do?
- When does it run?
- What is it allowed to touch — and what is it not?
- How does it report back?
The last one is the one people skip, and it’s the one that matters: a helper doing its job perfectly and telling nobody is indistinguishable from one that died six weeks ago.
They all live on one screen, each with its schedule, what it leans on, which brain does its thinking — or ○ No AI, which several of them proudly are — and when it last ran.
Sentinel — the one that never blinks
Watches the machines and everything on them: disk, memory and processor load; containers that restart in circles or get killed for eating too much memory; website monitors and expiring certificates; the network gear; the tool servers Station talks to; Home Assistant automations that fail; and Station’s own jobs.
Runs every 15 minutes, all day, forever.
May touch — almost nothing. All of the above is read. Since 21 August 2026 it can also run exactly two repairs: reload one Home Assistant integration, or re-run one failed Station job. That’s the whole list, it’s written in code rather than chosen by a model, and nothing outside it can run. Even those two ship switched off — and off isn’t idle: Sentinel still works out what it would have done and offers it as a button, which is the state the screenshot below was taken in.
Reports to one screen, quietly. My phone only buzzes when something newly becomes serious — at most three per sweep, six per day, never twice in a day for the same problem. Ninety-six sweeps a day where nothing is wrong produce nothing at all.
Since it started on 29 July 2026 it has swept 853 times and opened 78 conditions, of which 65 are resolved. 13 were still open on the evening of 3 September 2026 — the eleven the screen above counts, plus two I had told it to ignore. 75 of the 78 got an automatic investigation: one round, read-only, root cause plus ranked suggestions.
The rule I’m proudest of is the one about silence
A missing answer is never a healthy one. If a source of information goes quiet, Sentinel doesn’t clear the problem — it raises the silence itself as the problem. Three sweeps with no data and the source becomes its own warning. A tool server that stops answering stays in the catalogue marked down, with its last known state, rather than vanishing as if it had never been installed.
That rule has a date attached. On 19, 20 and 21 August 2026 the 6:30am wake-up radio didn’t play, three mornings running. The music system’s link to Home Assistant had died on the 18th, and every health indicator stayed green throughout. The only trace anywhere was one line a day in a log nobody reads — four error lines in three days, far too few to trip anything watching for a flood of errors. A human noticed. On the third day. By not playing.
So there’s now a rule watching individual automations for failed runs, and it will not accept the error going away as evidence that anything was fixed — because that log is wiped every time the system restarts, so "the error stopped" usually means "something rebooted". It only closes when a later run of that same automation actually succeeds.
Three ways of going quiet, all found in the last fortnight
- A tool server that disappears. Station used to reach several of its tool servers through a shared middleman, and when one vanished from the middleman’s list there was no way to tell "it’s broken" from "it was deliberately removed". Station now connects to each one directly from a shared list, and a failed check is kept and marked down rather than dropped. Two failed checks in a row and it’s a problem. Of the 78 conditions Sentinel has ever opened, 31 were a tool server going missing — by a distance the most common thing that goes wrong here.
- A configuration that stops being read. Station reads each service’s live settings and stores a copy. On the morning of 3 September 2026 an audit found only ten services producing those copies at all, and two of the ten had silently stopped — one hadn’t managed it since 5 July 2026, the other since 28 August. Nothing anywhere said so. There’s now a rule that complains when a service that used to hand over its settings hasn’t done it for three days. Note what it measures: age since the last success, not a count of failures — because a source nobody is asking any more never produces a failure to count, and a failure counter would have sat at zero for both of the dead ones forever.
- A weekly job that fails. A job that runs daily or more often has to fail three times before it’s raised. A job that runs weekly or less is raised on its first failure, because three weekly failures is 21 days of nothing.
The Groundskeeper — the daily walk
Does the rounds. Once a day it logs into every machine it has a key for — including the ones running no containers at all, which is exactly where things rot unnoticed — and checks disk pressure, failed services, log noise, unhealthy containers, load, memory and whether anything is waiting on a restart. It picks up Home Assistant’s own errors on the way past, and works out each machine’s hardware for itself while it’s there.
Runs daily at 7:30am — on my clock, not the house’s, so it still lands at breakfast when I’m travelling.
May touch nothing. Every check is read-only. A serious new finding gets one round of automatic investigation, and that investigation is read-only too: if it proposes a fix, the fix is parked, not run. At most three start per round, so a bad morning doesn’t turn into a bill.
Reports to the same health screen Sentinel writes to, a daily email, and — for anything serious — a real task with an owner that I can hand to a coding session.
As at 3 September 2026: 90 runs since 7 June 2026.
Backup Guardian — “are my backups okay?”
That’s the actual heading on the screen, because it’s the actual question.
Watches every backup job in the house, keeping its own permanent history rather than trusting whatever the last email said, and checking the evidence around the backups too — encryption, retention, and whether a restore has ever been proven.
Runs every 30 minutes, with one daily summary in place of the pile of separate emails it replaced.
May touch nothing. It reads, records and reports; no backup is ever changed, started or deleted by it.
Reports on its own page, and hands anything failed or overdue to Sentinel, which owns the decision about whether that’s worth waking me for. Two watchers, one notification path.
The tile I care about reads 0 not checked. "Not checked" is a first-class answer here, beside healthy and failed, and it is never rounded down to fine — a monitor that can’t reach something and says "all good" is worse than no monitor, because now you’ve stopped looking. When the new digest went live in late August 2026 the old emails were deliberately left running beside it for a 14-day proving period: it had to be shown to have missed nothing before anything was switched off.
As at 3 September 2026 it watches 8 jobs across 6 sources, and has recorded 27 runs since 24 August.
The Diagnostician and the Remediator
These two are a pair, and they’re the ones you talk to rather than schedule.
Do: start from a problem on the health screen. The Diagnostician goes and looks — service status, logs, journals on the machine that owns the thing — and comes back with what’s wrong and what it recommends, in sentences. The Remediator picks it up and proposes the exact command it wants to run, with what that will affect and what it risks.
Run on demand. No schedule; they exist because I clicked something.
May touch: the Diagnostician, nothing — every check is read-only. The Remediator, nothing until I approve that specific action. Not the conversation, not the plan: each action, one at a time, with its impact beside the button.
Report into a conversation that’s kept, so six weeks later I can read what was actually wrong instead of reconstructing it.
The Homelab Helper — the one I hand a job to
The Diagnostician waits for something to break. The Helper doesn’t need anything to be wrong — it takes a job.
Does whatever I describe, across the machines, the network between them and the containers running on them. It knows a container can be broken on a perfectly healthy machine, so it checks the workload before blaming the box.
Runs on demand, and can span several machines in one go.
May touch — and this is the whole design — only the machines I ticked. That’s the first thing on the screen, above the box where I type the task. Reading is free and happens without asking; anything that changes a machine, a container or the network is proposed as a single command with its impact and its risk, and runs only after I approve it. It sees the network from the machines I picked, so it has no view of the switch or the router unless one of them was on the list.
Reports into a kept conversation, grouped by which machines it touched.
Hermes — the one that thinks overnight
The strangest one, and the only one still on trial.
Does pick up two or three threads I’ve parked — an idea I never triaged, a conversation I drifted away from, a service whose settings look odd — and think one step further while I’m asleep.
Runs at 2:15am to think and 8:15am to tell me. At most three things, ever: that cap is fixed in code and the setting can only lower it. A night with nothing worth saying sends no email at all — not a "nothing to report" one, which would only train me to ignore the mornings that matter.
May touch nothing, and not as a matter of policy. It runs in its own locked-down container on a different machine, with no terminal, no browser and no way to run code — and, the part that actually makes it safe, it was never given a credential that could write to Station. It reads through a read-only door. Fully hijacked by something it read, the worst it could do is waste electricity.
Reports onto one shelf with three buttons — Keep, Promote, Drop. Anything I ignore retires itself after seven days and is never raised again. Nothing chases me, and there is no unread badge anywhere, on purpose.
Two things on that screen are why I’ll keep it. Cited lists the real Station records the thought is built on — and if not one of them checks out against the actual database, the thought is thrown away rather than shown to me. An answer that can’t point at anything is ungrounded however well it reads. Underneath, Why Hermes suggested this opens the frozen evidence: which service, which machine, which model, what it looked at, and — importantly — what it couldn’t reach, marked unavailable rather than quietly left out.
Keep is the newest button, from 28 August 2026. Before it, a thought that was interesting but not urgent met the same end as one that was useless. Keeping exempts it, files it, makes it findable in search — and works on thoughts that already retired, so missing the window isn’t permanent.
As at 3 September 2026 Hermes has thought on 35 nights since 1 August and produced 23 suggestions: 15 on the shelf, 3 retired unread, 3 dropped, and 2 promoted into real ideas.
It was silent for ten nights and looked thoughtful
From 17 to 26 August 2026 Hermes read nothing at all. A placeholder in its configuration had been shipped where its access token should be, so it couldn’t reach a single record — and because it couldn’t cite anything, every thought it had was correctly thrown away, so the morning email correctly sent nothing.
Which looks exactly like a thoughtful quiet night. Its health check stayed green throughout, because the service was running perfectly; it just couldn’t read.
The fix isn’t clever: a night where every single thread fails is now recorded as an error, not as a partial success. This is the same shape as the wake-up radio, the tool server that vanished and the configuration that stopped refreshing, and it is the lesson this entire page keeps circling. Working silently and failing silently look identical from outside. Almost everything on this page exists to tell those two apart.
The Idea Gardener — the one that remembers I forget
A second brain has a specific failure mode: you capture everything and act on none of it. The captured thing feels dealt with. It isn’t.
Does pick a small handful of ideas that have gone quiet — captured, never triaged, untouched a while — find what has arrived in Station since that might now connect to them, and put them back in front of me with the question I was dodging: promote, park again, or drop.
Runs daily at 8:30am, a gentle handful, with a cooling-off period so it can’t raise the same idea twice in a row and nag.
May touch one thing and one thing only: it notes that it resurfaced an idea, so it doesn’t pick the same one tomorrow. It never changes an idea, re-files one or deletes one.
Reports by email, and into the run log below — as at 3 September 2026, 19 runs since 7 June 2026.
That log is the one every helper writes to: every run any of them has ever done, what it found, and whether a finding ● opened, ⚠ worsened, ◐ was re-diagnosed or ✓ resolved. It is deliberately separate from the list of whether a job ran at all. Different questions — and I’ve been bitten by confusing them.
One I retired
There used to be a ninth. It watched the Home Assistant developers’ blog, worked out which of my projects a given post might break, and emailed me on Mondays. It ran 9 times, it worked, and on 20 August 2026 I switched it off — because a newer helper was already doing the same job for every project my code leans on, and two helpers finding the same thing means two places to dismiss it from until you trust neither.
What was carried across, and the one thing that wasn’t
Retiring a helper is not the same as deleting it. Two things were moved over first: its memory of how far down the blog it had already read, so the new one didn’t start again from the back catalogue, and its hard-won rules for spotting a genuinely breaking change in that blog’s particular phrasing, which had been tuned over months against that one source.
One thing was deliberately not carried across. The old one could draft the code change itself and open it for review, unattended. The replacement can’t, and won’t. That’s a reduction in autonomy I chose, and writing it down as a choice is the point — otherwise in six months it reads like something lost in a refactor.
Why I trust them
Four rules, and together they’re my answer to "aren’t you nervous?"
Everything ships switched off, or read-only first. Sentinel’s two repairs are off by default, and off isn’t idle — it still works out what it would have done and shows me the button, so the whole path gets exercised and watched before it is ever armed. Hermes is opt-in and still labelled a trial on its own page. Station starting coding work while I sleep was built and then shipped deliberately disabled, because overturning "a human is always present" is a decision for a person, not a setting.
What a helper may do by itself is a short written list, not the model’s judgement. Two repairs. Not "low-risk actions" — those two. And what’s protected is decided by what an action does rather than what it’s aimed at: gentle and reversible is always allowed; restarting or stopping anything on my protected list never is, whoever asks. Every attempt is logged, refusals included.
I press the button. Every change the Remediator or the Helper wants is one command with its impact written beside it, and it waits. Approving a plan is not approving its actions, and nothing here has ever been given permission in advance.
The practice copy cannot reach the real house. Station has a development copy refreshed nightly from a genuine backup — which is exactly what makes it dangerous, because it holds real, working credentials. Left alone, one click in the wrong window could have sent a real message, changed something in my actual home, or run a command on a real machine. Since 3 September 2026 every one of those paths checks, at the last moment before it would reach the outside world, whether it’s allowed to — and if it isn’t, says "suppressed on this instance" in the same shape the screen already knew how to draw, rather than failing in a way you’d learn to click past. Reading and looking still work everywhere. It just cannot touch the house.
What this isn’t
It isn’t autonomous, and I keep saying so because the word does a lot of unearned work. Twenty of these run on a clock, and exactly one of the twenty — Sentinel — can change anything outside Station at all, from a written list of two actions that are both reversible in a second and both currently switched off. Every other one of them reads, files and emails. The one that watches my code repositories for anything gone public flags it and refuses to fix it, because which of my repositories is public is not a machine’s call.
It isn’t a product. It runs on hardware in my house, for one person, and a fair amount of this page is a description of things quietly not working for days at a time while every light stayed green.
And it isn’t finished. The one I’d bet on being rewritten first is Hermes, which is still on trial, still opt-in, and still has to prove that three thoughts a morning are worth the electricity.
The machines all this runs on: The homelab →. The other half of the loop, where Station runs its own development: Station builds itself →.