Trust Is Not a Vibe

Originally published in my newsletter, In General — one useful thing I tried, built, or figured out each week. Subscribe here.

The Happy Path Lied

The clearest example was a job I set up to post GetMusic catalog releases across six social media sites. I set it up as a cron job in OpenClaw, and it worked for a week or so. Then it started failing.

I did not notice right away. Posts were not being published, but I was not checking all six social accounts every day, so it was easy to miss.

The problem wasn’t only that the job failed. The bigger issue was that I did not know it had failed, and I had no quick way to see what was going on inside the system and fix.

It Was a Management Problem

The failure was not that the agent job broke. Jobs break.

The failure was that I treated a recurring operational responsibility like a one-time demo.

That is not how I would manage a person. If someone were responsible for GetMusic social posts, I would not watch them do it once and then stop checking. I would define the job, the cadence, the expected output, and what should happen when nothing goes out.

I did not do that with the agent. I gave it work and assumed the system around the work would take care of itself.

Receipts, Not Status

A status update is not enough. I do not want an agent to tell me “done” unless there is something I can inspect.

When monitoring code creation, I could use a diff, RSpec test output, or a screenshot.

For operations work, the receipts look different. I’m using logs, published outputs, delivery records, support queue checks, and alerts when the expected work does not happen.

The point is not to create paperwork. The point is to make the work reviewable.

What I Needed Instead

Every recurring agent job needed a clearer contract.

What is supposed to happen? When should it happen? Where should the output go? What counts as a successful run? What should happen if nothing runs, or if the output is wrong?

For the GetMusic posting job, that would have meant one place showing the expected cadence, the last successful post, the channels posted to, and whether anything had gone stale.

That would not have prevented every failure. But it would have changed the failure from silent drift into something I could see and fix.

Trust Comes From the Trail

This failure pushed me to build Glance, a system that monitors whether automated work is actually delivered.

Not to watch agents perform, but to watch the expectations around the work: what was supposed to happen, what actually happened, what went stale, and what needs attention.

I wanted one place to see whether the automated work I depend on matched what I originally assigned.

Trust did not come from watching the work happen.

It came from what the work left behind.

If I want agents to do real work, I need the same things I would need from any delegated work: expectations, receipts, and escalation.

Otherwise, I am not delegating.

I am hoping.