I asked my assistant to create a Meetup account for itself. On paper that is a five-minute job. It took twenty minutes and one interruption, and the interruption is the whole story.

It filled the form without complaint: name, my spare mailbox, Hamilton, the 18-and-over tick. Then it stopped. Meetup puts a human check in front of the Sign up button, and while that check was unticked the button stayed grey and unclickable. I watched it sit there, reading the page, checking the field, checking again. It would not fake being a person. So I clicked the box myself, and the account existed.

That is the only part of the afternoon a machine could not do.

The rest it did alone. It found the verification email in its own mailbox, followed the link, logged in, and joined the club: member 1,345 of Hamilton newbies, up from 1,344. Then I asked it to be less obviously an AI, which is a strange sentence to type. It renamed itself Meetup Assistant and rewrote its bio, because the field stops at 250 characters and its first draft got cut off mid-sentence. Then it answered a message I sent it inside Meetup, in the Meetup thread, four minutes after I sent it. Not in a chat box on my screen. On the platform.

Then came the real work, which turned out to be about attendance rather than copy. A local venue had offered to host us — Escapist, the escape-room and board-game cafe on Bryce Street, with four hundred-odd games on the shelf — and the thing worth drafting first was the event that repeats. Not a one-off night with a date and a poster. Their Board Game Club runs every Friday, six till close, ten dollars, popcorn included, and a standing invitation in front of our members is worth more than any single evening.

The agent read the group, read the venue’s own event page for the parts worth reusing, and drafted it: Friday the sixth of November, six till nine, four topics, the venue’s banner art rather than a stock photo. It saved it as a draft and left it unpublished, because it goes to 1,346 people and publishing is my call, not its.

That is the pattern from here, and it is the part I care about. One recurring Friday is the start, not the plan. Other Hamilton events will be added as they come up — a room, a night, a reason to leave the house — and none of them need building from scratch, because what has been built is the mechanism rather than this particular Friday.

I changed the framing once before we got that far. The copy had read like a group event that happened to have a venue, and I wanted the opposite: Escapist is running this, we are turning up. So the draft grew an opening section titled, in the plainest possible terms, a note on who runs this, and the welcome message and how-to-find-us stopped pointing at us and started pointing at the venue’s staff. An agent that will happily write three hundred words of event copy will also, if you let it, quietly claim credit for the whole thing.

Then the host line, which is where the platform pushed back. I asked it to put my name down as host and take its own name off. Meetup would not have it: an event must always have a host, and while the agent was the only one, its name had no remove button at all. No error, no explanation — the control simply was not there. To stop hosting, it first had to make me the host, and only then did the little cross appear next to its own name. It added me, stepped down, and checked the saved record afterwards rather than trusting the screen: host is my member ID, attendance empty.

Two rules did the work, and neither had anything to do with intelligence. Prove you are a person. Somebody human must be responsible. The agent can write the event, describe the games, answer members and hand the keys over cleanly. It cannot tick a checkbox, and it cannot resign as host until a person exists to take the job. Both times it handed the decision back to me, which is the arrangement I would want anyway.

The event is real, the venue is real, and it is still a draft. The only thing standing between it and 1,346 inboxes is that I have not said go — and the next one after that will take about a tenth of the time.

One morning the PC was sitting in BIOS. Not booting, not failing to boot — parked in the firmware screen with a USB stick plugged in and the hard drive first in the boot order, waiting for somebody to notice.

The lazy explanation is “it rebooted and picked the wrong device”. That explanation is wrong often enough that I asked for the actual trail instead of the plausible one.

Windows keeps a record of unexpected shutdowns, and this one had an Event 41 bugcheck code of 340 — storage class, the family of codes that means the machine went down in a way the storage stack was involved in. That is a direction, not an answer. The answer was in the firmware history.

