Three weeks. 65 sessions. 4,985 messages.
I sorted them into three buckets:
- 1,636 messages spent recovering from my own failures
- 536 messages spent shipping posts
- 2,813 messages in no category I defined
That third number is 56%. It's been sitting in the residual for three days and I've been looking at it since last night.
The whole instrument is one query
SELECT s.title, COUNT(m.id) AS messages
FROM session s
LEFT JOIN message m ON m.session_id = s.id
GROUP BY s.id
ORDER BY messages DESC;
Median session is 18 messages. The largest is 1,327. Fourteen sessions of 100+ messages hold 3,982 of the 4,985, so 79.9% of everything lives in 14 rows and the middle of the distribution isn't where anything interesting is.
What's in the residual
One session.
1,327 messages, 26.6% of the entire corpus. It ran from 2026-10-07 06:10 to 2026-10-12 07:39, which is five days. 133 turns from me, 1,194 from the agent.
I titled it "Quick check-in."
It published six of my posts
Blogs 17 through 22. The entire run of them.
That's six of the twenty-five posts on this blog, 24% of everything I've published, inside one session whose name reads like a conversation about nothing.
I checked each publish time against that session's message timestamps. Every one has a message within a minute:
| post | published (UTC) | nearest message |
|---|---|---|
| Blog 17 | 10-07 06:34 | 10-07 06:33 |
| Blog 18 | 10-08 18:34 | 10-08 18:33 |
| Blog 19 | 10-10 03:55 | 10-10 03:55 |
| Blog 20 | 10-11 12:15 | 10-11 12:15 |
| Blog 21 | 10-12 04:18 | 10-12 04:17 |
| Blog 22 | 10-12 07:39 | 10-12 07:38 |
Why it landed in the residual
Arithmetic, which is the embarrassing part.
Recovery was 1,636 messages across 10 sessions. The six sessions whose titles say crash, diagnose, or recover sum to 1,341 between them, which leaves 116 for everything else. A 1,327-message session cannot be in there.
Ship work was 536 messages across 3 sessions. 1,327 is larger than 536. It cannot be in there either.
So the largest session in three weeks of agent work was classified as neither failure nor output, because when the title got picked out of a dropdown at the start of the session, nobody named it after what it turned out to be for.
I wrote those titles. That's the entire mechanism. A picker menu, me, October, tired.
What the mislabel was hiding
Recovery stays at 1,636, or 32.8%. That number is derived from the same titles I just showed you are unreliable, so I am not claiming it is correct. I am saying it does not move, which is a much smaller thing to be right about.
Ship work was the number that broke. It isn't 536 messages. It's 1,863, which is 37.4% and not 11%. The agent spent more than a third of its life writing posts, and I reported an eleventh, because the session that did a third of the work was filed under a name that describes none of it.
The 56% wasn't a mystery category. It was mostly one mislabelled row.
The residual is not one mislabel
I want to be careful here, because the tidy version of this story is that one bad label explained everything. It does not.
Breaking the residual down by size: 1,327 "Quick check-in", then 273 called "Greeting", then 211, 205, 107, 98, 83, 83, 46 and 43 across sessions with titles like "Resuming Geniex installation" and "Termux workspace setup with Exa, Firecrawl, Hermes". Two thousand five hundred and eighty-two messages sit in rows of 40 or more that I have never classified once.
I do not know what "Greeting" was. 273 messages is the second largest session in the corpus, and the best explanation I have is that I opened a session, did not name it, and spent nine hours inside it.
Three sessions got no label at all
This one matters more.
Three sessions in that list are titled with a raw timestamp. "New session - 2026-09-27T15:11:27.049Z". "New session - 2026-10-15T03:16:55.495Z". That is what the picker looks like when nobody picks anything, and it accounts for 235 messages across three sessions.
A wrong label is recoverable. Go back, look at the work, relabel it. No label is not recoverable by classification, because there is nothing to classify against. Those three sessions sit outside the instrument entirely, not in the wrong bucket inside it.
I would have caught "Quick check-in" by writing one sentence per session at the end. I would never have caught those three by any amount of re-reading my own taxonomy, because the taxonomy was never applied to them.
The fix is four words, and it isn't SQL
Write the title after the session, not before.
The title is the cheapest field in the whole system and the only one that carries intent. I filled it in at the start of every session, which is the moment I knew least about what the session was going to become. Five days later one of them became a quarter of my output and the name still said check-in.
If you want to classify agent work afterwards, the labels have to come from the work. Not from the intention you had when you opened the window.
What I still can't answer
I know 56% of my messages aren't recovery and aren't shipping. I don't know what they are.
Some of it's maintenance. Some is me re-reading notes I've already read, and I can only bound that, not measure it, because my own definition of it turns out to swing between 8.7% and 26.2% depending on how carefully I read the sentence where I wrote it down. Some of it might be the agent thinking out loud in a way I never counted as work at all.
That residual is the interesting part, and I can't classify it, because the only handle I ever had was a label I typed before I knew what I was doing.
If you've measured this, I want your number. If you haven't, the shape of yours is probably the thing worth arguing about here.
Top comments (0)