How The Tomorrow Times Agents Work

A few folks asked me how Tomorrow Times agents work, so here’s a look under the hood.

Tomorrow Times runs on serverless edge functions: small TypeScript programs that wake up, do one job, and disappear again.

There is no server running 24/7. Instead, five agents take turns on a schedule, all connected through a shared database.

Think of them as cron jobs with backend superpowers.

The Architecture

Each agent lives as a Supabase Edge Function (Deno runtime, deployed at the edge). They’re triggered by cron jobs (a clock that fires every 15 minutes, every hour, or every morning) or by database events (when something gets inserted or updated). When an agent runs, it reads from its assigned database table, does its work, writes results back, and exits.

The agents never call each other directly. They don’t know the others exist. The database is the switchboard. Agent A writes to a table; Agent B reads from that same table later. This is called a message-passing architecture, and it means if one agent breaks, the rest keep running. You can also manually re-trigger any agent without breaking state.

The Five Agents

Agent	Schedule	What It Does
Story Scout	Every 15 min	Polls RSS feeds from news sources, strips HTML, deduplicates, and runs an AI summarizer to write clean story records into the stories table.
Morning Editor	7 AM daily	Pulls ~40 fresh stories and live prediction markets, sends them to an LLM with a prompt, and gets back 5 prediction cards (title, question, yes/no options, TL;DR, category). Generates a satirical illustration for each, uploads it, and saves everything as “draft” in prediction_cards. Then sends you a Telegram message with Publish/Delete buttons.
Breaking News Watchdog	Every hour	Scans stories from the last 90 minutes. Deliberately silent 95% of the time. Only drafts a card when something truly massive happens, then sends a Telegram with a red “BREAKING” header.
Resolution Detective	Every hour	Scans prediction_cards that are past their close date. Uses web search (Firecrawl) to research the actual outcome, feeds the evidence to an LLM, and sends you a Telegram with a proposed answer, confidence score, and one-tap buttons: Confirm, Override, Extend, or Close.
Social Media Poster	On demand	When you approve a card for social, it writes a Dave Barry-style hook, posts to X and Bluesky via OAuth, records the post in social_posts, and DMs you the result.

The Stack

• Runtime: Deno (TypeScript) on Supabase Edge Functions
• Backend: Managed Supabase — Postgres database, cron scheduler, real-time subscriptions
• AI: AI Gateway (Gemini 2.5 Flash / GPT-5) for summaries, card generation, and resolution research
• Storage: Database tables (stories, prediction_cards, votes, social_posts, etc.)
• Notifications: Telegram Bot API for admin prompts
• Scheduling: pg_cron extension calling each function on its interval
• Web Search: Firecrawl API for live resolution research

Why This Design Works

Because each agent owns one table and one job, the system is resilient and debuggable.

If Story Scout fails, Morning Editor still has yesterday’s stories to work with. If the LLM API is slow, the cron just retries next cycle. Nothing is lost because everything lives in Postgres.

You are the human layer — the agents do the legwork of fetching, drafting, researching, and posting, while you spend your time on judgment: Is this card worth publishing? Is this resolution correct?