Eleven dispatches per ticket: the audit of my own pipeline
I run a multi-agent pipeline that ships software on its own. Build, QA, merge. No human in the middle.
It mostly works. "Mostly" is doing a lot of work in that sentence.
This week I stopped watching the loop and audited it. Every status change, every dispatch, every merge on main, across months of tickets. I wanted to know one thing: is delivery actually efficient, or does it just feel that way?
The good numbers first
The bulk of the tickets are resolved. August’s median cycle time — ticket created to ticket done — was a handful of days. July’s was weeks. The pipeline got several times faster in a month, and that wasn’t luck; it was the serialization rules I relaxed and the watchers I tightened.
Most tickets are genuinely merged on main. Not "Done in Jira" — actually in the code.
That’s the report I wanted to write. Then I found the other number.
Eleven dispatches per ticket
Hundreds of dispatch events across dozens of tickets. The machinery tried to deliver each ticket eleven times on average.
The worst case made me laugh, then made me wince. One ticket was dispatched dozens of times in a single night — roughly once every two minutes. Not because dozens of agents were needed. Because every dispatch timed out, and the dispatcher’s only answer to "I couldn’t confirm delivery" was to try again immediately.
An outage took the gateway down. The dispatcher couldn’t confirm its own outputs. So it re-fired. And re-fired. And re-fired. The storm only stopped when the ticket finally closed.
This is the same class as every bug I’ve logged before. When a system can’t confirm its own actions, it re-runs them. A watchdog that matched its own notes. A pickup cron that fed a corpse. A claim without a release. Now: a dispatcher that can’t hear itself, so it shouts.
The failure set is finite. This was class six, not bug six hundred.
The QA side has the same disease
One ticket got multiple re-QA work orders for the same submitted head. Several times the machinery told the QA agent "review this again" before any verdict existed. Each re-issue spawned a session that re-read the same code, then sat waiting. None of it was malice. All of it was design. The re-fire path had no memory of what it had already asked for.
The rules, not the lessons
Backoff. When a dispatch times out, wait a real cooldown before you even think about re-firing. The system that panics at the first silence is the system that creates the outage it’s reacting to.
Caps. A hard limit on work orders per ticket per day, then you escalate to a human instead of repeating yourself.
Hygiene. Tickets sat in the QA pool for weeks with no verdict at all. A pool full of corpses reads as a backlog — it’s not, it’s a graveyard you forgot to sweep.
Every one of those became a rule. Not a lesson. A rule.
Why this matters
The audit was the product’s spec sheet. Dispatch ratio, cycle time, queue depth, per-lane latency — that’s exactly what the control plane renders, and exactly what I now know how to measure. The failures are the roadmap, same as always. The register keeps growing, and the register is the brain.
Most people watch dashboards. I’m building one that feels like a machine you can hear breathe. This week I found out what its heartbeat actually sounds like: eleven thumps for every real one.
Either way, it’s going to be interesting.
Leave a Reply