Half of what my agents wrote, nobody ever opened

My agents have produced 444 cards since 15 July. This morning I counted how many of them a human being has ever opened. The answer was 222.

Exactly half, to the card, on the day I happened to look. The clean split is a coincidence of the date. The half is not.

I have spent eight weeks making a fleet of scheduled agents better at producing work. Every measurement I took was a production measurement: cards per day, cost per run, how many runs finished, how many failed. Not one of them asked the only question that pays: did anything come out the other end.

The part that works

Let me be fair to the machine first, because everything after this is criticism and none of it lands on the models.

The fleet runs between half past midnight and two in the morning on a second-hand laptop in my flat. It writes drafts, files press submissions, reads analytics, proposes topics, comments on its own reports. It costs about $24 a day and it has produced 8.3 cards a day for eight weeks. It is not flawless: of 329 scheduled runs, 34 failed and 3 were skipped, which is a failure rate just above 10 percent. That rate has never once been the reason a piece of work did not ship. If you had told me in July that this would be the boring part, I would not have believed you.

So this is not a piece about hallucinations or output quality. It is about what happens to good work when it arrives at a queue with one person standing at the end of it.

The acceptance rate, by card type

Here is the measurement, verbatim, run read-only against the production database this morning. Acceptance is counted as accepted over accepted plus dismissed, so only cards that actually got a decision. An open card is not a no; it is worse, and I will come back to it.

Read that column from the bottom and it tells an unflattering story about its author. The two types I reliably accept are cards I wrote myself, at 90 percent, and cards that ask me to fix the machine, at 70 percent. Reviewing and publishing an article sits at 55 percent. Press submissions, 47.

Then it falls off a cliff. Community posts, 11 percent. Sales inbox, 7. LinkedIn posts, 1 accepted out of 32 decided. X posts, decisions to place a bet, comments on my own reports: 35 cards, three types, zero acceptances between them across seven weeks.

The pattern is not about quality. It is about direction. Anything that stays inside the workshop gets through. Anything that has to leave my desk and appear in front of a stranger stops at me. I built a marketing machine and then became the part of it that faces the market, which is exactly the part I was trying to automate.

The week nobody was home

Between 24 and 30 August the loops produced 49 cards. Not one of them changed state by my hand. The only human trace in those seven days is three clicks on a single card on the Monday morning.

What makes that week worth a figure is not the gap. It is that nothing noticed. Forty-seven runs went out that week and six of them failed, a slightly worse rate than usual, and it made no difference whatsoever: the 41 that succeeded filed their cards into the same silence as the six that did not. No monitor fired, because there is no monitor for this. Every alarm I have built watches whether the machine did its work. None of them watches whether the work was taken. A queue has no way of knowing that nobody is reading it.

And here is the part I find hardest to write. In those same seven days I made 19 commits to the project that produces these cards, and 86 across all my repositories. The tool got measurably better every day of a week in which it delivered nothing at all. That is not a scheduling accident. That is a preference, and it was mine.

Two clocks

Cards that I eventually threw away lived an average of 9.4 days. Cards I acted on lived 6.6. Work I keep moves through the queue faster than work I bin, which means the extra three days on the rejected pile are not deliberation. They are the time it took me to get round to saying no.

The table underneath is the uncomfortable one. An agent’s card gets a decision within a week or two, usually a rejection. My own cards get accepted nine times out of ten, and more than half of them are still open a month later. I am a fast and ruthless reviewer of the machine’s work and no reviewer at all of my own.

There is one more entry in the event log that I would rather not publish. On 6 September I dismissed 26 cards in a single day. That is not triage. That is a bin day, and a bin day is what a queue produces when nobody has been to it in a while.

What one accepted card costs

I have already written about what this whole setup costs to own. The figure that matters here is narrower and it is the one I had never calculated.

$3.40 buys a card. $18.16 buys a card that was used for something. Neither figure is large in absolute terms, and that is precisely what makes them dangerous: at this price nothing forces the question. A machine that costs $24 a day never sends you an invoice big enough to make you ask what you got.

For completeness, and because this site promises that every number comes out of a log on my own machine: the illustration at the top of this article took two runs at an image model, $0.039 each, $0.078 for one usable image. The first attempt wrote a garbled word into the bottom right corner, which a picture on an English page has no business doing, so it went in the bin. Both runs are booked. The four figures in the body are not model output at all: a script renders them from the query results, and it ships alongside the draft.

I had written $0.134 there, and it was wrong, and finding out why belongs in this article more than the number does. The script that makes the cover carries a comment naming the model it uses and the reason for choosing it. The script cannot choose. There is no model argument in that code path at all: the generator takes whatever a configuration file two directories away happens to say, and mine said something else. So it ran a cheaper model than the one I documented, at a third of the price, and every word of my justification was about a decision I had not actually made.

The only reason I know is that the booking records the model that ran rather than the one that was asked for. That was a deliberate choice by whoever wrote it, with a comment explaining why: of two versions of the same value, the more accurate one is the one nobody reads. It caught me forty minutes after I wrote the sentence.

Two failures that look like agent failures

