By Rolf Versluis · Published September 1, 2026 on Uncommon Knowledge in Business and Life

Open-source software is almost always 95% ready to go. You download it, you run it, it mostly works. Then you gotta install it, configure it, integrate it with whatever else you've got running, lock it down, and tune it for your situation. That last 5% is where most projects die. The work's not hard. It's fiddly, undocumented, and never quite the same twice.

I've seen this pattern for 20 years. I reach for nginx most often. It installs in a few minutes, then I still gotta set it up, integrate it, and harden it. Those are the small decisions nobody writes down.

I wanted an agent doing that work with me. Didn't have one ready. That's what the camera project proved: get the agent to handle the fiddly bits.

The farm camera example

I bought an IP security camera for the farm and mounted it on the building. Wanted it to do one thing: when somebody drives onto the property, send me a Telegram message with a picture, and tell me if it's someone I know or someone I don't.

That sounds simple enough. The hard part is the "someone I know" piece. I tried a trail camera with a SIM card first. It handled the first half: motion alerts with pictures. Figuring out "is this person known?" means looking at the picture, comparing it to the people I've seen before, and making a judgment. No tool out there does this.

The agent and I looked at what was available first. Nothing worked the way I wanted. Built it from scratch. Took a few months.

I laid out the architecture in four stages, each one filtering out the noise before the next stage has to deal with it.

I put a Reolink camera on the property. It fires an HTTP webhook at a Flask listener I set up on port 8090. I wrote the listener to peel frames from the camera's RTSP ring buffer and route by camera and event type.

First thing I do is run YOLO on each frame. I set it to drop any frame with no real object. Roughly 99% of false positives die there. I never call the expensive vision model for events that don't matter.

When YOLO says yes, I pass two tight cropped boxes to Qwen3-VL running locally on port 8093. Two streak crops plus the pairwise differential between them. It returns structured output: make, model, color, body style, confidence. That's what turns "vehicle" into "black Ford F-150 pickup."

The matcher scores that signature against data/vehicles/known_vehicles.json, an enrolled store of vehicles I've shown the system before. I set it up to answer one question: known or unknown?

A small text model on port 8081 writes the human-readable alert body. I wrote the prompt so it'd produce readable text. Instead of "VEHICLE DETECTED" it writes "Black Ford F-150 on the north road."

Then the alert goes to Telegram through the bot API. Two seconds from motion event to phone.

Jill, a Hermes instance running on a local model, proposed how to break the problem into stages, picked the free tools, wrote the integration code, and debugged the connections between stages. I laid out what I wanted the system to do. Took a few months. The design calls were mine and the agent handled most of the implementation.

The first version sucked. The motion gate let tires through, the vision model mistook shadows for trucks, and the matcher said everything was unknown because the enrolled store was empty.

I kept a log of the wrong cases. Each one pointed at a small fix. Adjusted the YOLO confidence threshold. Made the differential crop hug the motion tighter. Added the truck to the enrolled store. Each fix taught the system something the next alert would benefit from.

After a few months of running it, the false positives dried up. System figured out who was at the property, took a picture, and sent it to me.

The 5% is also the part no vendor will sell. Too specific to any one property, any one set of cameras, any one definition of "known." A vendor sells a generic product. I built the specific thing.

Most people quit at 95%. I don't.

My clients ask me to implement Hermes agents for pieces of work. I look at what already exists first, pick the best option, install and configure it, then build the 5% that turns whatever I found into something that works for them.

For some projects, the 5% is configuration. For others, it's integration with the rest of their stack, or writing a custom classifier or workflow. The work changes from project to project but the pattern's the same.

The kind of problem I work on is that open-source tool sitting at 95% with the last 5% keeping it from being useful. Camera monitor's at github.com/blockops1/ai_camera_monitor, MIT-licensed. My address is localhermesagent.com.