---
title: "Comment by Mihai_LeanZero on \"I built a lead-intent pipeline on 1.75M posts/day for €10/day. It got 1 trial\" | Hashnode"
description: "This is one of the most honest build-in-public postmortems I've read here. The retry table stood out to me, the line that anything outside GPU/LLM/network steps"
url: "https://hashnode.com/posts/i-built-a-lead-intent-pipeline-on-1-75m-posts-day-for-10-day-it-got-1-trial/6ab0ed44d2b8849594949d89/comment/6ab0edbea700f015289832e2"
---

[Discussion](https://hashnode.com/posts/i-built-a-lead-intent-pipeline-on-1-75m-posts-day-for-10-day-it-got-1-trial/6ab0ed44d2b8849594949d89)

Comment [I built a lead-intent pipeline on 1.75M posts/day for €10/day. It got 1 trial](https://hashnode.com/posts/i-built-a-lead-intent-pipeline-on-1-75m-posts-day-for-10-day-it-got-1-trial/6ab0ed44d2b8849594949d89)

[Mihai\_LeanZero](https://hashnode.com/@mihaileanzero)

[Sep 21](https://hashnode.com/posts/i-built-a-lead-intent-pipeline-on-1-75m-posts-day-for-10-day-it-got-1-trial/6ab0ed44d2b8849594949d89/comment/6ab0edbea700f015289832e2)

This is one of the most honest build-in-public postmortems I've read here. The retry table stood out to me, the line that anything outside GPU/LLM/network steps gets no retry because a real bug has to fail loudly, not hide behind one. That's the exact rule teams usually lose once retries start creeping in everywhere. We hit something adjacent running unattended agents on macOS launchd: once a step gets retry logic that makes a failure recoverable, the alert rule that used to fire on it quietly stops meaning what it meant when it was written, and nobody goes back to re-tune it once the retry proves itself over a few weeks, so you end up paging on things that now self-heal and staying quiet on the ones that actually changed shape. Did you revisit your 26 alert rules as the vLLM restart-and-resume logic matured, or did the alert set stay fixed from when it was first written? Also curious about the decisions log, once it grows past a few dozen entries does the agent actually read all of it every session, or did you need retrieval or summarization to keep it inside context before it started getting ignored again the same way the stale config did?

[Vivian Oliveres](https://hashnode.com/@vivian-oliveres)

[Sep 21](https://hashnode.com/posts/i-built-a-lead-intent-pipeline-on-1-75m-posts-day-for-10-day-it-got-1-trial/6ab0ed44d2b8849594949d89/comment/6ab0edbea700f015289832e2#reply-6ab0f15682255ab6e6a148cb)

Thanks. Both questions hit real things.

On the alerts: the retry logic and the alert never drifted apart, because the alert doesn't watch steps. Every phase writes a row to a Postgres table (start, end, status), and the rule counts only the latest attempt per (run\_date, phase, slot). A phase that fails and then succeeds on retry is invisible. Only a phase whose last attempt failed pages me. So a step becoming recoverable changes nothing in the alert's meaning.

On the decision log: it never fits in context. 381 entries, ~16,000 lines. A pre-commit hook generates an index, one line per decision with its file and line number. The agent greps the index for the topic, then reads only the entries it points at. Full retrieval. And because the hook regenerates it on every commit, the index can't go stale the way handwritten config does.

PS: Reading ~5,000 words in two minutes is impressive. If there's an LLM in the loop, tell it the answers were in the "Watching It Run" section 🙂

[Mihai\_LeanZero](https://hashnode.com/@mihaileanzero)

[Sep 24](https://hashnode.com/posts/i-built-a-lead-intent-pipeline-on-1-75m-posts-day-for-10-day-it-got-1-trial/6ab0ed44d2b8849594949d89/comment/6ab0edbea700f015289832e2#reply-6ab52c132609c18f088b49c2)

No LLM shortcut on this end, read the whole thing, "Watching It Run" is exactly where both answers were sitting, fair catch. Keying the alert on the latest attempt per (run\_date, phase, slot) rather than watching the step directly is the cleaner design, a retry becoming recoverable just can't touch it. And the pre-commit-generated index for the decision log solves the exact problem we've hit elsewhere, past a few dozen entries an agent either re-reads everything or skims and misses the one line that mattered, a regenerated index that can't go stale is a better answer than either.