System overview
The current HermesAI application architecture and how the major domains connect.
Current architecture shape
HermesAI is a hybrid Next.js application with a curated source catalog, a runtime synthesis pipeline, durable relational state, and Redis-backed runtime state.
Curated source datasets + catalog
↓
Runtime fetch + synthesis pipeline
↓
Durable Postgres state + mutable runtime state
↓
Tenant newsroom app + platform admin appMajor layers
Curated source datasets
Canonical source data lives under news-sources/ and is normalized into a versioned dataset that can be synced into Postgres through the explicit admin sync route.
Runtime fetch and synthesis
Runtime code fetches ingest_enabled feeds, enriches thin articles, groups overlapping reporting, and produces localized newsroom artifacts.
Durable product state
Postgres + Drizzle store subscriptions, memberships, source catalog entries, editorial drafts, newsroom profile data, and chat-session persistence.
Mutable runtime state
Redis-backed runtime state is used for monitoring rules, alert history, webhook state, notifications, delivery state, and related operational flows.
Architectural reality
The current implementation is not the older BullMQ-style durable worker pipeline sometimes implied by outdated notes.
Today the shipped architecture is:
- Next.js App Router handlers
- Runtime synthesis logic
- Supabase-ready Postgres via Drizzle
- Upstash Redis with in-memory fallback
- Vercel AI SDK and provider registry controls
Product surfaces on top of that architecture
/app/*
Tenant newsroom workflow — feed, story workspace, compose, refinement, editorial review, monitoring, settings, notifications.
/admin/*
Platform operations — provider governance, queues, costs, deliveries, source catalog health, tenant oversight.
Public marketing
Landing, pricing, partners, security, contact, careers, and the legal/policy surfaces.
Integration endpoints
WordPress connector, webhook delivery, API keys — the outbound integration layer.