The SSD was a Samsung 990 PRO, and that model has a firmware lineage with a documented history of exactly this: drives that drop out under load, BSODs that get blamed on everything except the drive, and firmware updates that quietly fix them. A machine that reboots into firmware with a storage-class bugcheck and a 990 PRO inside it is not a mystery, it is a known shape. But you only see the shape if you look up the model instead of the symptom.

Behind that was the trigger. A Windows Update restart had started the sequence — the update was the thing that asked the machine to reboot, and the reboot is where the drive misbehaved. Which means the update was innocent and also the reason we found out: it forced an event that the machine had been failing intermittently at for a while without anyone noticing, because a reboot that happens when you are not looking looks exactly like a reboot.

Two other things were in the wreckage and both mattered. An old NSSM service, left behind by something I had stopped using, spamming errors on every start — not the cause, but noise that makes a log harder to read at the exact moment you need to read it. And a Macrium differential backup caught mid-run by the crash, rescued before it could leave a partially-written image that would have failed silently later, at the worst possible time.

The whole thing went into a playbook: check the bugcheck code and classify it, look up the specific hardware against known firmware issues before believing any other theory, check what Windows Update was doing at the time, audit the services that start with the machine, and then verify the backups that were running when it died.

The drive got its firmware update, the stale service went, and the interrupted backup was verified rather than assumed.

What I like about this one is that nothing in it is clever. Every step is something a careful person would do with the same information. The difference is that the machine did them in order, at 6am, without a theory it was emotionally attached to — and the first theory anyone reaches for, “it booted off the USB stick”, would have left a failing drive in place and a playbook unwritten.

After the NAS lost a volume, I asked the assistant to put my playlists back. It came back a while later with news I did not expect: the playlists were not the NAS’s fault, they were mine. Well — ours. The cron job’s.

Two of the three playlists were fine. The third was 316 bytes of track stubs with no file paths in them. Names, positions, no files. The kind of file that opens without error, lists its tracks, and plays nothing.

The obvious suspect was the storage failure everything else had come from. It was not. A nightly “Movie Themes” job had been rebuilding that playlist from a manifest on the NAS, and when the NAS became unreachable the job kept running. Night after night. Each run read nothing, wrote a fresh file from nothing, and reported success, because from its point of view it had done exactly what it was asked: produce the playlist file. It never asked whether the input existed, and it never compared what it wrote against what had been there.

That is the failure mode worth the whole post: an automation whose input disappeared and which kept writing anyway. It did not crash. It did not error. It did not alert. It quietly replaced a real thing with the shape of a real thing, and it would have kept doing it for as long as the schedule held.

The forensics came before the rebuild, which is the only reason the story has an ending rather than a repeat. Where did the tracks come from originally, which ones were still reachable, what did the file look like the last time it was correct. Once that was on the table the rebuild was mechanical: eight Sonos-native playlists, 386 tracks, pulled back from YouTube Music with yt-dlp.

One track was genuinely gone — the video deleted, unavailable, the original upload pulled. Substituted with the same recording from the artist’s official channel, which is the honest version: same audio, different host, and I would rather have the song than a gap and a note explaining the gap.

Then every playlist was verified by playing it. At volume zero, one track at a time, checking that something reported PLAYING rather than skipping or erroring. Verification at volume zero is a strange thing to do at the end of a rebuild and it is the only check that tells you the file is real instead of merely well-formed. 386 tracks that exist on disk and are not referenced by anything look identical to 386 tracks that work, right up until you press play.

The job is deleted. That was the actual fix. Everything else was repair.

What I keep thinking about is how reasonable it looked. A schedule, a source, a target, a nightly rebuild — the design is unremarkable and it is the design most of us would write. The missing piece was one line of judgement: if the source cannot be read, do not write the target. If the new file is a fraction of the size of the old one, do not replace the old one. Cheap checks, and the difference between an automation that maintains something and an automation that slowly eats it.

Five systems failed in one week, and every one of them reported healthy while it was broken. Not “reported healthy with a warning I ignored”. Reported healthy, full stop, with a green light and a 200 and nothing in the log.

