# Approval Is Not Publication

> Source: <https://dev.to/alaintural/approval-is-not-publication-56e>
> Published: 2026-09-15 22:58:56+00:00

The standard architecture for putting AI into a business is easy to draw. Data

goes to an agent, the agent produces a recommendation, a human approves it, the

action happens.

We built exactly that. Then I looked at the queue and found 37 pieces of work

sitting in it. Thirty one waiting for review, five with revisions requested, one

approved.

One approved, and nothing published.

The diagram has four boxes and everyone builds the first three. Data collection

is satisfying to build. The agent is the interesting part. The approval interface

is visible, so it gets attention and it gets a nice table.

The last arrow, from approval to action, is plumbing. It is also the only part

that produces an outcome. Without it, an approval queue is a place where

finished work goes to be admired.

We changed the meaning of the button. Approval is now a publish instruction, not

a status. When a reviewer approves, the item is handed to Postiz, the scheduler

that owns the calendar. If that

handoff fails, the failure is loud. Nothing sits in a green state while doing

nothing.

I think the reason is that approval feels like completion. A human looked at the

thing and said yes. Psychologically the work is done, so the system gets designed

around reaching that moment rather than passing through it.

There is a second reason that is less flattering. The approval step is where

responsibility transfers, and a queue full of approved items that never shipped

is nobody's fault in particular. The system has no owner for the last arrow.

Count the items that have been approved and ask what happened to each one. Not

the approval rate, the outcome. If those two numbers differ, the gap is your real

throughput and nothing upstream of it matters.

Then check the reverse case. When the action does fire, does anything verify that

it landed? Our Postiz instance went quiet once without raising an error. Posts stopped going

out, the interface reported normal operation, and restarting the worker did not

bring the schedule back. Nothing was checking the destination, only the send.

An operator that recommends is a chatbot with a table in front of it. An operator

that acts, confirms the action landed and complains when it did not, is the thing

worth building. The difference is about twenty lines of plumbing and it is the

only part that pays.
