Pollux

A permissioned AI communication twin that learns your style and helps you reply across connected apps with human approval controls.

Comment

Inspiration

AI tools are getting better at writing, but communication workflows still feel broken.

Important conversations are spread across email, chat, and notifications. Many AI assistants can draft 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 AI becomes involved.

That was the starting point for Pollux.

We wanted to build an AI communication copilot that feels genuinely useful in daily work while staying grounded in a clear permission model. Instead of asking users to copy messages into a separate AI tool, Pollux connects to the platforms they already use, helps them review what matters, drafts replies in context, adapts to their writing style, and keeps them in control before anything is sent.

At a broader level, Pollux is also an exploration of a bigger product question:

How should AI systems act on behalf of users inside explicit authorization boundaries?

What it does

Pollux is a permissions-aware AI communication copilot for email and team chat.

It brings identity, connected accounts, message context, reply generation, personalization, and platform-native actions into one product surface.

Today, Pollux supports

  • Gmail: real inbox reading, real message detail retrieval, AI reply generation, and real sending
  • Slack: real OAuth connection, real message reading, AI reply generation, and real sending
  • Outlook: inbox access powered by Auth0 Connected Accounts + Token Vault
  • Unified Inbox: a shared interface for triaging communication across providers
  • Style Personalization: reply style learned from presets, writing samples, or Gmail sent mail
  • Daily Brief: AI-assisted summaries of what happened today and what needs attention
  • Persistence and Send Logs: database-backed reliability for connected accounts, style profiles, and action history

Core workflow

  1. Sign in with Auth0
  2. Connect Gmail, Slack, and/or Outlook
  3. Open a real message in Pollux
  4. Generate AI reply candidates
  5. Review or edit the draft
  6. Send through the original platform where supported

Pollux is designed so that AI helps with drafting, summarizing, and prioritizing, while the user remains in control of meaningful outbound actions.

How we built it

We built Pollux as a modern full-stack web app using:

  • Next.js 15
  • React 19
  • TypeScript
  • Tailwind CSS
  • Prisma
  • Neon PostgreSQL
  • OpenAI API
  • Auth0

Architecture overview

Identity and access

Auth0 powers product authentication and session handling across Pollux. It also powers the Outlook provider path through Connected Accounts + Token Vault.

Provider integrations

  • Gmail is connected through direct OAuth and Gmail API integration
  • Slack is connected through direct OAuth and Slack Web API integration
  • Outlook is connected through Auth0 Token Vault, with Microsoft Graph inbox reads normalized into the shared internal message model

AI layer

Pollux uses OpenAI to generate:

  • multiple reply candidates
  • style-aware drafts
  • Daily Brief summaries
  • provider-sensitive responses for email vs chat

Reliability and persistence

We used Prisma with Neon PostgreSQL to persist:

  • Gmail token state
  • Slack token state
  • style profiles
  • send logs

We also added backend-owned message retrieval for more reliable reply/send behavior, safe HTML email rendering, provider-aware fallbacks, and local development fixes for OAuth consistency when testing with ngrok.

Challenges we ran into

1. Real provider integrations are much harder than mocks

Connecting Gmail and Slack meant dealing with OAuth flows, token storage, callback URLs, provider-specific message formats, MIME parsing, thread behavior, and send semantics. Getting these flows to work reliably inside one product took much more effort than building the UI around them.

2. Reliability matters more than the demo path

Early MVP state could live in memory, but that quickly became fragile. Once we wanted Pollux to feel like a real product, persistence became necessary. We migrated key state such as provider tokens, style profiles, and send logs into PostgreSQL so the product would survive restarts and behave more consistently.

3. AI should not blindly trust inbound content

Inbound email or chat content can contain text that looks like instructions. Because Pollux generates replies to external messages, we had to treat inbound content as untrusted and structure prompts so the model assists the user rather than following instructions embedded inside messages.

4. Personalization is harder than changing tone labels

We did not want style control to be a simple professional vs friendly toggle. We built multiple ways to create a user writing profile, including presets, pasted samples, uploaded samples, and learning from Gmail sent mail. Making that flexible, coherent, and demo-ready took several iterations.

5. Multi-provider architecture needs clear boundaries

Once multiple platforms are involved, the product has to clearly separate:

  • who the user is
  • what accounts are connected
  • what Pollux is allowed to access
  • what Pollux is allowed to do

That challenge shaped much of the product design. Pollux is not just a text generator with integrations added later; it is built around explicit authorization boundaries from the start.

What we learned

We learned that useful AI products are not just about model output quality. They are about workflow, trust, and boundaries.

A good AI draft is not enough if:

  • the user cannot tell what the system can access
  • the send path is inconsistent
  • the message context is unreliable
  • the product hides the approval boundary before an action is taken

We also learned that many of the most important product qualities come from the less glamorous parts of the system:

  • token persistence
  • safe rendering
  • backend ownership of sensitive operations
  • structured logging
  • consistent provider adapters
  • review-before-send UX

In other words, building a trustworthy AI copilot is as much a systems and product-design problem as it is a model problem.

What’s next

Pollux is already a working multi-platform prototype, but there is still a lot we want to push further.

Next steps include

  • richer action extraction and prioritization
  • better auditability for AI-assisted actions
  • deeper Outlook support beyond inbox access
  • attachment handling improvements
  • database-backed viewed state and preferences
  • stronger risk classification
  • broader provider coverage
  • better visibility into permission scopes and connected account boundaries

Our long-term goal is to make Pollux into a true permission-aware AI communication layer: a system that helps users act across communication tools without becoming opaque, over-privileged, or out of control.

Why Pollux is different

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 stay in control

That is the core product idea behind Pollux.

The Outlook path extends this idea further by showing how Pollux can use Auth0 Token Vault to access an external provider without requiring the app to manage Microsoft refresh tokens directly.

Bonus Blog Post

One of the most interesting parts of building Pollux was realizing that a communication copilot is not just an AI feature layer — it is an authorization problem.

At first, Pollux was centered around direct Gmail and Slack integrations. That already taught us a lot: each provider has its own OAuth flow, token lifecycle, message structure, and sending behavior. Even when the UI looked simple, the system underneath had to reconcile multiple platform models while still feeling trustworthy to the user.

The Outlook path pushed that idea further. Instead of treating Microsoft integration as “just another provider,” we explored using Auth0 Connected Accounts + Token Vault as a different access pattern. That changed how we thought about the product. Rather than storing and managing Microsoft refresh tokens directly in the app, Pollux could retrieve provider access through Auth0’s identity and authorization layer. Technically, this reduced some token-management complexity on our side. Conceptually, it made the product more aligned with our core thesis: AI systems should operate inside explicit, understandable permission boundaries.

That did not mean the work became easy. We still had to normalize Outlook inbox data into our shared internal message model, keep the UX coherent beside Gmail and Slack, and clearly communicate that the Outlook path was currently an inbox-access provider route rather than a full send integration. But that challenge was valuable, because it forced us to think carefully about what Pollux is really becoming.

The biggest lesson from Token Vault was this: better AI products are not only about better generation. They are about identity, delegated access, and making sure the user can still understand who is acting, with what permission, and on whose behalf.

Note

Solo-built prototype running from my personal machine for demo purposes, so continuous uptime cannot be guaranteed during judging. I will do my best to keep it live. Video, repo, screenshots, and test instructions fully demonstrate the project.

Built With

  • auth0
  • dompurify
  • gmail-api
  • neon-postgresql
  • next.js
  • oauth-2.0
  • openai-api
  • prisma
  • react
  • slack-api
  • tailwind-css
  • typescript
Share this project:

Updates