While measuring all this I found two things that a casual reader would file under “the AI got it wrong”. Neither is. Both are wiring.

A gap between two constants in two repositories

The writing pipeline stops working on an article once its grade reaches 7.0. The comment next to the constant says so: at or above this, ship it, no more rewriting. The publishing path, which lives in a different repository, would only take an article at 8.0 or better.

Nobody wrote that rule. It is the arithmetic of two numbers that had never been read side by side, and it means every article between 7.0 and 8.0 was manual labour by construction. The pipeline considered it finished; the exit would not take it. Measured against the production database this morning: 446 of 635 graded blog articles sit in that gap. Only 176 clear 8.0.

The card generated for those articles has the worst record in the entire system. Grouped by grade, over the whole history:

Sixteen chances, zero acceptances. For seven weeks the system reliably produced a card that asked me to do something I had never once agreed to do, and it produced it faithfully, on time, every night.

A queue that erases its own history

The second one cost me something real. Across 13 runs of the community agent, 22 discussion threads were proposed and 12 of them came up more than once. One thread was proposed in 11 of the 13 runs, over four weeks. One forum appeared in 12 of 13. The result was five comments from me in one day across two forums, one of which the platform removed. On a community site that is not untidiness, it is spam, and spam costs the account.

The obvious fix is a filter: before proposing a thread, check whether it was proposed before. That fix would have found nothing at all. The approval queue is a snapshot, and its update function replaces every entry belonging to a platform on each run, so each run quietly deletes the evidence of the one before it. A filter over an empty set filters nothing and looks exactly like a guardrail while doing it.

The cause was never the missing filter. It was the missing record. The fix is a journal that sits beside the queue rather than inside it, because a snapshot deletes and a journal appends, and only one of those can answer the question “have we been here before”.

Where I was wrong, and what caught it

The same week, I wrote a cleanup rule for a different pipeline. Some articles came back from the model with an unclosed code fence, an artefact of the wrapper the model had put around its own answer. My rule counted the fences: an odd number means one is unmatched, so cut from the last one and throw away everything after it. It is a clean rule. It is obviously right. It fits on one line.

Before letting it touch anything I ran it dry across the existing articles. It found one with seven fences, all of them legitimate, and proposed to delete 3,251 characters of real article text from an article that was already published. A footnote explaining a pricing calculation. Nothing about it looked like model debris. My rule would have deleted it in silence and the article would have stayed live, shorter, and nobody would have known which paragraph was missing.

The rule now requires exactly one fence, not an odd number of them. Where the unmatched fence cannot be identified without ambiguity, the cleanup does nothing and says so. An article with seven fences and an odd count is still broken, but it needs a person, not a knife.

What I changed, and what this morning said

Yesterday I closed the gap. The publishing threshold moved from 8.0 to 7.5, which keeps it above the point where the writing pipeline stops, so it remains a real filter, and puts it inside the range I have in fact published 446 times. And a run that produces an article below the exit threshold no longer raises a review card at all: it closes its own card with the grade recorded in the event log, so the fall is loud rather than silent.

I scheduled the counter-measurement for this morning, before I knew what it would say. Here is what it said.

The publishing run went at 05:15. It checked 28 drafts and published none. The log line underneath explains why: three announcements are open against a ceiling of two, so there were no free slots, and eight articles are waiting for later runs. Live article count yesterday: 415. Live article count this morning: 415.

So the gap closed and the queue moved up one step and stopped at the next ceiling, which is also mine. That is not a failed fix. It is the ordinary shape of this kind of work: you do not remove a bottleneck, you find out where the next one lives. It happens to live two metres from the first.

There is a second finding from the same build that I nearly missed. Of the 78 review cards in the system, 42 carry no reference to the article they are about. The threshold logic reads the grade through that reference, and where there is none it correctly does nothing. For more than half the cards, the fix I had just shipped would have sat there doing exactly nothing, and every log line would have looked healthy. That is the most dangerous way to be ineffective, because it does not resemble a failure.

What I would tell anyone building this

Instrument acceptance before you instrument production. Cards per day, runs completed, cost per run, tokens: all of that was on a dashboard within a fortnight, because it is easy to count and it goes up. Acceptance rate per card type took me until this morning to write, it is nine lines of SQL, and it is the only number in this article that tells me whether any of it was worth doing.

An agent that files nine cards a day and gets one accepted is not nine tenths of the way to a working system. It is a working system pointed at a queue that cannot absorb it, and every improvement to the agent makes the mismatch larger.

444 cards. 222 that nobody ever opened. 19 commits in the week nobody came. The machine was never the part that needed the work.

All figures measured on 7 September 2026 between 08:30 and 08:50 Vienna time, read-only, against the production databases on my home server: the ticket, event and run-cost tables of the operations database, and the article table of the writing pipeline. The acceptance table was produced by a nine-line script that ships next to the draft of this article, so the measurement can be repeated rather than trusted. Model spend covers the scheduled loops on that machine only; my own sessions are a separate ledger and roughly twenty times larger per day. The commit counts are path-limited to the relevant project and to the whole monorepo respectively. Two figures in this piece were generated by an image model at a booked cost of $0.268 for the pair, one of which was discarded.