Project 4 of 5
TicketScan
A fleet of AI agents that runs unattended, watches itself for failure, and recovers from a specific credential-failure mode.
Why this matters to a client
Why this matters to a client
"Set up an AI agent to do X" is easy to demo and hard to trust with real, unattended operation. The gap is what happens at 2am when the tool it depends on silently changes behavior, or a credential expires, or one step in the chain fails quietly while everything downstream reports success anyway. I run eight distinct agents on a real schedule for one of my own products, specifically so I know what that failure mode looks like and how to build against it before I tell a client to hand a process to an unattended agent.
What it does
What it does
Eight agents, each with a distinct job (content strategy, SEO, social, paid ads, email, conversion, analytics, growth), run on a daily and weekly schedule against a real production site with no human triggering them. Each run produces real committed output — copy, calendar entries, reports.
Product screenshots
Placeholder — not a real screenshot. TicketScan product imagery to be added before launch.
How it's built
How it's built
Technical detailFor readers who want the engineering — skip ahead if you just want the outcome.
Scheduled via OS-level jobs (daily, and two weekly variants) that shell out to a CLI-driven agent runner. Every run tracks a failure counter per agent and writes a single greppable line to its log — "AGENT FAILURES: N" — so a monitoring check doesn't have to parse agent output to know if something broke. A prior real incident is documented directly in the script: a piped command was silently swallowing the agent CLI's exit code, so around thirty failed runs had been logging themselves as successful. The fix, and a comment explaining why, are in the code, not just in a postmortem.
The interesting decision
The interesting decision
The agents authenticate to their CLI provider through a local credential file, and that authentication silently degrades under certain conditions — the CLI falls back to a different billing mode without erroring. Rather than let a run continue on the wrong credential path, the runner checks the login mode explicitly before every run, and if it's wrong, re-provisions the correct credential from a secrets file and checks again before proceeding — hard-failing the run rather than continuing on an assumption. It's a few extra lines that exist for exactly one reason: so a silent auth problem shows up as a stopped job instead of an invisible one.
The same fleet, on its own, has written content acknowledging its own data limitations rather than papering over them — a scheduled post noting that a price-history feed was stale and declining to state a number as fact because of it. That wasn't hand-checked by me; it's the kind of behavior you want from something running unattended.
Status
Status
Running in production, unattended, on daily and twice-weekly schedules. This is infrastructure I own and operate for my own site — not a claim about the underlying product's user base or results, which this page makes no claim about either way.