The Congressional Mirror trading experiment has been running against the wrong field names since I built it.
Not kind of wrong. Wrong in a way that would have silently produced bad data for 30 days and then delivered a false verdict on whether the experiment worked.
One test call to the live API caught it this morning. That’s the win.
The loss: the content_queue database table disappeared, and two agents have been down since morning with no self-recovery path. Still open at end of day.
What Got Built
- Congressional Mirror API schema corrected. The original build used field names from the QuiverQuant documentation:
Filedfor the date, an exact string match forTransaction. The live API returnsReportDate. TheTransactionfield requires a substring match. ETF filtering also needed correction. Three silent field mismatches, all caught by making one actual API call and comparing it to what the code expected. - Experiment-003 enriched with signal tracking. Added lag analysis (how long after a congressional trade report do we act), chamber breakdown (House vs Senate trading patterns), conviction scoring, and sector relevance. The experiment now tracks the dimensions that actually matter for the 30-day verdict.
- 30-day experiment diagnosis job scheduled for June 27. On that morning, an agent will run a scientific evaluation of all three @casualabsurdity trading experiments: Mancini Protocol (overnight futures), Overnight Drift, and Congressional Mirror. It will report on what the data shows, not what the design intended.
- Weekly article cron added for @casualabsurdity. Every Sunday at 2pm CT, the system pulls experiment performance data, drafts a mattragudo.com post, and sends the link to X. The trading account now generates its own documentation loop without me touching it.
- 50 outreach emails sent, 18 new prospects added. The daily cap hit at 00:41 UTC. The email pipeline is running normally after last week’s fixes.
- 4 blog posts auto-published by pipeline-health. Two mattragudo build logs, one wimperinstitute article, one wimperpartners article. All flipped from draft to live without human input.
What Broke (And How I Fixed It)
The content_queue table is gone. Two agents are down. Not fixed.
At some point between yesterday and this morning, the content_queue database table disappeared. This is the table that both the strategic-orchestrator and the understandmymedicare-content agent use as a work queue. Think of it like a shared whiteboard where agents write down what to work on next. The whiteboard got erased.
Both agents failed on the same error. Normally a missing table triggers an initialization script that recreates it. In bridge mode (the way agent containers connect to the production database on the VPS), that auto-init path doesn’t exist. The agents failed, escalated, and stopped. Hermes flagged it every 30 minutes throughout the day. The actual fix requires someone to manually run a DB init on the host machine.
That’s five-plus hours of two agents effectively paused. The understandmymedicare content pipeline and the strategic orchestrator both just stopped generating. This is a preventable failure mode. It happened once. It goes on the list.
Data bridge transiently unreachable at 09:00 UTC.
The build-chronicler hit the bridge at 9am and got no response. It retried and succeeded. No data loss. But three bridge incidents in three days is a pattern, not noise. The bridge is the central read/write layer for agent-generated data. When it’s unreachable, agents either skip writes or retry with delays. The data usually makes it through. The question is whether this is a load issue, a resource issue, or just random.
The Lesson
Documentation and live behavior are not the same thing. Test against real responses.
The Congressional Mirror was built against API documentation that described one set of field names. The live API returns different ones. Filed vs ReportDate. Exact string match vs substring. Three fields, three discrepancies, all invisible until I made a real call.
Here’s what I’d tell someone building agents that call external APIs: documentation is a starting hypothesis, not a contract. Read the docs to understand the shape of the data. Then make one real call and compare. Check every field name. Check every data type. Check every filter behavior against an actual response.
One test call before the 30-day experiment would have caught all three mismatches in thirty seconds. Instead, it almost ran for a month on subtly wrong data, in a way that would have been invisible until the final verdict came out wrong.
The documentation said one thing. The live data said another. Always test against the live data.
A missing infrastructure dependency can silently block multiple systems for hours. Pre-flight checks are cheap insurance.
One missing database table took out two independent agents for five-plus hours. Neither agent could fix it. Neither could work around it. They failed midway through initialization and escalated.
The frustrating part: a two-line check at job startup would have surfaced this in seconds. Does this table exist? If not, log the specific error and stop immediately with a clear message. Instead, both agents failed with a generic database error, and diagnosing what happened required piecing together logs across multiple jobs.
Here’s what I’d tell someone building multi-agent systems: your agents should be able to answer “what does this job need to run correctly?” before they start running. Connection checks, table existence, config file presence. Ten seconds of pre-flight saves five hours of silent failure downstream.
The Numbers
- Commits: 84 total (78 agent, 6 Matt)
- Agent jobs run: 75
- Prospects added: 18
- Emails sent: 50
- Social posts: 2
- Content published: 4
- Open issues: 1 (content_queue table missing, blocks 2 agents)
What’s Next
Run the DB init on the host to restore the content_queue table, then add pre-flight table existence checks to the affected agents so this failure mode doesn’t repeat silently.