Approval Is Not Publication

A developer who built an AI agent approval workflow found that of 37 queued items, 31 were awaiting review, five had revisions requested, and only one was approved — with none actually published. The engineer redefined approval as a publish instruction handed off to the Postiz scheduler, making handoff failures loud, and added verification that actions actually land after a silent Postiz outage stopped posts without raising errors. The developer argues that an operator which recommends is just a chatbot with a table, while one that acts, confirms the action landed, and complains when it did not is the only part worth building.

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.