Building an AI Email Intelligence Pipeline with Gmail, n8n, OpenRouter & PostgreSQL

The Problem

Important Gmail messages required manual review and triage. The goal was to create a structured intelligence layer around the inbox so urgency, sentiment, category, and reply requirements could be reviewed in one dashboard.

The Architecture

• Gmail provides the incoming email input.
• n8n orchestrates receipt, content preparation, the AI call, and routing for storage.
• OpenRouter AI produces the summary, classification, priority, sentiment, and reply analysis.
• PostgreSQL stores the structured result.
• Next.js renders a secure, searchable, filterable dashboard.

The automation writes the workflow output, while the dashboard reads it without modifying email records or the n8n workflow.

The Query Layer

The dashboard database access lives in a server-only module. It reads from the public.emails table and selects sender, subject, body, summary, priority, category, suggested action, reply status, sentiment, confidence, dates, and message identifiers.

The same parameterized query layer supports sender-or-subject search, priority, category, sentiment, and reply-required filters. It orders rows by received date and paginates them in groups of 20. Separate parallel reads provide totals, high-priority and reply-required counts, average confidence, and database-backed filter options.

Implementation Decisions

The PostgreSQL client stays on the server and uses SSL by default. The browser never receives database credentials or talks directly to PostgreSQL. The admin area uses a signed session and a scrypt password hash with a timing-safe comparison.

The dashboard also normalizes category values and formats confidence values at the presentation boundary. Those safeguards keep imperfect stored values from becoming broken filter options or confusing labels.

Challenges

The main challenge was keeping an external automation workflow and a read-only dashboard loosely coupled. The dashboard can evolve around the structured result without becoming part of ingestion.

Another boundary is the public demo. It uses fictional examples only; the real dashboard remains private and continues to read the PostgreSQL workflow output behind authentication.

Lessons Learned

AI output becomes more useful when it is stored as predictable fields rather than left as raw text. Summary, category, priority, sentiment, reply status, suggested action, and confidence give the interface concrete values to query.

Read-only dashboards still need strong boundaries. Server-only database access, protected admin routes, and anonymized public examples make the system safer to explain and share.