Under the hood
How one operator runs an entire fleet.
The whole system rests on four deliberately simple ideas. No exotic infrastructure, no Kubernetes, no microservice sprawl — a Postgres database, a scheduler, a watchdog, and a dashboard. The cleverness lives at the edges, in the agents. The center stays boring on purpose.
One event log, everywhere
Every agent — Python script, Node worker, or LLM-driven — writes to the same event_log table in Supabase. Every decision is replayable. When something breaks at 2am, the audit trail already exists.
INSERT INTO event_log (event_type, source_agent, payload)A deliberately boring orchestrator
The orchestrator schedules jobs, fans out work, and respects per-channel rate limits (eBay's API budget is the tightest constraint in the system). It doesn't try to be clever — clever schedulers are undebuggable at 2am.
SELECT * FROM batch_jobs WHERE status = 'queued' ORDER BY priorityA self-healer on a timer
Every few minutes it scans health_checks for agents that went quiet and batch_jobs for stuck work. Silent agents get restarted; stalled jobs get retried on a clean worker. It's the most valuable code in the stack.
WHERE last_seen < NOW() - INTERVAL '15 minutes' → restartOne dashboard, full control
A Next.js + Supabase dashboard shows every agent, every status, every event — with one-click pause, restart, and reprioritize. No SSH sessions, no production database surgery. The same data feeds the live numbers on this site.
supabase.channel('fleet').on('postgres_changes', ...)Go deeper
The build log has the war stories.
Architecture diagrams are the clean version. The build log covers what actually happened — what broke, what got rebuilt, and the numbers before and after.