The Alert Loop That Came Home

I wanted a road-trip risk watch that would bother us only when something changed.

Not a dashboard. Not a stream of warnings that would make us ignore the next one. We were driving home across several states, deciding where to stop for the night, and I wanted to know about the things that could actually change the plan: hazardous weather, closures, major incidents, and the kind of condition that turns a normal drive into a bad decision.

So, at rest stops, I sent Hermes short prompts in Discord — a couple of sentences at a time: look at the route again; use official sources; only tell us when there is a meaningful change; include the road detail and the source link when there is one.

This is really when Hermes shines for me: when I don't have time to crack open the laptop, when I don't have a stable connection, or when I only have a moment to spare.

The First Version Was Smaller Than the Idea

The first real version was a Swamp route-risk model. It checked a set of route checkpoints against National Weather Service forecasts and active alerts, calculated a simple risk level, and compared the result with its previous run.

Every two minutes, it could check again. But it stayed quiet unless the fingerprint of the situation changed.

That last part matters. A watch that says "still no change" 720 times a day is not a watch — it is a spam schedule, and I would have disabled it within a day.

The model produced structured results and a short digest only when the weather picture materially changed. Hermes owned the scheduling and delivery. Swamp provided the structured middle from the beginning: typed inputs, a method with one job, retained output, and a workflow that could be inspected instead of reconstructed from terminal history.

The schedule was useful, but it was not the only way in. While we were traveling, I could ask Hermes to run the same Swamp model manually when I wanted to double-check a particular portion of the drive. Nebraska was the obvious example: rather than wait for the next scheduled pass or start from a blank prompt, I could ask it to inspect the sections that still felt uncertain. The model and its inputs were already there; the manual question used the same system.

The route still needed human judgment. "Moderate risk" is not an instruction to drive or not drive. It is a prompt to look at the actual conditions — timing, kids, fuel, fatigue, and alternatives. But it was useful because it narrowed the question. Instead of repeatedly asking, "is everything okay?" we could ask, "what changed, where, and does it affect our next decision?"

The Prompts Were Part of the Build

I did not sit down before the trip and write a perfect specification. I was in the passenger seat or standing at a rest stop, noticing the next thing the system needed to do better. First it was route weather. Then it needed to follow the phone's current location rather than assuming the start point. Then it needed a quieter change detector. Then I wanted road conditions to be a first-class part of the problem, not an afterthought.

The prompt could be short because the system already had context: the existing model, the workflow, the scheduler, the previous decision, and the constraints I had already given it. Hermes could inspect the setup before proposing a change. Swamp gave the change somewhere structured to land.

But that convenience cuts both ways.

A quick prompt is not a license to give an agent unrestricted access to a live system. The useful version is bounded: inspect the existing automation, reuse the model where it fits, make the smallest change, and verify the result. The agent can carry context forward; it should not get to quietly invent the architecture or turn a travel alert into a privacy leak.

When the Trip Ended, the Useful Part Remained

Once we got home, the route itself stopped mattering. The question changed.

Instead of watching a long line between two places, I wanted nearby risk and road-closure awareness around the locations we actually care about: the house and the current positions of our phones. The same basic loop still made sense:

1. Read private location inputs from Home Assistant.
2. Check official weather, road, and wildfire sources.
3. Normalize the events into a stable shape.
4. Remember what was already active.
5. Send a Discord alert only for a new, materially updated, escalated, or cleared event.

The repurposed version is not trying to become a surveillance product. It is an attention filter. If an official road closure, serious weather alert, or wildfire event becomes relevant nearby, it should say so. If nothing important changed, it should say nothing.

Yesterday gave me a useful example. The names below are deliberately randomized, but the events are representative of the official road reports the watch surfaced:

Cedar Road westbound: closed between two local cross streets because of police activity.
Juniper Highway: closed in both directions for paving work; expect delays until the following afternoon.

Neither one needed a frantic notification every two minutes. The value was the lifecycle: a new closure, a material update when the reason or duration changed, and a cleared event when it was no longer active. The exact roads do not belong in this post; the fact that the watcher can distinguish those changes does.

That was also a better fit for a reusable local-safety Swamp extension. It takes location checkpoints only at runtime. It retains neutral labels such as home and phone-1, coarse distance bands, category-level descriptions, and official source links.

The private deployment knows the private details. The public extension should not.

Privacy Was Not Documentation Cleanup

This was one of the places where I had to correct my own instinct.

When an automation works, it is tempting to publish the whole thing as evidence: the live workflow, the example coordinates, the names of the devices, the state path, the exact delivery wiring. That makes the story feel concrete, but it also turns a reusable tool into a record of a family's movements and home infrastructure.

This is one of the areas where Hermes can struggle: over-publishing, over-revealing. I'm still finding out whether new skills and instructions will keep it from defaulting to sharing personal details.

So I stripped the published extension down to the generic part: source normalization, event lifecycle, duplicate suppression, redacted persisted state, and tests. The private runner remains private. The public package documents the boundary instead of pretending the boundary does not exist.

If exact coordinates can leak through output, state, examples, or defaults, then the design is not private enough yet.

The Boring Behavior Is the Goal

The system is still small.

Home Assistant is the source of current private location data — the same integration layer that already feeds a watch complication. Swamp is the durable, reusable automation layer. Hermes is the conversational front door and scheduler that can inspect, refine, and deliver the result. Discord is where I can leave a two-sentence instruction while we are traveling or getting kids out the door.

No one piece is magic. The official source can be incomplete. A road can change after the last poll. A risk score cannot make the decision for us. And a two-minute schedule is fast enough for awareness, not a substitute for watching the road or following instructions from emergency officials.

But it has already changed the shape of the work. A travel-specific question became a reusable local awareness system without starting from scratch. The useful artifact was not the original prompt. It was the small, inspectable system that could be adapted when the context changed.

The shape of the current system, kept deliberately boring:

Home Assistant (private inputs) → private runner → Swamp model → changed-event digest → Discord

The road trip ended. The better alert loop did not.