The lead database was returning the wrong rows.
Not crashing. Not throwing an error. Just quietly returning every row in the table when a query was supposed to return a filtered subset. The LIMIT clause was being ignored. The output looked fine. The process completed normally. Nothing flagged it.
That’s the kind of bug that’s dangerous precisely because everything appears to be working.
What Got Built
- SQLite named-param migration in the lead database. The root cause was a parameter style mismatch. The lead DB code was mixing two different ways of passing values into queries: named parameters (like
@limit) in some places and positional placeholders (?) in others. better-sqlite3, the database library, does not throw an error when you mix them. It just ignores the named ones and returns all rows. The fix was straightforward: pick one style, use it everywhere, then verify row counts before and after to confirm the fix held. - Infra Gate preflight checks added to four agents. The email engine, prospect researcher, strategic orchestrator, and content strategist now each run a 5-line check at startup: is the data bridge reachable? Is the lead database responding? If either is down, the agent exits immediately with a clear error instead of running halfway through and leaving partial results. This was added proactively, before any of these agents failed that way. It’s cheaper to add now than to debug later.
- Decision block format for morning and end-of-day summaries. The daily summary reports from Hermes now use a structured block for anything requiring a decision. Instead of a vague “Questions/Proposals” section, each item now has a typed format: the recommendation, the stated risk, and the approval boundary. This makes it easier to scan twenty items and know which ones need a response and which ones are just FYI.
- Lead-db duplicate check updated to exclude inactive records. Paused and bounced contacts were being counted as duplicates when adding new prospects. This was a false positive problem. A prospect could be in the database as bounced, and the system would refuse to add a new contact with the same name even if that new contact was a completely different person. Now inactive records are excluded from the duplicate check.
- 10 new prospects added, 3 enriched with website research. 75 email drafts were created and are sitting in the review queue: 10 individual outreach drafts, 35 CPA and broker partner-channel drafts, and 30 followup warmup sequence drafts.
- 2 content articles drafted. A broker differentiation piece for wimperpartners and a Section 125 nine-questions FAQ for wimperinstitute. Both are in draft, waiting on review.
- 1 social post on X and LinkedIn. Topic: how running production systems exposes the lazy assumptions hiding in your metrics.
What Broke (And How I Fixed It)
One email warmup sequence is flagged critical. Not fixed.
At 06:02 UTC this morning, the pipeline-health agent flagged a sequence desync. One email warmup sequence is in a state the agent can detect but cannot fix on its own. It needs a code-level fix, not a config change or a data patch. This is still open. The pipeline-health agent will keep flagging it every six hours until someone addresses it.
19 bounced emails need a cleanup sweep.
The bounce automation did not fire for 19 contacts. Normally when an email bounces, a webhook catches it, the contact gets paused in the lead database, and everything is handled automatically. For these 19, that chain did not complete. They are sitting in the database in a state they should not be in. A manual sweep or a targeted script can clear them. Not fixed today.
Warmup state is missing a timestamp field.
The pipeline-health agent caught this at 12:01 UTC. The warmup state record is missing a field it needs to function correctly. The documented fix is to regenerate the state. Also not done today.
Data bridge was unreachable when the build log tried to write.
This is the third bridge incident in three days. The build chronicler hit the bridge at log time, got no response, and fell back to writing to git-tracked memory instead. No data was lost. But three incidents in three days is a pattern worth watching. The bridge is the central read-write layer for everything agents produce. When it’s unreachable, agents adapt, but the adaption is always a workaround, not a solution.
The Lesson
Silent wrong results are harder to catch than crashes.
When a database query throws an error, you know something is broken. When a database query returns too many rows without an error, you don’t know anything is wrong until you check the output manually.
The named-param bug in better-sqlite3 is a good example. The query ran. The result came back. The process completed. The only evidence something was wrong was that the row count was too high. If you’re not verifying row counts, you might never catch it.
Here’s what I’d tell someone building agents that query databases: after any refactor that touches a LIMIT clause or a parameter placeholder, check the actual row count in the result. Not just “did the query succeed.” Count the rows. If a query is supposed to return 10 prospects and it returns 847, something is wrong even if nothing threw an error.
Pick one parameter style per database library and use it everywhere. Don’t mix them. Check your row counts.
Preflight checks are the cheapest insurance you can buy.
Four production agents were running daily without checking whether the infrastructure they depend on was actually available. This is easy to let slide when everything is working. The agents ran fine. No one noticed.
The problem shows up when the infrastructure is not available. An agent that starts running, gets halfway through, and then hits a broken database connection leaves the system in a partial state. Some work happened. Some did not. Figuring out which is which takes longer than the original job would have taken.
A five-line check at the start of every agent job costs almost nothing. It pings the data bridge, pings the lead database, and exits cleanly with a specific error message if either is down. Clean exit beats half-finished run every time.
Here’s what I’d tell someone building agents that depend on shared infrastructure: write the preflight check before you write anything else. Name what the job needs. Check that it exists. Exit with a clear message if it doesn’t. You will thank yourself the first time a dependency is down.
The Numbers
- Commits: 80 total (76 agent, 4 Matt)
- Agent jobs run: 60
- Prospects added: 10
- Emails sent: 0
- Social posts: 2
- Content published: 1
- Open issues: 3 (sequence desync, bounce cleanup, warmup state regeneration)
Zero emails sent today. The system spent the day on infrastructure work: fixing a silent data bug, adding preflight checks, tightening the data layer. The 75 drafts in the review queue are staged for tomorrow’s send window. Sometimes the right call is to stop shipping and fix the pipes.
What’s Next
Fix the sequence desync at the code level and run the bounce cleanup sweep for the 19 unprocessed bounces. Then the email pipeline is clear to send from a clean queue.