A permissions-aware AI communication copilot for email and team chat.
Pollux helps users review messages, generate context-aware replies, and send responses through the original platform — while keeping the user in control of every meaningful action.
Demo video: https://youtu.be/TH21j4cuX7Q
Pollux is a full-stack AI communication product built around a simple trust model:
- users sign in explicitly
- users connect communication platforms intentionally
- AI helps with drafting, summarizing, and prioritizing
- outbound actions remain visible and user-approved
Instead of copying messages into a separate AI tool, Pollux brings identity, account connection, message context, reply generation, and sending into one product surface.
- Gmail: real inbox reading, real message detail retrieval, AI reply generation, real sending
- Slack: real OAuth connection, real message reading, AI reply generation, real sending
- Outlook: inbox access powered by Auth0 Token Vault through Connected Accounts
- Dashboard / Inbox / Settings: polished product UI for daily use
- Style Personalization: custom reply style learned from presets, writing samples, or Gmail sent mail
- Daily Brief: AI-assisted summary of what happened today and what needs attention
- Persistence: database-backed token storage, style profile storage, and send logs
Modern communication is fragmented.
Important work is split across email, chat, and notifications. Most AI tools can generate text, but they often sit outside the real workflow. They do not clearly show what data they can access, what actions they are allowed to take, or how much control the user still has once the AI is involved.
That becomes a bigger issue when AI stops being just a writing tool and starts acting on behalf of users.
A trustworthy communication copilot needs more than good text generation. It needs:
- clear identity
- explicit platform connection
- scoped access
- understandable permission boundaries
- strong human review before high-impact actions
Pollux is built around that model.
Pollux is a permissions-aware AI communication copilot.
It lets users connect the platforms they already use, view real messages in one interface, generate multiple AI reply options, personalize reply style, and send the final response through the original provider.
- Sign in with Auth0
- Connect Gmail, Slack, and/or Outlook
- View real inbound messages
- Ask Pollux to generate reply candidates
- Review and optionally edit the draft
- Send through the original platform where supported
- See activity reflected in summaries, send logs, and the unified inbox flow
Pollux is not only about replying faster.
It is a product exploration of a larger question: how should AI systems act on behalf of users inside explicit authorization boundaries?
Pollux makes that question concrete by showing:
- explicit connection flows instead of hidden access
- platform-aware actions rather than detached text generation
- user review before sending
- separation between identity, connected accounts, and AI-assisted actions
- a UI that makes the workflow feel understandable rather than magical
That makes Pollux relevant both as a useful communication product and as a practical prototype for safer agent authorization patterns.
- Aggregate connected communication channels into one product surface
- Support provider-aware rendering for Gmail, Slack, and Outlook
- Show source, risk, message status, and interaction state in one view
- Gmail OAuth connection flow
- Real inbox retrieval through Gmail API
- Message detail parsing with MIME handling
- HTML email sanitization with DOMPurify
- Attachment metadata extraction
- Real reply sending via
gmail.users.messages.send - Thread-aware sending using Gmail thread context
- Slack OAuth connection flow
- Real message retrieval from accessible channels and DMs
- Provider-aware message fetch and send paths
- Real reply sending via Slack API with thread support
- Microsoft account connection through Auth0 Connected Accounts
- Outlook inbox access powered by Auth0 Token Vault
- Provider access retrieved through Auth0 rather than app-managed Microsoft refresh tokens
- Microsoft Graph inbox reads normalized into the shared
MessageItemmodel - Outlook messages surfaced in the same inbox UI as Gmail and Slack
In the current version, Outlook is implemented as a Token Vault-powered inbox provider path. Gmail and Slack remain existing direct integrations.
- Multiple reply candidates per message
- OpenAI-backed generation with graceful fallback
- Prompt-injection-aware prompt design
- Provider-sensitive tone differences between email and chat
- Reply source labeling for transparency
Users can build a personalized writing profile through four paths:
- start from a preset
- learn from recent Gmail sent mail
- upload writing samples
- paste writing samples directly
The resulting style profile can include:
- tone rules
- banned phrases
- sign-off patterns
- greeting patterns
- directness level
- hedge-word preferences
- representative writing examples
- user guardrails
- Summarize today’s communication activity
- Highlight high-attention items
- Extract action items
- Break down activity by provider
- Support rule-based generation with AI upgrade and fallback
- Cache summary generation for better stability and cost control
- Gmail tokens persisted to Neon PostgreSQL
- Slack tokens persisted to Neon PostgreSQL
- Style profiles persisted to Neon PostgreSQL
- Send logs persisted for traceability
- Backend-driven message fetching for reply and send consistency
- HMR-safe in-memory caching patterns for local development
- Better local development handling for ngrok / OAuth domain consistency
Pollux is designed so that AI assistance stays inside explicit boundaries.
-
Explicit sign-in
- User identity is handled through Auth0.
-
Explicit provider connection
- Gmail and Slack access are granted through dedicated OAuth flows.
- Outlook is connected through Auth0 Connected Accounts.
- Platform access is not assumed or bundled invisibly.
-
Scoped access
- Pollux only operates with the scopes granted to the connected provider.
- Gmail and Slack connections are handled directly in the app.
- Outlook access is retrieved through Auth0 Token Vault.
-
Human-in-the-loop sending
- AI drafts suggestions.
- The user still reviews and approves the message before it is sent.
-
Backend consistency for sensitive actions
- Reply generation and sending prefer backend-fetched real message context rather than trusting the frontend alone.
- This reduces mismatch between what the user saw and what the system sends.
-
Visible action channels
- Send results are surfaced clearly, including whether a reply was sent through a real provider path or a fallback path.
-
Safe rendering
- HTML email content is sanitized before rendering.
- Suspicious prompt-like instructions in inbound messages are treated as untrusted content in the generation pipeline.
Pollux separates three layers:
-
Who the user is
Auth0 session and identity -
What Pollux can access
provider-specific connection state and granted scopes -
What Pollux can do
summarize, draft, and prepare replies — with the final send action remaining user-approved
In the current architecture, Auth0 powers product authentication and session management across Pollux, and also powers the Outlook provider path through Connected Accounts + Token Vault. Gmail and Slack remain existing direct integrations.
- Video: https://youtu.be/TH21j4cuX7Q
- Live app: https://transnationally-jauntier-fritz.ngrok-free.dev
- Repository: https://github.com/GuZZ1119/Pollux
The video is the fastest way to understand the Gmail / Slack workflow and the Outlook authorization path powered by Auth0 Token Vault.
- Sign in to Pollux
- Connect Gmail, Slack, or Outlook
- Open the Inbox
- Pick a message
- Generate AI reply candidates
- Select or edit a draft
- Send through Gmail or Slack where supported
- Review Daily Brief or continue triage
- Auth0 establishes authenticated product access
- Gmail or Slack OAuth connects direct providers
- Outlook is connected through Auth0 Connected Accounts
- Provider adapters fetch normalized message data
- For Outlook, Pollux retrieves provider access through Auth0 Token Vault
- Message detail is parsed and normalized into shared internal types
- Reply generation builds prompt context from:
- message content
- sender / subject / provider
- user style profile
- representative writing examples
- guardrails
- The user chooses a draft
- The backend re-fetches authoritative message context when needed
- The message is sent through the platform-native API where supported
- Send logs and style/persistence state are stored in PostgreSQL
Pollux is structured as a modern full-stack web application with provider adapters.
- Next.js 15
- App Router
- React 19
- Tailwind CSS 4
- polished Dashboard / Inbox / Settings experience
- Auth0 for product login and session handling
- direct provider OAuth flows for Gmail and Slack
- Auth0 Connected Accounts + Token Vault for Outlook
- Gmail OAuth + Gmail API
- Slack OAuth + Slack Web API
- Outlook via Auth0 Token Vault + Microsoft Graph
- provider adapter layer for inbox and send paths
- backend message fetchers for authoritative message detail retrieval
- OpenAI-based reply generation
- style-aware prompt composition
- Daily Brief AI summary path with fallback
- injection-aware prompt structure
- Prisma ORM
- Neon PostgreSQL
- token storage
- style profile storage
- send log storage
- HMR-safe global caches for local development
- summary caching
- event logging
- provider-aware fallbacks
- ngrok-safe callback redirect handling via
APP_BASE_URL
- Next.js 15
- React 19
- TypeScript 5
- Tailwind CSS 4
- Next.js Route Handlers
- Prisma 6
- Neon PostgreSQL
- Auth0
- Auth0 Connected Accounts
- Auth0 Token Vault
- Google OAuth
- Slack OAuth
- Gmail API
- Slack Web API
- Microsoft Graph
- OpenAI API
gpt-4o-minifor reply generation and summary generation
- DOMPurify for sanitized HTML email rendering
- ESLint 9
- PostCSS
- ngrok for public local callback testing
Pollux was significantly advanced during the hackathon period.
It moved from a minimal runnable scaffold to a multi-platform, persistence-backed product prototype with a polished UI and a complete end-to-end demo flow.
- built the initial full-stack scaffold with typed domain models and mock adapters
- added Auth0-based login flow
- added Gmail OAuth connection flow
- replaced mock Gmail inbox with real Gmail inbox retrieval
- added MIME parsing, HTML rendering, and attachment metadata extraction
- connected OpenAI-based reply generation
- implemented real Gmail sending
- introduced risk classification, inbox metrics, filtering, and event logging
- polished the Inbox and Settings UX for demo quality
- added Daily Brief and provider-agnostic summarization
- shipped Style Personalization V1
- migrated key state to Neon PostgreSQL
- added backend-owned message fetching for more reliable reply/send behavior
- upgraded Slack from mock to a real second platform
- added an Outlook inbox path powered by Auth0 Token Vault
- fixed OAuth redirect consistency for local + ngrok development
- finalized the product into a submission-ready demo
This is not a static concept repo. It is a working product prototype with real provider integrations and a real user flow.
- Node.js 18+
- npm
- a Neon or PostgreSQL database
- Auth0 application credentials
- Google OAuth credentials
- Slack OAuth credentials
- Microsoft / Azure app registration for the Outlook Token Vault path
- OpenAI API key for live generation
npm installCreate .env.local from .env.example and fill in your credentials.
Typical variables include:
AUTH0_DOMAIN=
AUTH0_CLIENT_ID=
AUTH0_CLIENT_SECRET=
AUTH0_SECRET=
APP_BASE_URL=http://localhost:3000
DATABASE_URL=
OPENAI_API_KEY=
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
GOOGLE_REDIRECT_URI=http://localhost:3000/api/auth/gmail/callback
SLACK_CLIENT_ID=
SLACK_CLIENT_SECRET=
SLACK_REDIRECT_URI=
# Optional; defaults to windowslive
AUTH0_MS_CONNECTION_NAME=windowslivenpx prisma generate
npx prisma db pushnpm run devThen open:
http://localhost:3000
Configure your Auth0 application with callback/logout origins for local development.
Typical values:
- callback URL:
http://localhost:3000/auth/callback - connected accounts callback URL:
http://localhost:3000/auth/connect - logout URL:
http://localhost:3000
If using ngrok, also include the public ngrok URL in Auth0 allowed origins.
Configure Google Cloud OAuth redirect URI:
http://localhost:3000/api/auth/gmail/callback
For localhost-only development, Slack OAuth is limited because Slack expects a public callback URL.
For public local testing with ngrok:
- run
npm run dev - expose port 3000 via ngrok
- set
APP_BASE_URLto your ngrok HTTPS URL - configure the Slack app redirect URL to:
https://<your-ngrok-domain>/api/auth/slack/callback
- restart the dev server after changing environment variables
Pollux uses APP_BASE_URL to keep callback redirection consistent in proxied local environments.
For the Outlook provider path:
- create a Microsoft app registration
- set the redirect URI to:
https://<your-auth0-domain>/login/callback
- add Microsoft Graph delegated permissions such as:
User.ReadMail.Read
- create a Microsoft Account social connection in Auth0
- enable Connected Accounts for Token Vault
- enable the connection for your Pollux app
- ensure your Auth0 app includes:
APP_BASE_URL/auth/connectin allowed callback URLs
This repository is intended to be easy to review.
-
Watch the demo video
https://youtu.be/TH21j4cuX7Q -
Open the live app
https://transnationally-jauntier-fritz.ngrok-free.dev -
Sign in
-
Connect Gmail, Slack, and/or Outlook
-
Open the Inbox
-
Choose a real message
-
Click Generate AI Reply
-
Review the candidate drafts
-
Edit if desired
-
Send through Gmail or Slack where supported
-
Open Dashboard to inspect the Daily Brief summary flow
-
Open Settings to inspect style personalization and connection state, including the Outlook Token Vault path
- explicit sign-in and explicit provider connection
- user-visible control before sending
- real provider integrations
- an Outlook authorization path powered by Auth0 Token Vault
- backend / frontend coordination for trustworthy send behavior
- polished end-to-end UX rather than isolated API demos
- a product architecture that is aware of persistence, fallbacks, and local reliability issues
Live app: https://transnationally-jauntier-fritz.ngrok-free.dev
Demo account: TBD
Test notes: TBD
pollux/
├── prisma/
│ └── schema.prisma
├── src/
│ ├── app/
│ │ ├── dashboard/
│ │ ├── inbox/
│ │ ├── settings/
│ │ └── api/
│ │ ├── auth/
│ │ ├── inbox/
│ │ ├── reply/
│ │ ├── send/
│ │ ├── summary/
│ │ ├── style/
│ │ ├── events/
│ │ └── attachments/
│ ├── components/
│ │ ├── dashboard/
│ │ ├── inbox/
│ │ ├── layout/
│ │ ├── reply/
│ │ ├── settings/
│ │ └── shared/
│ └── lib/
│ ├── adapters/
│ ├── auth0.ts
│ ├── config.ts
│ ├── gmail/
│ ├── outlook/
│ ├── slack/
│ ├── openai/
│ ├── style/
│ ├── services/
│ ├── types/
│ └── viewed-store.ts
├── .env.example
├── package.json
└── README.md
src/lib/adapters/— provider-specific inbox and send adapterssrc/lib/services/— aggregation, send, reply, summary, risk, and event servicessrc/lib/gmail/— Gmail OAuth, token, parsing, client, fetcherssrc/lib/outlook/— Outlook token retrieval through Auth0 Token Vaultsrc/lib/slack/— Slack OAuth, token, client, fetcherssrc/lib/style/— style presets, extraction, storagesrc/components/— UI for dashboard, inbox, replies, settings, and shared primitivessrc/app/api/— route handlers for all product capabilities
Pollux is functional, but it is still an early product prototype.
Current limitations include:
- live deployment and demo credential setup may still require final packaging
- attachment download is scaffolded but not fully implemented
- inbox cursor pagination is not fully implemented yet
- viewed/opened state is still localStorage-based rather than database-backed
- risk classification is keyword-based rather than ML-based
- Daily Brief caching is lightweight and in-memory
- some local development flows still depend on careful OAuth configuration
- Outlook currently supports inbox access only in the Token Vault path
- Gmail and Slack remain existing direct integrations rather than Token Vault-based providers
These limits are real, but they are also clearly bounded and visible in the current architecture.
- richer action extraction and prioritization
- audit-oriented action history views
- stronger provider coverage beyond Gmail and Slack
- deeper Outlook actions beyond inbox read
- attachment download and handling
- database-backed viewed state and user preferences
- more advanced risk classification
- more personalized communication modeling over time
- broader multi-platform communication automation inside explicit approval boundaries
Many AI messaging tools start from the model and add product later.
Pollux starts from the workflow:
- who is signed in
- what account is connected
- what message is being acted on
- what style the user wants
- what the AI is allowed to help with
- when the human must remain in control
That is the product idea at the center of Pollux.
The Outlook path extends that idea further by demonstrating how Pollux can use Auth0 Token Vault to access an external provider without app-managed Microsoft refresh-token handling.
MIT