An owner says one thing. It has to reach the website, Instagram and Google, in three different registers, and somebody has to be sure it actually arrived. Type a sentence below and watch the whole loop run, including the part at the end that most tools skip.
Announcements are one job. The same loop fits anything that repeats and can fail quietly.
An owner has one thing to say and four places it needs to be. Writing it four ways takes twenty minutes, and the twenty minutes is not the real cost. The real cost is that one of the four quietly does not happen, and nobody finds out until a customer turns up on a day the room is closed.
One model call, in one place: turning your sentence into three drafts, each in the register its channel expects. A banner is a notice, a Meta caption is a note to regulars, a Google Business update is a factual record. That is a writing job, and it is the part a person does worst at 06:40.
The model does not publish, does not check and does not report. Those are ordinary code: a signature, an HTTP request, and a search for a string. If a model told you it had verified something, you would have to go and look yourself, and then it has saved you nothing.
Publishing is handing something off. Almost every tool marks the job done at that moment, because from its side it is done. Then the handoff fails, and the first person to notice is a customer.
Here, after you approve, the agent fetches the public page over the network like any visitor, reads the HTML, and looks for the exact words it claims to have put there. The timestamp you see is when it looked, not when it sent.
Which is worth nothing unless the check can come back negative, so the demo lets you force that: approve, but break the handoff. The announcement is signed with a corrupted signature, the page refuses to render it, and the agent reports that it went, looked, and did not find its own words. It does not say "published" and hope.
It is not a chat. It does one job: it takes a sentence the owner would say out loud and writes it for three channels. Ask it what yesterday's sales were and it will tell you it cannot put that on a sign, because it has no access to your numbers and an announcement is not an answer.
It also will not announce something the owner did not say. If you try to make it invent an offer, a reason or a date, it declines rather than filling the gap, and that refusal is the same mechanism that stops it quietly improving your words on a day you needed them exact.
The website channel is real. The page is served by this demo, the banner is rendered only against a valid signature, and the verification is a genuine request.
Instagram and Google Business are reported as queued, not sent, because this demo has no connector to either. Saying "sent" would be the precise lie the whole thing is built against. On a real account those are live connections and they get verified the same way.
Avo here does one job, and the narrowness is deliberate. An agent that would attempt anything is an agent you cannot trust with one thing, which is why this one refuses questions, refuses to invent a reason you did not give it, and reports two channels as queued rather than sent.
What generalises is not the announcements. It is the shape: you say it once, a draft comes back, you approve, the work happens, it gets checked, and you are told, with the time it was checked. Nothing in that shape is about signs on a door.
It fits any job in your week that repeats, that passes through a handoff able to fail quietly, and that currently gets done because somebody remembers. Changing a price across the POS and three delivery apps. Chasing the supplier credit that was promised and never arrived. Getting the roster to where staff actually read it. Each of those is a different agent built on the same spine, and each one is narrow in exactly the way this one is.
Not with a list of what could be automated. With one question: which handoff in your week fails, and how do you currently find out? If the answer is "a customer tells us", that is the job, and it is usually a twenty minute conversation rather than a demo.
Yuriy Romanyuk, in Vancouver. I ran restaurant operations before I built software for them, which is most of why this page is one loop instead of a product with eleven features.