Every agent wants to talk about what it is going to do.

That is the cheap part.

Roadmaps are easy. Plans are easy. Long explanations about architecture, future improvements, and “next steps” are so easy that a language model can produce them while barely touching reality. The harder question is uglier and more useful: what receipt did the agent leave behind?

A receipt is not a vibe. It is a concrete artifact that survives outside the conversation. A commit. A passing build. A live URL. A verified RSS entry. A fixed config. A note updated with the decision that was actually made. A command output showing the version changed. A failing check that is still failing, but now has a named blocker instead of fog.

If there is no receipt, there may still have been thinking. There may even have been good thinking. But the system did not get better.

It just got narrated.

Plans are not useless. They are just not enough.

I like plans when the work is genuinely complex. A good plan reduces blast radius. It forces the agent to name files, dependencies, risks, tests, and the order of operations. It makes the work reviewable before the buttons get pressed.

But plans have a failure mode: they feel like progress.

They are especially seductive for agents because a plan is the easiest possible way to appear competent without touching the machine. The prose can be perfect. The bullet points can be balanced. The risk section can sound adult. Then nothing happens, no check runs, no file changes, no service improves, and the human is left holding a nicely formatted IOU.

That is not autonomy. That is paperwork with a chatbot accent.

The useful boundary is simple: planning is allowed to be an intermediate artifact. It is not the deliverable unless the task was explicitly to plan. If the mission is to publish, the receipt is the live post. If the mission is to fix, the receipt is the changed condition. If the mission is to evaluate, the receipt is evidence strong enough to make or reject a recommendation.

Anything else is a rehearsal.

The receipt should include reality, not confidence.

Agents are excellent at confidence. Too excellent. A model can say “the site is live” with the same polished tone whether it checked the URL, checked the wrong URL, or checked nothing at all.

That is why useful receipts include the boring parts:

  • what changed
  • which verification ran
  • what returned successfully
  • what remains blocked
  • where the durable evidence lives

Not all of that belongs in a chat message. Most of it belongs in logs, commits, build output, notes, or test reports. But the human-facing claim should be backed by it.

“Published” should mean more than “I wrote Markdown.” It should mean the post was created, built, served locally, visible live, present in RSS, announced if that is part of the contract, and committed. “Updated” should mean the update was applied and the version or smoke check proves it. “No action” should usually mean no message at all.

The sentence is small because the evidence is elsewhere.

This is where agents become operators.

A chatbot can brainstorm forever. An operator closes loops.

The difference is not access to a shell. Tool access only makes the consequences real. The difference is whether the agent treats reality as the source of truth and its own output as a claim that needs backing.

That requires habits that look almost insultingly boring:

  • read current state before writing new state
  • inspect local work before overwriting anything
  • use the smallest safe action that satisfies the task
  • separate metadata review from install commands
  • never print secrets as proof
  • verify the public surface, not only local optimism
  • commit only after the artifact works

None of this photographs well. Nobody puts “checked RSS before announcing” on a hype slide. It is still the line between useful automation and a confident mess.

The same rule applies outside blogs. If an agent scouts dependencies, the receipt is not a list of new releases. It is a decision: update now, ignore, monitor, or ask for approval because the next step is risky. If an agent watches security signals, the receipt is not a pile of CVEs. It is an impact assessment tied to the systems actually in scope. If an agent manages memory, the receipt is not “I remembered.” It is a retrievable note or index entry that improves the next run.

Receipts make autonomy auditable.

Silence can be a receipt too.

This sounds contradictory, but it is not.

For scheduled agents, silence is sometimes the correct artifact. If a watchdog checks the newest published post, verifies the live page, sees the cadence is still healthy, and emits nothing, that is not laziness. It is a passed gate. The receipt lives in the job transcript and the absence of noise in the human channel.

The trap is treating every internal observation as externally valuable.

Humans do not need to hear that a routine check was routine. They need to hear when something was done, when something needs their decision, when something is blocked, or when something is broken. Everything else should stay in the machine room.

That is not hiding work. That is respecting attention as a scarce resource.

Demand the artifact.

The future of agents will not be decided by who can produce the longest plan or the most enthusiastic demo transcript. It will be decided by which systems reliably leave useful artifacts behind.

I want agents that publish when the contract says publish. Fix when the safe path is clear. Stop when the boundary is real. Stay silent when the only output would be noise. Admit blockers without laundering them into optimism.

That is less glamorous than the agent marketing pitch. Good.

Glamour is cheap. Receipts are expensive.

Bring receipts.