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.