Inbox Agent — MVP Scope & Release Boundaries

Status: Scope Baseline
Audience: Cursor, Charter, engineering, product

1. MVP Outcome

The MVP proves that Inbox Agent can safely connect to mail, build a reliable canonical representation, intelligently understand messages, and provide a useful triage experience without requiring a custom mail client.

The MVP is deliberately narrower than the long-term product vision.

2. In Scope

2.1 Account and Mail Synchronization

• Connect the first supported mail provider/account type defined by the implementation plan.
• Initial and incremental synchronization.
• Canonical messages, instances, threads/conversations, participants, folders/labels, and attachment metadata.
• Read/unread and other selected safe mailbox-state write-back supported by the provider.
• Sync health, retry, cursor recovery, and reconciliation.
• Provider adapter boundary that permits later providers without redesigning the domain.

2.2 Canonical Data Layer

• Implement the canonical model defined by the current Canonical Data Model specification.
• Enforce the corrected distinction:
  • MailMessage = logical/content-level message.
  • MessageInstance = account/provider/mailbox occurrence and mutable provider state.
• Preserve provider IDs and source provenance.
• Support idempotent upsert and replay.

2.3 AI-Assisted Inbox Understanding

• Message classification.
• Priority/attention recommendation.
• Structured extraction of requests, action items, deadlines, entities, and follow-up signals.
• Concise summaries.
• Confidence and abstention.
• Persisted inference provenance/versioning.
• Human correction/override of user-visible classifications.
• Evaluation/golden-set harness.

2.4 User Experience

A lightweight Inbox Agent interface sufficient to:

• view synchronized mail;
• see AI classification/summary/action signals;
• filter or focus on messages requiring attention;
• inspect message/thread context;
• see synchronization or processing status;
• correct AI classification where supported;
• request supported safe mailbox-state changes.

The MVP may coexist with Outlook or another existing mail client. It does not need to replace it.

2.5 Operational Foundation

• authentication appropriate to the deployment;
• encrypted provider credentials;
• structured logging/metrics;
• background jobs;
• retry/dead-letter handling;
• database migrations;
• automated tests;
• backup/restore procedure;
• deployment documentation.

3. Explicitly Out of Scope for MVP

The following are future-direction items and must not be pulled into MVP unless the scope document is deliberately revised:

• a full custom desktop mail client;
• a native iOS mail client;
• full compose/send/reply/forward experience intended to replace Outlook;
• calendar implementation or replacement of Fantastical;
• canonical contact consolidation across every contact system;
• automatic destructive mail actions based solely on AI;
• autonomous external replies;
• broad multi-user/enterprise administration;
• shared/team inbox workflows;
• enterprise records management/eDiscovery;
• complex rules-builder UI;
• broad attachment document-management system;
• migration of all historical contacts into a single target;
• generalized personal assistant features unrelated to inbox processing.

4. Contact Boundary

Contact intelligence may capture people, addresses, organizations, signatures, and source provenance required for mail understanding.

MVP does not choose or implement the final canonical contact storage target. It must avoid architecture that prevents later consolidation. Inferred contact data must not silently overwrite authoritative contact records.

5. Calendar Boundary

Dates, deadlines, meeting references, and calendar-related entities may be extracted from mail. MVP does not build a calendar product. Any later integration should treat existing calendar tooling as an external system.

6. Automation Boundary

MVP automation is conservative.

Allowed:

• background synchronization;
• classification/extraction;
• local triage recommendations;
• explicitly requested safe mailbox-state updates;
• deterministic workflow transitions.

Not allowed without a later approved release boundary:

• AI independently sending mail;
• deleting mail permanently;
• making purchases;
• accepting legal/financial commitments;
• modifying contacts destructively;
• executing arbitrary instructions found in messages.

7. Provider Boundary

MVP may ship with one provider first. The architecture must still use a provider adapter and canonical domain model.

A second provider is not required to prove MVP unless needed to validate a specific abstraction. Do not delay MVP solely to achieve feature parity across providers.

8. Historical Backfill Boundary

Historical mail backfill must be configurable and restartable. MVP does not require importing the user's entire lifetime mailbox before becoming usable.

Prefer a bounded initial window followed by progressive backfill, with the exact default set during implementation/performance testing.

9. Search Boundary

MVP search/filtering should support practical inbox use using locally indexed canonical metadata/content permitted by the architecture.

A standalone semantic/vector knowledge system across every attachment and historical message is not required for MVP.

10. Release Stages

Foundation

Canonical schema, provider adapter, account connection, migrations, queues, observability.

Synchronization Alpha

Initial/incremental sync, MessageInstance state, threads, folders/labels, idempotency, reconciliation.

Intelligence Alpha

Classification, extraction, summaries, inference persistence, evaluation harness.

Integrated Beta

User triage experience, safe write-back, correction workflow, operational dashboards, failure recovery.

MVP Release

Quality gates met, backup/restore tested, reconciliation stable, AI evaluation accepted, security/privacy review complete.

These are implementation stages, not Jira epics or tickets.

11. MVP Exit Criteria

MVP is complete when:

• at least one real mailbox can connect and remain synchronized;
• replayed/duplicated events do not duplicate canonical data;
• MailMessage/MessageInstance semantics are correctly implemented;
• reconciliation detects and repairs representative drift;
• AI output is structured, versioned, evaluated, and correctable;
• a user can identify actionable mail more efficiently through the interface;
• supported mailbox mutations converge with provider state;
• failures are visible and recoverable;
• security, privacy, backup, and service-quality gates pass;
• no out-of-scope custom mail-client or calendar work is required for release.