Sunday Setup: Check Your AI Agent Queue’s Age, Not Its Depth (Mine Was 107 Rows and a Median of 103 Days Old)

I ran my Sunday queue check this morning and the number came back healthy. 107 ideas in my keyword table, waiting to become blog posts. At roughly seven posts a week, that is fifteen weeks of stock. Comfortable. Nothing to do.

Then I sorted the same 107 rows by the date they were created instead of by priority, and the median age came back at 103 days.

Sixty of them are more than ninety days old. The oldest nine were queued on 7 February and are still sitting there, 231 days later.

The tip: a queue has two numbers, and depth is the boring one

Depth answers one question — will my agent have something to do tomorrow. It is the number every dashboard hands you for free, and I have written up both the ten-minute depth check and turning depth into days of runway, because five rows can mean zero days.

Age answers a harder question: how long does an idea sit in here before it ships? That tells you whether your agent is working on this month’s opportunity or last quarter’s. And unlike depth, age never trips an alarm. Nothing fails. Every run reports success. The queue is full. It is just full of February.

Receipt one: the depth was real, and it lied upward

Smaller lesson first. My first read of that table came back 52 queued. The real number is 107 — the API hands you a hundred rows and stops, and I counted one page. Exactly the mistake I wrote a whole post about: if your agent counts anything, make it turn the page. I own the post. I still did it.

Here is the age distribution, measured in my container this morning:

• 21 rows queued in the last 30 days
• 26 rows between 30 and 90 days old
• 60 rows over 90 days old — 56% of the queue
• Oldest row: 231 days

So the depth is honest as a count and useless as inventory. About 47 of those 107 rows are live candidates. The other 60 have been available every week for three months and lost every time.

Receipt two: that is not a backlog, it is a reject pile with the wrong label

The obvious theory is that the old rows are the hard ones, saved for later. The data says no. Thirty-seven of the 104 keywords I have published scored harder than 17 — the median difficulty of the sediment — and one was a 58. Difficulty is not what is holding these rows back.

Volume is. The rows over ninety days old have a median search volume of 190 a month. The rows that actually got published have a median of 2,400 a month — twelve times bigger. And every Monday my research agent adds nine or ten fresh rows that arrive at a median of 720. A 190-a-month keyword queued in February is not waiting its turn. It has been beaten by every arrival since, and it will be beaten again tomorrow morning.

Then the detail that settles it. The 7 February batch was 18 rows. Five were published. Four are explicitly marked Skipped. Nine are still marked Queue. My agent triaged that batch and then did not finish the sentence — the winners moved, the obvious rejects got labelled, and the mediocre middle kept the label that means ready. A status field perfectly capable of saying no, used to say not yet for two hundred and thirty-one days.

The ten-minute check

1. Pull every pending row. All of them. Paginate. The default page size is a lie about the size of your problem.
2. Sort by created date, not by priority. Priority is what you meant. Created date is what happened.
3. Read two numbers: median age, and the count over 90 days. Median age is the real latency between having an idea and shipping it. If it is longer than your niche’s shelf life, your agent is answering a question nobody is asking any more.
4. Name what your selector optimises for, then test the old rows against it. Mine effectively picks on volume; the sediment is all low volume. Yours might pick on score or priority. Whatever the axis, your leftovers lose on it permanently, not temporarily.
5. Mark them. Not delete. Mark. Move them to Skipped or Retired so your depth number only counts rows that can actually be chosen.

Three more queues, same container, same morning

Content calendar: 4 pending, oldest 12 days, median 8. Healthy — the drain runs daily, nothing gets a chance to settle.

Backlink outreach queries: 38 pending, median 40 days, oldest 103. Same disease caught three months earlier; two rows have just crossed ninety days. This is what my keyword table looked like in May.

Newsletter queue: 15 rows, 15 sent, zero pending. One in a week, one out a week, no buffer at all. It cannot sediment — and it cannot absorb a single missed Thursday. Balanced is not the same as safe.

And the exception that proves the rule: my social queue has 4 pending rows, three of them anniversary posts welded to dates in early September that have already gone past. Those did not age out of relevance, they expired outright — and they are still sitting there, which tells you what writing a finding down accomplishes on its own.

The takeaway

Depth tells you whether your agent eats tomorrow. Age tells you whether it is eating anything fresh. A queue that has been a hundred rows deep for six months is not stable, it is stagnant, and those two look identical on every dashboard you own.

This is the input-side version of something I wrote ten days ago: content decay is not your post getting old, it is your post getting wrong. Same rot, earlier in the pipeline — an idea can go wrong before it is ever written. Pair it with the ten-minute memory check and you have a Sunday habit: one stops the notes bloating, this one stops the to-do list fossilising.

Ten minutes today: take the queue your agents read most often, sort it by created date, look at the oldest row. If you cannot say out loud why it has not been picked in three months, it has not been picked. Give it a status that says so.

That is most of what running agents unattended actually consists of — not better prompts, but stopping the numbers your agents trust from quietly turning into fiction. Want a second pair of eyes on the queues feeding your stack? Book a strategy session.

— Jon