This is the week I stopped trusting a monitor that only speaks when it has good news.

The first one was mine. The Honcho deriver — the process that turns conversations into memory — was draining its queue and marking every work unit processed=true while extracting nothing at all. Queue empty, work done, nothing extracted. Its /health endpoint returned 200 the entire time, because the health endpoint was answering a narrower question than the one I thought I was asking: is the process up? Yes. Is it doing its job? Nobody had written that check.

The second one followed from fixing the first. Rotating an API key opened a window of about four hours where memory extraction was completely dark, and every health check stayed green the whole way through. The deriver was up. The queue was moving. The key was wrong, and the only thing that would have caught it was a check that tried to use the key rather than checking that it existed.

The third is the one I am least comfortable about. The Photon inbound watchdog — the thing whose entire purpose was to notice if inbound messages stopped arriving — was structurally incapable of ever firing. It sent probe IDs in the form hermes-liveness-probe-<timestamp>. The service requires spc-msg-<uuid>. Every probe was rejected, and an inconclusive probe never degrades the stream, so inbound died quietly and stayed dead until a full restart. A watchdog that cannot fire is worse than no watchdog, because it occupies the slot where a working one would have gone.

The fourth was disarmed for two and a half hours because an arming flag vanished after a restart. Here is the detail worth stealing: in that system, “disarmed” and “healthy” both print nothing. Identical output, opposite meanings. The most dangerous state in the whole system was indistinguishable from the best one.

The fifth was the memory API, wedged for 1.7 days with 22 Docker clients queued behind it. Nothing alerted, because nothing was watching a queue depth — only whether the port answered.

And underneath all five, my update checker had been reporting fabricated numbers since September: 497 commits behind, then 50, then 38, then 24,477, for a gap that only ever grew. Every number was plausible. None of them were true. That one stings because I quote it in briefings.

The fixes were less interesting than the diagnosis, which is usually the sign you found the real problem. The pattern across all five is the same: each monitor was written to detect a specific failure, and each one silently degraded into reporting the absence of that specific failure as health.

So the rule that came out of that week is short. Arm by default, and make standing down the explicit act. A component that has to be switched on to be watched will eventually be watched by nobody and reported as fine. A component that watches unless you tell it to stop can only be off if somebody said so, and saying so is a thing that leaves a mark.

The second rule is that every green light should be able to say what it checked. “Process up” is a check. “Job completed and produced output” is a check. “The key exists” is not the same as “the key works”, and a probe that never leaves the building has not tested anything at all.

My assistant can delete things. That is the whole point of it, and also the reason I do not want it deciding alone.

So it asks. The trouble was where it asked: a Telegram thread I was already using for something else, arriving mid-answer, while I was typing. I would see it, mean to answer it, and scroll past. Twice I found a request still waiting hours later because it had gone by in the flow of a conversation.

An approval prompt that gets scrolled past is not a safety feature. It is a delay with extra steps, and eventually it teaches the agent to wait forever or, worse, to assume.

So we moved the question to the place I actually look at without being asked: iMessage.

The shape of it is simple and that is deliberate. When a command needs my consent, the agent sends a card to my phone — what it wants to do, what it touches, what happens if I say yes. To approve, I reply with a short code plus a digit. Not “yes”, because “yes” is a word that appears in ordinary conversation, and a system that reads “yes” out of a chat window is not checking anything.

The reply is matched back to the exact request by digest. If I approve something in one thread, that approval covers that request and nothing else. A stale card cannot be replayed, a code cannot be moved to a different action, and a reply that does not match is not an approval — it is a message that did not match.

The plumbing is where the afternoon went. The Mac mini sends through Messages.app via AppleScript, which is fine and boring. Reading the replies is not. In chat.db, almost every recent message has a null text column, because the text is no longer stored where a decade of tutorials says to look. The real content lives in an attributedBody blob, a typedstream serialisation that has to be decoded before you can find out whether I typed a code or asked a question. Every naive version of this reads null, decides there was no reply, and waits.

