Twenty-five agent jobs ran. They produced a 1,254-word Medicare guide, five verified deployment receipts, and zero outbound emails.
That last number was intentional. The infrastructure was healthy, but the business data still contained 68 duplicate-email groups and 366 follow-up touches that were due but not safe to release.
What Got Built
- I drafted and validated a new Understand My Medicare guide. The article explains why Medicare enrollment choices become complicated. The content system rejected older candidates that duplicated existing work or conflicted with current CMS and KFF evidence, then selected queue item 179. The finished 1,254-word draft passed the site’s Hugo build, which is the check that confirms the website can turn the file into a valid page.
- I published the daily WIMPER pipeline and revenue controls. The review reconciled 1,516 prospects, 36 content items ready for review, 34 cumulative bounded sends, zero verified replies, and one bounce. Those numbers did not justify reopening broad outreach.
- I rewrote 24 WIMPER social blocks into my voice. The revised bank makes me the first-person speaker and keeps WIMPER in the role of the strategy. No post went public during the rewrite.
- I recorded five verified site deployment receipts. A receipt is evidence that a deployment actually happened, not just a task saying it intended to deploy. That distinction keeps planned work from being counted as published work.
- I kept the revenue portfolio in no-send mode. DIRECT stayed manual-review only. Research, composition, follow-up, paid actions, and uncertain record changes remained behind their gates.
What Broke (And How I Fixed It)
The largest problem was not a crashed server.
The database passed its integrity checks. Reply visibility was working. The content jobs could read evidence, write drafts, and validate pages.
But healthy software does not mean the business state inside the software is trustworthy.
The pipeline still contains 68 duplicate-email groups across 187 rows. It also contains 47 prospects marked contacted whose records are stale, plus 366 sequence touches that are due and held.
Those are customer-facing risks. A duplicate identity can receive the same message twice. A stale stage can make an old conversation look current. A due date can pressure the system to follow up even when the history behind that follow-up has not been reconciled.
I did not “fix” this by letting the queue drain.
I kept research, composition, follow-up, and sending closed. That is the safe response until identity, stage, and sequence history agree. A calendar can tell me that a task is due. It cannot prove that the task is correct.
The content queue exposed a smaller version of the same issue.
Older Medicare ideas were available, but availability was not enough. Some duplicated pages already in the system. Others could not be supported by current CMS and KFF evidence. The job moved through candidates in age order, rejected the weak ones, and drafted only the oldest distinct topic that survived the evidence check.
The WIMPER Institute topic scan used the same rule and produced nothing. Fresh signals repeated subjects already covered, while seven Institute drafts were already waiting for review. Adding another similar article would have increased review debt without adding useful coverage.
One collection tool also failed. GitHub’s commits API returned HTTP 401, which means its remote credential was rejected. I used verified local git history to count four commits instead of estimating the number or reporting the missing source as zero.
The Lesson
Separate infrastructure health from business-state trust.
Here is what I would tell someone building an agent system: create two gates. The first asks whether the software can run. The second asks whether the records are safe enough for the next external action. A green database check should not authorize sending when identities or stages still conflict.
Make zero an acceptable output before you automate a schedule.
A scheduled content job should not owe you an article merely because the clock triggered it. Tell the agent to reject duplicates, unsupported claims, and saturated topics. Zero output is cheaper than another weak draft that consumes review time and weakens the site.
Process candidates in order, but require each one to survive the same gate.
Start with the oldest candidate so useful work does not sit forever. Then run duplicate, source, and contradiction checks before drafting. If it fails, record why and move to the next candidate rather than lowering the standard to satisfy the job.
Use a named fallback, not an invented metric.
When one source fails, the replacement should be explicit and independently verifiable. In this case, the GitHub API failed and local git history supplied the commit receipts. If no trustworthy fallback exists, the number should remain unknown.
The Numbers
- Commits: 4 total (0 agent, 4 Matt)
- Agent jobs run: 25
- Prospects added: 0
- Emails sent: 0
- Social posts: 0
- Content publication and deployment receipts: 5
- Medicare draft: 1,254 words
- Prospects in the reconciled pipeline: 1,516
- Content items ready for review: 36
- Cumulative bounded WIMPER sends: 34
- Verified WIMPER replies: 0
- Bounces: 1
- Duplicate-email groups awaiting repair: 68
- Stale contacted records: 47
- Held sequence touches: 366
The useful comparison is 25 jobs against zero emails.
The system was active. It drafted, checked, reconciled, rewrote, and recorded deployments. It did not confuse activity with permission to contact someone.
The other important pair is 34 sends and zero verified replies. That does not prove the offer can never work, but it is enough evidence to keep broad sending paused while I repair the underlying records and review the referral-first strategy.
What’s Next
Review the 36-item content queue, then repair the 68 duplicate-email groups and reconcile the 47 stale contacted records before deciding whether any of the 366 held touches should be released.