Your accounts
Personalcfpperche@gmail.com · Google
Companycarlos@cognix.se · provider to confirm
A company address stays private unless you explicitly grant access. Other supported accounts can be added later.
Recommended direction
Core experience.
Provider extensions.
The Inbox stays a first-class COGNIX[WS] surface. Official extensions connect Gmail, Microsoft and other providers through a versioned mail contract.
You connect an account once. Seeing mail yourself and letting an agent use it are separate decisions.
01
Keep decisions visible
Needs you retains its own queue and badge. Incoming mail cannot bury a blocking approval.
02
Always know the account
Every conversation has an origin. Replies use the receiving account; changing From is explicit.
03
Agents ask before sending
Account access is off by default. Drafting and approved sending have separate grants.
01 / Product scope
First complete release
- Unified view and account filters
- Read, reply, reply all, forward and compose
- Local drafts and attachments
- Read and archive state synchronized with the provider
- Visible sync, reconnect and uncertain-send states
02 / Architecture choice
| Option | Benefit | Trade-off |
|---|---|---|
| Everything in core | Less initial adapter protocol work. | Every provider adds core maintenance and release coupling. |
| Everything in an extension | Independent package and optional installation. | A separate app fragments the Inbox; deep integration still needs core doors. |
| Hybrid Recommended | One native Inbox, optional providers and central controls. | Upfront work on mail, authorization and operation contracts. |
03 / Three participants
Connect and decide
Connect accounts, read and write mail, choose agent access and approve exact outgoing messages.
Read and prepare
Use only granted accounts, summarize selected messages, prepare drafts and propose work or sends.
Synchronize and record
Keep identities separate, reconcile provider state, preserve drafts and expose failures honestly.
This is a design proposal. No accounts have been connected, no email has been read or sent, and no product code has been changed.
Suggested walkthrough
→→→→→→
Boundaries to approve
One mail model.
Replaceable provider adapters.
Extend the platform at explicit doors. Provider packages do not inject arbitrary components into the host interface.
Person + granted agents
Inbox · Email tools
Native desktop, browser and phone experience
↓ reviewed actions and scoped reads ↓
Core
Mail domain + connection broker
Accounts · threads · messages · drafts · operations · grants
Host authorization · refresh · revocation · approval · receipts
↕ versioned mail API and constrained authenticated operations ↕
Google extension
Gmail + Workspace
Microsoft extension
Microsoft 365 + Outlook
Other adapters
IMAP + SMTP, later
What already exists
| Existing platform support | What mail still needs |
|---|---|
| Core Inbox, conversation navigation and event feed. | A mail model with account/provider identities and email actions. |
| Supervised extension processes, instance activation, private databases, reviewed manifests. | A provider declaration, account lifecycle, mail sync contract and operation receipts. |
| Calendar provider extension doors. | A mail door with a separate contract; email is not an FYI item. |
| Assistant-owned OAuth connections. | Person-owned service connections with distinct grants; no automatic credential sharing. |
Canonical data and identity
Use separate mail tables for accounts, threads, messages, drafts, operations and grants. Do not stretch inbox_items into a MIME store.
Account + external conversation + external message form the identity boundary. Equal subjects across accounts never imply equal conversations.
Keep owner drafts and operation records durable in the core. Adapter cursors and reproducible provider cache stay separate. Store mutations announce their events transactionally.
Connection broker: new work
The host owns authorization, refresh and revocation. Adapters use reviewed, constrained authenticated operations, with pinned origins, methods and resources; this is not an arbitrary HTTP proxy.
This generalizes the existing Assistant-specific OAuth boundary and needs an ADR. It is proposed work, not an existing extension capability.
Extension processes run as the operating-system user. Reviewed permissions are a consent contract; they do not create OS process isolation.
Sync and recovery rules
| Condition | Action |
|---|---|
| New account | Import a bounded recent window, then continue with incremental synchronization. |
| Gmail history expires / provider cursor is invalid | Resynchronize the configured window without duplicating messages. |
| Message changed in Gmail or Outlook | Reconcile read/archive state; preserve an open local draft. |
| Send response is lost | Mark uncertain and reconcile. Never blindly resend. |
| Grant revoked / account disconnected | Refuse new scoped operations, reconcile any already dispatched action, retain drafts. |
| Backup restored | Restore declared user data. Reconnect missing credentials. Restored operations never auto-send. |
| Extension removed | Explain affected accounts; keep user drafts/history by default. Deletion is an explicit choice. |
Content and model access
Email HTML is untrusted: isolate rendering, block scripts and control remote images. Attachments are not executed. Received text cannot authorize tools.
Agent access is per account and principal. Sending mail to a model is a separate data flow that must be disclosed and checked against the provider's data policy.
Backup coverage
Declare mail records, attachments and drafts in the persistence inventory. Add independent recovery fixtures for current and older snapshots.
Existing extension and Assistant secret stores have explicit backup exclusions. Mail cannot promise portable sign-in recovery without an approved change to that policy.
Proposed execution
Deliver a complete loop,
then widen provider coverage.
Contract and experience
Approve architecture boundaries, wireframes, account grants, operation states and backup behavior. Record the core/extension and OAuth changes in an ADR.
Exit: reviewable contract + decision table + desktop and phone states.Google reading pilot
Connect multiple accounts, import recent threads, read and search, resume sync and reconnect.
Exit: real-provider read/sync evidence; no claim of a complete mail client yet.First complete release
Compose, reply, reply all, forward, attachments, drafts, read/archive synchronization and the actual provider of carlos@cognix.se.
Exit: both requested accounts complete the read → reply → provider reconciliation loop.Agent collaboration
Explicit account grants, bounded reading, draft proposals, immutable send reviews and optional conversion to a mission.
Exit: unauthorized reads refused; changed messages invalidate prior send approval.Additional providers
Add providers by demand, IMAP/SMTP coverage and push notifications where the deployment supports them.
Exit: every adapter passes the shared provider contract.First-release acceptance
- Both requested accounts work without identity leakage.
- Reply From matches the receiving account.
- Read and archive changes reconcile in both directions.
- Duplicates and lost responses do not cause blind resend.
- Restart and restore preserve drafts and stop automatic replay.
- Needs you remains visible under high mail volume.
- Desktop Windows and physical-phone checks have separate receipts.
Open decisions
- Confirm the company account provider.
- Approve the hybrid boundary and person-owned connection broker.
- Choose initial history window and content retention.
- Define the production OAuth registration owner.
- Approve backup and reconnect behavior.
- Confirm whether agent access ships with V1 or follows it.
Google launch dependency
Gmail read-only and modify scopes are restricted. A personal pilot and public distribution have different verification conditions. Determine verification and any assessment requirement from the actual deployment and data flow, including model access.
Use read-only for a reading pilot. A full read/archive/reply experience needs an appropriately broader reviewed scope; application grants must still restrict what each agent can do.
Each implementation branch follows the repository's isolated-worktree, documentation, scoped-check and closing workflow. Integration and deployment remain separate authorized steps.
Research basis
Functional patterns.
Visual references.
The three Dribbble artworks below were opened in the conversation browser and inspected visually. They inform layout and hierarchy; they do not prove connection or synchronization behavior.
Robert Licau
Desktop email app · dark mode ↗Adopt the list-to-reply continuity, explicit From selector and attachment tiles. Avoid decorative translucent window chrome.
Dawid Jankowski
E-mail Client · Inbox Dark Mode ↗Adopt sender/subject hierarchy and muted previews. Avoid repeated bright NEW badges and a second chat section.
Jordan Hughes · Untitled UI
New message ↗Adopt recipient chips and subject/body separation. Add explicit account identity and visible Send; those states are absent from the artwork.
Product benchmarks
SparkUnified Inbox and separate account views ↗FrontIndividual accounts private by default ↗SuperhumanFocused splits and keyboard triage ↗ThunderbirdAccount and sender-identity model ↗
Primary technical sources
- Google: Gmail authorization scopes
- Google: desktop OAuth, browser authorization and PKCE
- Google: full and partial synchronization
- Google: push notifications and watch renewal
- Google: restricted-scope verification and exceptions
- Google Workspace: user data and developer policy
- Microsoft: per-folder delta synchronization
- Microsoft: immutable message IDs
- Microsoft: send acceptance versus completed delivery
- IETF: IMAP4rev2 and separate mail submission
Repository evidence reviewed
docs/architecture/inbox.md · extensions.md · assistant.md · backups.md · ADR-0208, ADR-0221, ADR-0230, ADR-0324 · internal/server/extensions_host.go · internal/store/inbox.go · internal/backup/inventory.json
Visual foundation: the canonical web/shared/tokens/theme.css, the existing Inbox study and the repository's Cursor adaptation for compact, keyboard-accessible controls.