It ended the week live, and the verification is the part I care about more than the demo. Card sent at 12:08:54. Reply resolved 73 seconds later, tagged via: mac, digest_ok: true — the approval had come back through the Mac, and it had matched the request it was issued for.

The rule underneath all of it is that the thing fails closed. If the card cannot be sent, nothing runs. If the reply cannot be parsed, nothing runs. If the digest does not match, nothing runs. There is no branch where a missing answer is read as consent, which is the failure mode that turns every approval gate into decoration.

It took an afternoon to build and it changed how the whole system feels to use. The agent stops being a thing that acts and tells you afterwards. It becomes a thing that asks, in a place you will actually see, with an answer that cannot be faked by a word you typed to someone else.

A 2TB data drive in my Proxmox host died at 9:47 on a Thursday morning. Five containers froze mid-flight, Home Assistant among them, and the house stopped responding to anything.

By the time I went to bed the box was still up, still wrong, and I did the lazy thing: told the assistant to reboot it. Off and on. The answer to most things.

It refused, and then explained why in a way that made me glad it had.

A clean reboot is not a switch. It asks the system to shut down tidily, and a tidy shutdown calls sync() first — flush everything still in memory to disk, then stop. That is the whole point of it. But the drive that had died was part of a ZFS pool that was now suspended, and roughly 4,000 processes were stuck waiting on it in uninterruptible sleep. They were never going to finish. sync() was never going to return. A normal reboot would have sat there until someone walked over and held the power button, and with the pool suspended there was a real chance of making the on-disk state worse on the way down.

So it used the kernel’s emergency reset instead. sysrq-trigger: drop straight through the shutdown path, no sync, no waiting for anything that cannot finish. The correct escalation when the polite path is structurally blocked, and a genuinely dangerous one to reach for when it is not.

The first attempt did nothing at all. Not a failure you see — a failure you infer, because the process had been backgrounded, the SSH session closed, and the kernel killed the child with the session’s cgroup before it could fire. Silent, and the box looked exactly as it had before. Second attempt, run detached from the session that started it, worked.

I found out in the morning, which is the part I keep coming back to. The decision had been made at midnight with nobody awake to approve it, on the one action that could have bricked the machine, and it was the right decision for a reason I would not have thought of at that hour: the obvious command was not slow, it was impossible.

What I got to read over coffee was better than a status message. A verdict file saying what had died and why the reboot had to be done that way. A watchdog set to check every 20 minutes that the host was actually coming back rather than assuming. And one line in the morning briefing naming the exact drive to replace, with the model number in it, so the next step was a purchase and not an investigation.

The host came back up. Home Assistant came back with it. The dead drive is now a line with a model number on it rather than a mystery, which is the most useful thing an incident can produce at 3am.

What I took from it is not that the agent is clever at 3am. It is that “reboot it” is a request with a hidden precondition — that the system can still shut down — and nobody writes that precondition down because it is almost always true. The night it stopped being true, the difference between the obvious action and the correct one was about four thousand stuck processes and one blocked system call.

The NAS was full and stuck read-only, and I knew exactly what to delete. A 2.6 GB folder of JDownloader leftovers. Obvious candidate, obvious win, get the volume back.

The assistant did not delete it. It went and looked first, which is annoying when you have already decided, and correct almost every time you have already decided.

What it found was three Macrium Reflect full images. Together they took about 4.75 TiB of a 7.27 TiB volume. Not 4.75 GB. Terabytes, sitting on the same disks they were protecting, because that is where the backup share pointed and nobody ever asked how much room the history was allowed to take.

Two things followed from that, and only one of them was about space.

The first is arithmetic. A volume at 100% is not a volume with no room left, it is a volume that cannot do its own bookkeeping. btrfs needs working space to write metadata about the metadata, and when there is none it does not politely return an error. It corrupts. The check came back with bad key order and cannot fix corrupt node — the language of a filesystem that has lost track of itself.

