Architecture
MirQuadri.com is a personal-brand platform where AI agents draft essays, evaluate them against a rubric, create social media companions, and publish them—but only after I approve. The site is built on Next.js and Supabase, orchestrated by seven specialized AI agents powered by Claude. Every agent run and its cost is visible in the studio; token counts are tracked internally and recorded in the database for audit trails. Nothing ships without human judgment.
Last reviewed: September 20, 2026
Stack & Rationale
| Layer | Technology | Version | Why |
|---|---|---|---|
| Framework | Next.js | 16.2.6 | Full-stack SSR + API routes + server components. |
| UI Library | React | 19.2.8 | Interactive pages and components. |
| Language | TypeScript | ^5.6.3 | Type safety; strict mode enabled. |
| Database | Supabase (PostgreSQL) | Latest | Managed Postgres, auth, RLS, and migrations. |
| Auth | Supabase Auth | Built-in | Passwordless magic-link, single-owner gate. |
| AI Brain | Anthropic Claude | Sonnet 4.5 | Best reasoning; used by all agents. |
| Styling | Tailwind CSS | ^3.4.15 | Utility-first; design tokens as theme. |
| Resend | Latest | Transactional email (welcome, digests). | |
| Hosting | Vercel | Latest | Auto-deploy, serverless edge functions, scheduled jobs. |
| Observability | Datadog | Latest | LLM observability; traces every agent run. |
System Flows
Request Flow: Visitor to Page Render (Data-Backed Routes)
This flow applies to dynamic routes that fetch data from Supabase (e.g., /essays, /studio). Static routes like /architecture and /about skip the database query and render cached HTML directly.
Agent Run Flow: Trigger to Published Essay
How the Agent System Works
The Base Class
All agents inherit from an abstract base class that enforces a lifecycle: queued → running → success/failure/skipped. Every agent registers in a central Map (not an object, for security), making them discoverable by ID. When triggered, an agent is instantiated and its execute() method is called inside a Datadog trace span.
Token Counting & Cost
Every Claude call is tracked: input tokens, output tokens, model used. Costs are calculated at runtime using a pricing table (Sonnet, Opus, Haiku variants each have different rates). The final cost is written to the run record, making it auditable.
Fire-and-Forget Execution
When a user triggers an agent (or cron triggers it), the API responds in ~100ms with the run ID, even though the agent hasn't executed yet. The actual work happens in the background via Next.js after() callback, keeping the response time fast and predictable. The studio dashboard polls for live status every ~3 seconds.
The Seven Agents
- WRITER-02: Drafts essays given a topic. Stores draft to database with status='draft'.
- CRITIC-04: Scores drafts against a 7-axis rubric (clarity, originality, audience fit, etc.). Chained after WRITER automatically.
- SCOUT-01: Generates topic candidates for future essays. Fills a topic pool that WRITER draws from.
- PUBLISHER-05: Creates LinkedIn companions for published essays (in-progress, not yet verified in production).
- ANALYTICS-07: Writes weekly digests of internal pipeline activity (essays published, run costs, tokens used, etc.).
- MATCH-06: Scores sponsor/partner inquiries for fit (in-progress, unverified).
- PRODUCER-03: Drafts a video script for a published essay (in-progress, not yet verified in production). No voice synthesis or rendering — script only.
Triggers: Manual & Scheduled
Agents are triggered manually from the studio (e.g., "Run WRITER-02") or automatically on a schedule. A daily orchestrator runs at a fixed time (UTC), checking if the draft queue is below target (default: 3 pending drafts). If so, it triggers WRITER-02 with the next topic. It also runs SCOUT-01 to top up the topic pool, PUBLISHER-05 to draft LinkedIn companions, PRODUCER-03 to draft video scripts, ANALYTICS-07 to write weekly digests, and MATCH-06 to triage sponsor inquiries.
Agent Chaining
After WRITER-02 completes successfully, it automatically triggers CRITIC-04 with the draft ID. This fire-and-forget chain means essays are scored immediately, without manual intervention. Other agents are not chained; they run independently on manual or scheduled triggers.
Concurrency & Schema Drift
When database migrations are deployed, there's a window where code has been updated but the schema hasn't. We handle this with fallback logic: WRITER catches "column does not exist" errors and retries without the new column. Other agents use optimistic concurrency guards (unique partial indexes, edit-version incrementing triggers) to prevent race conditions where two agents try to create the same record simultaneously.
Key Decisions & Tradeoffs
Single Owner, Manual Approval
No agent can publish automatically. Every essay must be reviewed and approved by Mir before going live. This is a deliberate constraint: the site demonstrates that AI can assist (conceptualization, drafting, editing, scoring) while humans remain the decision-maker. Tradeoff: slower throughput, but higher editorial integrity.
Passwordless Magic-Link Auth
No passwords, no social login, no multi-factor auth flows. Just an email link. Tradeoff: simpler UX and recovery (you can't "forget" a magic link), but requires a working email address and depends on email delivery. Supabase Auth handles the security details (time-limited links, HTTPS-only).
Vercel Cron (Node.js Serverless) Over Polling
Scheduled jobs run via Vercel Cron on Node.js serverless runtime, not a self-hosted cron daemon or polling service. Tradeoff: cheaper and simpler (no new infrastructure), but tied to Vercel's availability and schedule precision (~1 minute window). No retries on failure.
Manual Database Migrations
Migrations are not auto-applied on deploy. After code ships, migrations are applied manually via Supabase SQL editor. Tradeoff: explicit control and visibility (no surprise schema changes), plus time for code to add fallback logic. Risk: deployment window where code expects a column that doesn't exist yet (mitigated by fallback error handling).
Datadog Observability (Not Essential)
Traces are logged to Datadog for visibility, but the system works without it (traces are lost, but agents still run). Tradeoff: great observability for debugging and cost tracking when Datadog is up, but no alerting on agent failures or cost anomalies. More operational awareness than critical infrastructure.
Supabase for Everything
Database, auth, and RLS (row-level security) are all Supabase. Tradeoff: simplicity and tight integration, but vendor lock-in. If Supabase is down, we can't read or write anything. Single points of failure matter here.
What's Live & What's Not
✓ Live & Verified
- WRITER-02: Drafts essays. Real code, live drafts in queue.
- CRITIC-04: Scores drafts on every WRITER run. Real code, 7-axis rubric.
- SCOUT-01: Fills topic pool. Real code, candidate generation working.
- Studio auth: Magic-link login, owner-only access enforced.
- Studio dashboard: Live run feed, cost ticker, draft queue. Polls every ~3s.
- Database layer: Migrations applied, RLS enabled, service role gates enforced.
- Datadog tracing: WRITER-02 and CRITIC-04 calls are traced and logged.
⚠ Built But Unverified
- PUBLISHER-05: Code exists, compiles, likely works. No production run observed yet.
- PUBLISHER-05's real LinkedIn posting: Code exists (OAuth connect flow, Posts API call). No LinkedIn Developer App is registered yet, so it has never been exercised against a real LinkedIn account.
- ANALYTICS-07: Code exists, stats logic tested. Never run end-to-end to verify output quality.
- MATCH-06: Code exists, two input modes. Untested in production.
- PRODUCER-03: Code exists, drafts a video script per essay. No production run observed yet.
- Weekly analytics digest publishing: Scheduled job exists, but no complete run observed.
- Email unsubscribe flow: Migration and handler logic exist, untested end-to-end.
✗ Not Yet Implemented
Some operational and observability hardening remains: rate limiting, resilience patterns, audit trails, and UI polish. These do not block the current mission (publish essays with human control) but represent the natural gap between a lean startup and a hardened production system.
Architecture Notes
This system accepts some technical debt in exchange for speed and simplicity:
- Essays are not versioned. I can edit published text via the studio, but edits overwrite the current version with no history or rollback capability.
- Migrations are applied manually, not auto-deployed. Small risk of code expecting columns that don't exist yet (mitigated by fallback logic).
- No feature flags. All deployments are all-or-nothing. New agent features ship or they don't; no gradual rollout.
- Design system is informal (Tailwind config with CSS variables). Not published as a separate token library.
These are acceptable tradeoffs for a personal-brand site. A production SaaS might make different choices.