How AI manages my website and social media posts
This article, the social media posts that go with it, and nearly the entire flow between them were orchestrated by AI. The idea comes from my real activity. I approved two things along the way, and everything else ran on its own.
This article walks through how it works, and a bit of the journey that got me here.

How a post gets made, start to finish
It starts with an idea, and the idea comes from real activity rather than from a model being asked to be interesting. A sweep runs over the last seven days of my projects: code I committed, work I finished, decisions I recorded, notes I wrote. It comes back with two or three possible angles, each pointing at the actual work behind it. I pick one, or provide a different topic of my own.
An agent then writes the draft. Not from nothing: it writes against a profile built from my own past writing, plus every post I have personally approved. If the post is going to more than one platform, a separate step rewrites it for each one, so the same block of text is not pasted in three places.
Then it stops and waits for me to read the text.
If the post points at a longer article like this one, the article gets written too, and put in a holding area. Held, not published, and this part might be worth a moment: the writing system and website system are separate, independent projects. The writing project never puts a file inside this website project. It writes into a folder it owns, and the website project reaches over and takes a copy when I tell it to.
Then it stops and waits for me a second time to look at the finished page and make any revisions. Once it is approved the agent publishes it.
Only after that do the social posts go out, on a schedule, sent by a small program that wakes up when a scheduled task runs it and then shuts down again. It is not sitting there running all day. It writes nothing, and it has no AI in it at all. A test reads that program’s own code and fails if an AI library is ever added to it, by me or by an agent working on it, so the one piece that actually transmits stays a plain and predictable program. It reads approved posts out of a database and posts them to the different social media platforms.

Why a person still says yes twice
The gates exist because everything upstream of them can be wrong. An agent can write something inaccurate, or something I would not say, or something fine on its own that lands badly today. Once it is posted, it is public, and taking it down is not the same as never having said it.
So there are exactly two moments where the machine stops and waits for a person, and they are the two decisions that actually need judgment: is this the right thing to say, and is this page right to publish.
What makes those approvals worth something is that each one is tied to one exact thing.
When I approve a post, I am not saying it looks fine in general. I am approving one specific piece of text. The system takes a FINGERPRINT of those exact words, which is just a short code calculated from the characters themselves, and stores it. Before the post goes out, it recalculates the fingerprint and compares. If one character changed anywhere in between, the codes do not match and it REFUSES to send. It does not warn, and it does not send a corrected version. It stops.
So “I approved this” is not a memory or a promise. It is something the system can check, every time, and it does.

How it makes sure the article is really there
A post about an article has a link to that article in it. But the post is written and approved before the article is published, because the post is how anyone finds out the article exists. That means the link is a promise about a page that does not exist yet.
If the article never shows up at that address, every approved post points at nothing. And the wording cannot be corrected afterward, because changing it breaks the fingerprint and the post will refuse to send.
So before it sends any post carrying an article link, the program visits that address and checks the article is GENUINELY THERE.
Checking that the page loaded is not enough. A website can answer “here is a page” for an address that was never real, and hand back its homepage instead, which looks like success from the outside. So the check goes one step further: every real page on this site states its own address in its code, and the check requires that stated address to match the link in the post, exactly. A real article names itself. A stand-in page names something else.
If the article is not there yet, the post simply waits. That is not treated as a failure. Failures get retried a couple of times and then give up, which is right for a network problem and wrong for an article sitting unpublished for three days. So a waiting post keeps its place in the queue, emails me once the first time it waits, and shows up in my morning summary every day until it goes live.

Three things were wrong, and how the agent found them
All three of these come down to provenance: being able to say exactly where something came from, and prove it has not changed since. That sounds like a technicality until you remember whose name is on the post. If I approve a set of words and a different set goes out, or I approve a picture and a different picture goes out, then my approval bought nothing and I am publicly accountable for something I never actually saw. Fingerprinting is what turns “I approved this” from a claim into something that can be checked. Each of the three problems below was a hole in exactly that assurance, and none of them was caught by a test.
The first one: the words were protected and the picture was not.
The fingerprint covered the text and nothing else. The image was stored as a filename, and the file itself was only opened at the moment of posting. So in the gap between my approving a post and the post going out, that image could have been edited, replaced, or deleted, and nothing would have noticed. The guarantee covered half of what I was actually approving. The image now gets a fingerprint too, taken when I approve it and checked again before sending, and a mismatch stops the post exactly the way a changed word does.
The second one: the posting command silently ignored the article link.
The underlying code accepted the link correctly, and the automated tests called that code directly, so they all passed. Nothing carried the link from the command a person actually types. The result would have been a post that looked completely normal and skipped the safety check entirely. The agent found it while writing the instructions for how to use the thing, and then following those instructions literally.
The third one: the example had one picture in it.
The agent built a sample article to demonstrate the format, and it had a single image. One image cannot show what happens with two, so nothing in the format said where in an article a picture should go. It looked finished. The gap only appeared when the website side built against it and asked the obvious question. The fix was about thirty lines. Noticing it required a second picture to exist.
The pattern is worth keeping. What caught all three was writing the thing down, and handing it to someone else to use.

What this does not do
It does not make the writing good. Nothing in here checks whether an article is worth reading, and no amount of fingerprinting will rescue a boring post.
It does not prove who approved anything. It trusts whoever is at my keyboard. That is honest for one person working alone and would not hold up for a team.
And it does not remove me. It removes the parts where I was adding nothing but delay, and it puts my attention on the two decisions that actually need a person.
That is the trade I would make again. Not fewer humans in the loop. Fewer places for a human to be careless, and two places where being careful is the whole job.