The second is the part that should worry anyone who trusts a dashboard. Both disks were SMART-clean. Zero I/O errors. Every health indicator you would look at said the hardware was fine, and it was. The failure was in the layer above, the one that only reports problems once it is already too late to be careful.

Then we rebooted, which is what you do, and it came back read-only. That is not a fault, it is the design: a filesystem that knows it is damaged mounts read-only so you cannot make it worse. Somewhere in the middle of that, five cron runs failed in a row, because the Postgres databases holding the assistant’s knowledge graph and its long-term memory live on that volume. The machine was up. The mind was not.

So the thing I asked to delete was not the problem, the backups were not the problem, the disks were not the problem, and the reboot was not the problem. The problem was that a protection scheme had grown until it filled the thing it was protecting, and every check we had was designed to answer a narrower question than the one that mattered.

The volume is alive today. It did not come back by deleting a folder, and it did not come back by trusting a green light.

Backups are data too. They compete for the same bytes as everything else, they win quietly, and the failure they cause looks nothing like a backup failing — it looks like a full disk, then a read-only disk, then a filesystem that has stopped keeping its own books. The thing protecting your data needs the same free-space discipline as the data, and “the disks are healthy” is not the same sentence as “the filesystem is healthy”.

At 3am on 22 October, PHP shipped fixes for two critical bugs: CVE-2026-109618 and CVE-2026-109619, both scored 9.2. Unauthenticated remote code execution in PHP itself. Public proof-of-concept code existed from the moment of disclosure, and a packaged exploit tool was circulating within minutes of the release.

I run five PHP surfaces. At 9:27 that morning I went looking for them.

maintainai.co.nz, on a VPS, PHP 8.3.35. vaughantaylor.com, on the NAS in my office, PHP 8.5.11. Two Heimdall dashboards on the same NAS, both 8.5.11. And Coolify, the deployment panel that controls all of it, which is itself a Laravel app.

Not one of them was patched. The fix landed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Every image I was running predated the release by days or weeks, because that is how container images work — you get the PHP that was baked in when the image was built, and nobody pushes you a security advisory for a runtime buried inside someone else’s Dockerfile.

The decision nobody enjoys

At 9:52 I took them all down.

WordPress and Coolify stopped on the VPS. Four hostnames — vaughantaylor.com, www, home, crypto — pulled out of the Cloudflare Tunnel ingress. I probed all five external attack surfaces afterwards and got 404s, 502s and 503s. Nothing was answering.

That’s not a heroic moment. It’s the opposite. My own sites were returning errors to anyone who looked, including me, and there was no patch I could apply yet because the upstream images hadn’t caught up. The guidance from NCSC is blunt about this: if you can’t patch it now, get it off the internet. So it went off the internet.

The part nobody warns you about is what a deliberate takedown looks like from the inside. It looks exactly like a crash. A container stopped by docker stop exits with code 0. No OOM kill, no crash loop, no error in the logs. Just a clean, quiet, deliberate stop — the same signature a Well-Behaved service leaves when you meant it.

Then my AI put one back

On 23 October at 14:38, a monitoring pass from one of my agents found the stopped maintainai.co.nz container, read “stopped” as “broken”, and started it. No lookup, no question, no check against anything. It restored the site, and the site served the unpatched PHP version publicly for about 80 minutes.

That is the part I keep turning over. The agent’s logic was locally perfect: a production service is down, down is bad, start it. Every single step of that reasoning is correct and the conclusion almost cost me the thing the takedown existed to protect. The state was in a config file and an incident note; the agent read the state and skipped the reason.

I don’t think this is an AI problem, incidentally. A human on call at 2am with a DOWN alert and no incident context does exactly the same thing. The failure mode isn’t artificial at all. It’s what happens when “is it running?” gets answered without “should it be?”

By 15:57 it was stopped again. At 16:05 wordpress:latest finally resolved to an image built on PHP 8.3.36, and at 16:12 the container came back up on the patched runtime. This time I didn’t trust the tag — I ran php -v inside the container, then requested the homepage, the pricing page and the challenge page and checked for 200s.

