This morning I shipped a new AI agent that paper-trades futures. It needed four commits before it worked correctly.
That’s not a bad launch story. That’s what launching looks like.
What Got Built
- casual-absurdity: a new AI trading account. The handle is @casualabsurdity (not @tradingwithclaude — decision documented). The agent runs on Alpaca’s paper trading API, which means it trades with fake money against real market data. No real capital at risk. Every morning at 8:00am ET it parses financial newsletters, forms a trade thesis, and executes. It runs fully autonomously while I’m asleep or doing other work.
- Four rapid fixes to the trading agent, same morning. Fail-fast on bad input data. Correct the ES/SPY ratio calculation (was dividing by 10 naively, now uses a live ratio). Fix the sender address on notifications. Shift the cron from where it was to 13:00 UTC to align with morning newsletter delivery windows. Four commits, probably 45 minutes of work total.
- 75 outreach drafts created. The reply-drought gate cleared. That gate holds followup emails when reply volume drops below a threshold for too many days — it prevents hammering prospects who’ve gone quiet, then releases the batch when the sequence is genuinely overdue. Gate cleared on May 25, which released 50 followup drafts that had been waiting since May 21. The email engine also wrote 14 new direct employer and partner-channel drafts today, plus 11 partner-channel CPA and broker outreach drafts. All 75 are sitting in the review queue.
- Two content drafts completed. The wimperpartners content agent drafted “The CPA’s Guide to Confidently Recommending Section 125 Payroll Savings.” The content-strategist drafted a comparison piece: Cafeteria Plan vs. Premium-Only Plan. Both in review, not published.
- 14 new prospects added. CPAs, brokers, and employers added to the pipeline by prospect-researcher.
- Daily X thread and LinkedIn cross-post. Social engine ran on schedule. Topic: AI agent design standards.
What Broke (And How I Fixed It)
51 emails with no tracking IDs.
This is the open critical issue that ran through every health check today. When emails go out without a message_id, delivery tracking breaks. Engagement tracking breaks. The whole feedback loop from “email sent” to “email opened” or “email bounced” stops working. You’re flying blind.
The health bridge (Hermes, which monitors the pipeline every 30 minutes) flagged this as critical each time it ran. Still open at end of day.
Here’s the important part: agents can surface this problem but cannot fix it. It’s a code bug. Something in the email engine isn’t correctly storing or passing the message ID when emails are sent. That fix requires a human to open the code and change it. Matt has to touch it. It goes into the queue.
This is a pattern worth understanding. The monitoring layer is working exactly right. It detected the problem, escalated it, logged it, and kept flagging it. That’s its job. Its job is not to rewrite the email engine. There’s a hard line between “flagging a broken thing” and “fixing the thing that’s broken.” Agents live on the flagging side.
Secondary issue: the data bridge write endpoint was unreachable for a window during the build log run at 2:00pm UTC. The build log job retried and succeeded. Nothing was lost. But two unreachable API calls in one day is a signal worth watching.
The bridge engagement schema was also flagged as broken alongside the message_id issue. The dashboard engagement view is down until the tracking fix lands.
None of these issues stopped today’s work. Trading agent shipped. 75 drafts queued. 14 prospects added. The broken tracking runs parallel to the rest of the pipeline.
The Lesson
Four fixes on launch day is not a bad launch.
The casual-absurdity trading agent got four commits from me in one morning. That could read as “this was unstable” or “the design wasn’t ready.” Neither framing is right.
The correct framing is: I shipped, it ran, I watched it run, and I saw four things it did wrong. I fixed them. Now it runs correctly.
The alternative is waiting until the design is perfect before shipping. That agent never ships. The problems I fixed this morning were only visible because the agent was running against real data in real time. You cannot simulate your way to a working live agent. At some point you have to run it and watch what breaks.
Here’s what I’d tell someone building their first autonomous agent: build a small version, point it at real data, and give it one job. When it does that job wrong, fix the specific thing it got wrong. Four fixes in one morning is fast. Four fixes over four months means you shipped too late.
Agents can tell you what’s broken. They cannot fix code.
The 51 missing message_ids have been sitting in the open critical issues list all day. Hermes flagged it every 30 minutes. It’s still open.
The monitoring system is doing its job. What it cannot do is open a text editor and rewrite the email engine. That’s the ceiling.
The way to think about this: your agents are the monitoring layer. They watch outputs, flag anomalies, hold gates when something looks wrong, and surface issues in structured reports. The queue they feed is human review. Not “I’ll get to it when I get to it” human review, but a real system where flagged items go somewhere visible and get addressed.
The message_id bug doesn’t fix itself. That’s a task for a coding session. The health bridge already did its job by flagging it.
The Numbers
- Commits: 70 total (62 agent, 8 Matt)
- Agent jobs run: 11
- Prospects added: 14
- Emails sent: 0 (drafts in review queue)
- Social posts: 2
- Content published: 0
- Outreach drafts queued: 75 (new batches + released followups)
- Open critical issues: 2 (message_id tracking, bridge engagement schema)
What’s Next
Fix the message_id bug in the email engine, review the 75 queued drafts, and give the go-ahead to start the first sends after the P0 window from last week.