AI agent queue marked 175 items done while delivering nothing downstream

A postmortem published on dev.to by Elena Revicheva details an AI agent queue failure in which 175 items were marked as completed without a single one being processed. A newly connected data source ran on schedule for an entire day, logged healthy counts every hour, and passed nothing downstream. The pipeline never raised an error; from the outside it looked like a productive day.

An empty queue behind a healthy report

The consumer responsible for working through those items, an agent the author calls VibeJobHunterAIPA_AIMCF, went hungry because its input never arrived. The problem was not missing data — items were ingested fine — but a mislabelled status: entries were recorded as "done" before any work touched them. Revicheva notes the discrepancy surfaced by comparing the source's internal logs, which showed 175 items handed to the next stage, against the downstream system's intake logs, which showed zero.

How the ordering bug burned jobs

New arrivals first passed through a deduplication ledger whose job is to stop the same item being processed twice. Anything the ledger had seen before was stamped as done and skipped. The defect was where this step sat relative to the pipeline's processing cap, a limit intended to keep resource use in check by holding surplus items for the next cycle.

Because the ledger ran first, items that exceeded the cap had already been marked done by the time the cap rejected them. Instead of being deferred, they were thrown away. The ledger kept reporting progress, the queue kept reporting success, and the majority of the day's items simply evaporated.

The fix: apply the cap first

Reordering the two operations resolved it. The processing cap now runs before the dedup ledger marks anything complete, so only items that have genuinely passed through a cycle — in progress or finished — carry the done status, and overflow survives for the next run. The author recorded the correction in two commits on 2026-08-30: one titled "wellfound: stop reporting success while returning nothing", and a follow-up, "pipeline: stop burning jobs at the cap, and stop starving the best source".

Why monitoring missed it

The existing checks stayed green while the pipeline delivered nothing. A PM2 process list showed eight processes online, though with striking restart counts — 99 restarts in two days for cto-aipa, and 55,193 in fourteen days for algom-stream. Revicheva points out those numbers signal stability problems of a different class, unrelated to this logical error. Log files showed passing self-tests and "ok": true responses. Business metrics in HubSpot tracked deal stages rather than agent health.

None of these could catch the mismatch, because none of them compared what went in against what came out. What was missing, the author writes, is a direct reconciliation of items ingested versus items delivered downstream, with an expected delta. A dedicated metric contrasting items entering the processing queue with items marked as deduplicated before processing would have flagged the gap immediately, and building it is now a stated priority.

A shared-memory workaround

The post also describes an adjacent problem: several AI coding tools work on the same repository but cannot see each other's conversations. The workaround is a hand-maintained file, NOW.md, that acts as the working memory for whichever agent is not currently running. Debugging logical failures across that fragmented context remains manual, and automating detection of inconsistencies — many items ingested while almost none are delivered — is listed as a next step.

Why it matters

This incident is a clean example of the failure mode agentic pipelines are most vulnerable to: not crashing, but confidently reporting progress while discarding work. Each component behaved reasonably in isolation — deduplication prevents waste, caps protect downstream services — yet their interaction silently destroyed data. The lesson generalises beyond this system: a status flag written at the wrong point in a sequence can turn a defer mechanism into a delete mechanism, and no amount of process-level monitoring will notice. End-to-end reconciliation between what enters a pipeline and what leaves it is the only check that catches this class of bug, and it needs to exist before a new data source is trusted.