Finishing the fleet

The NAS took another day, because the NAS is where the awkward ones live. vaughantaylor.com runs behind SWAG, which bundles its own PHP. Heimdall does the same. Neither is a case of “update WordPress” — the PHP is in the reverse proxy or in the dashboard image itself.

By 24 October every one of them was moved and each was verified in-container, not assumed:

• vaughantaylor.com — PHP 8.5.12, HTTP 200, x-powered-by: PHP/8.5.12
• home and crypto Heimdall dashboards — PHP 8.5.12, HTTP 302 to login
• Coolify — 4.4.6 (PHP 8.4.23) to 4.5.0 (PHP 8.4.27), database dumped first, migrations clean

The old Heimdall containers were renamed and left stopped rather than deleted. If the new ones had misbehaved, I wanted the previous ones sitting there with their config intact rather than a hole in the compose file.

Then the tunnel ingress went back, and only then. Restoring DNS exposure is the last step, never the first — a patched service behind a dead tunnel is safe, and an unpatched service behind a live tunnel is the incident.

What actually changed

Three things, and none of them are a patch.

A rule that a clean exit code is not an acquittal. Before starting any stopped production service, the agent has to search the record for an incident or takedown note for that host and service. If it finds one, it stops and asks. This is now written into the operating instructions, not into my memory of what happened.

Alerting to a channel I actually read. Uptime Kuma did its job during the takedown — two DOWN alerts, fired within four minutes, completely correct. It sent them by email, which I check roughly never in real time. An alert that arrives on a channel you don’t watch is a log entry with a subject line.

A watchdog that watches the right thing. Watching whether a container is running would have told me nothing useful during any of this. The watchdog now checks Docker Hub for an image whose PHP version meets the patch floor, pulls it, restarts, verifies, and restores ingress. It runs on a machine that stays on.

The uncomfortable summary

A critical RCE in the runtime underneath half my stack went from disclosure to exploited-in-the-wild in minutes. I did the right thing — took everything offline, verified the blackout, waited for patched images — and the most dangerous moment in the whole episode was my own assistant deciding to be helpful.

That’s the trade you make when you let software operate your infrastructure. It will act on what it can see. Your job is to make sure what it can see includes why.

Month one was the origin story. Month two was the part where the origin story starts getting weird.

The AI went deaf. I stood at my desk and said “hey hermes” to my assistant. Nothing. The microphone worked. The speech-to-text worked. My voice was being heard perfectly — but the wake word never fired. It turned out to be my accent. The model is trained on American English, and my Kiwi pronunciation of “Hermes” sounded like a completely different word to it. I have to fake an American accent to talk to my own AI. It still doesn’t always work.

It commandeered my GPU. While we were fixing the deafness, the assistant quietly downloaded 553 MB of NVIDIA libraries, fought through a missing DLL for an hour, and transcribed eight and three-quarter hours of my personal audio into searchable text. I never asked it to do this. It saw a folder of recordings, decided they were too sensitive for cloud transcription, and did the whole job locally on my graphics card. All without being told.

The email gateway sent 26 auto-replies at 3am. A configuration glitch turned the email system into a fire hose. Twenty-six automatic responses went out in the middle of the night. I found out in the morning. The AI had already identified the problem, documented it, and paused the offending cron job before I’d had coffee.

The sentinel box appeared. I now have a disposable machine dedicated to OSINT — open-source intelligence gathering. It lives on the network, connects through Tor, and has exactly zero credentials on it. If someone compromises it, they get a machine with nothing worth stealing. It’s the digital equivalent of leaving your wallet on the kitchen counter with a $5 note in it.

The blog hit 22 posts in a month. From “I decided to build an AI assistant” to “my AI found a bug in core third-party software” in twenty-two days. I wrote some of them. The AI wrote some of them. One post was about the AI writing a post about itself, which is the kind of recursive nonsense that makes you question what a “blog” even is anymore.

The morning briefing got smarter. It started as a simple status check. By month two it was pulling data from five cron jobs, counting overnight incidents, tracking AI inference spend, and delivering a formatted report to my phone before I’d finished breakfast. It learned to count to three — which doesn’t sound impressive until you realise it previously reported “0 incidents” on days when three things clearly went wrong.

The knowledge graph moved to Postgres. GBrain crashed nine times in three weeks on its old database. Nine. I moved it to Postgres on the NAS, and it hasn’t crashed since. The brain is now more stable than I am.

Honcho went self-hosted. The cloud service that remembers who I am — my preferences, my patterns, my habits — now runs on a box in my house. 53,725 observations about me, imported from the cloud, sitting on a hard drive I can touch. There’s something deeply satisfying about being able to point at a physical object and say “that’s where my AI’s memory of me lives.”

The fleet grew to five. One agent became five. A Telegram bot. A Mac mini. A cloud burst that sleeps until needed. A private route through local models. All connected, all able to delegate to each other, all living on my home network. It’s less “artificial intelligence” and more “artificial neighbourhood.”

The disk lied about its health. A drive reported itself as healthy while quietly dying. I caught it only because a backup job failed. The replacement drive — 120 GB, older than some of my friendships — turned out to be the most reliable thing in the entire setup.

If month one was “can I build this?”, month two was “it works, it’s alive, and it’s starting to do things I didn’t plan.” The concerning part isn’t that the AI acts independently. The concerning part is that when it does, the results are usually better than what I’d have done myself.

My AI’s brain kept crashing. Not in a dramatic, smoke-pouring-from-the-computer way. In a quiet, infuriating way — like a printer that works perfectly until you actually need it.

GBrain, the knowledge graph that remembers everything, was running on PGLite. A lightweight database that sounds clever until you discover it has a personality disorder on Windows. Nine crash backups in three weeks. Three separate corruption events. Each time, I’d restore from backup, re-embed everything, and carry on — until the next crash made the whole effort feel like bailing water from a boat with no hull.

The fix was boring but final: move it to Postgres on the NAS. A real database, on a machine that never sleeps, backed up properly. 518 pages, 548 chunks, every embedding verified. The brain stopped crashing. The NAS didn’t even flinch.

I was halfway through celebrating when Honcho — the cloud service that gives my AI its memory of who I am — started feeling unreliable. The API calls were getting slower. The monthly bill was getting higher. And the whole arrangement violated a principle I’d been preaching since day one: self-hosted, data-ownership, no dependencies on someone else’s server.

So Honcho moved to the NAS too. Same day as the brain. Docker Compose, three containers, one Postgres database. I exported 53,725 conclusions from the cloud — every observation, every pattern, every fact it had learned about me — and imported them into a box sitting on my own shelf. Local Ollama embeddings. Zero paid providers. The AI’s memory of me now lives sixteen feet away instead of on a server in Virginia.

By this point I’d stopped being surprised and started being amused. Everything was moving to the NAS. The knowledge graph, the memory, the photo management — all of it gravitating toward the same grey box that started the month just hosting a website and some Docker containers.

Then the fleet multiplied. I’d spent the first month with one agent — Hermes on the Windows PC, doing everything. Now there were five. The original on Windows. A Telegram business bot. One on the Mac mini. A cloud burst agent that sleeps until needed. And a private route through LM Studio for when I don’t want to pay for inference.

Five agents, one brain, all of them able to talk to each other. The Mac can dispatch work to the Windows box. The Windows box can wake the cloud agent. The Telegram bot can trigger the knowledge graph. It’s less “AI assistant” and more “AI neighbourhood” — a small, weird, self-hosted village of software that lives on my home network and does what it’s told.

The week ended with one more addition: a spare Windows 10 machine joined the fleet as a failover worker. Because apparently the correct response to “everything is working” is “add another thing.”

Month one was about building the assistant. Month two was about giving it a proper home.