Continuum — The Operating System for Human Intelligence

Product Specification · System Design · Technical Architecture · Design System · Company Strategy

Working codename: Continuum. The name encodes the core bet: one continuous surface from think → learn → research → create → collaborate → automate → execute, instead of twenty fragmented tools. Rename freely.

Document status: v0.1 founding blueprint. Audience: founders (fundraising), PMs (roadmap), designers (prototypes), engineers (implementation), recruiting (hiring against roles).

How to read this: Sections 1–2 are the thesis and the single most important architectural idea (why 20 products are actually one). Sections 3–10 are the platform substrate — concrete and implementation-grade. Section 11 is the 20 products built on that substrate. Sections 12–17 are business, GTM, competition, sequencing, and org.

#Table of Contents

1. Company Thesis & Category
2. The Consolidation Thesis — One Product, Twenty Surfaces
3. Information Architecture (entity model, hierarchy, relationships)
4. AI Architecture (agents, RAG, memory, tools)
5. UX Design (conversational, agent, explainability, trust) — the throughline
6. Design System
7. Frontend Architecture (React / TS / Tailwind / Next.js / monorepo)
8. Backend Architecture (APIs, services, events, security, compliance)
9. Database Design (schemas, indexes, scaling)
10. Infrastructure (cloud, k8s, CI/CD, multi-region, DR)
11. The Twenty Products (vision, personas, journeys, features per product)
12. Business Model
13. Go-To-Market
14. Competitive Analysis
15. Build Sequencing & Roadmap (the realism section)
16. Org Design & Hiring (design team build-out)
17. Risks & Open Questions

#1. Company Thesis & Category

#1.1 The problem

Knowledge work in 2026 is fragmented across ~15 SaaS tools per knowledge worker (industry surveys put the median at 9–13; power users far higher). Each tool has its own auth, search, notification stream, permission model, and mental model. AI has been bolted onto each silo — a copilot in the doc editor, a copilot in the IDE, a copilot in the inbox — which multiplies fragmentation instead of resolving it. The user is now the integration layer: the human is the message bus, the scheduler, and the memory between tools.

Simultaneously, agentic AI introduces a new, harder problem: probabilistic, autonomous behavior that non-technical users cannot see, understand, predict, or steer. Today's agent products fail not on capability but on legibility — users don't know what the agent did, why, with what data, using what tools, and they have no graduated controls between "fully manual" and "fully autonomous."

#1.2 The thesis

The winning AI company is not a better chatbot. It is the operating system layer that (a) consolidates the fragmented surfaces of knowledge work into one coherent environment, and (b) makes probabilistic agent behavior legible and steerable for non-technical people.

These two are the same bet from two angles. Consolidation gives agents a unified substrate (one memory, one permission model, one search index, one set of tools) so they can actually be useful across the whole of someone's work. Legibility/steerability is what makes that power trustable enough to adopt. Capability without legibility is a demo; legibility without consolidation is a toy.

#1.3 Category

We are not creating "a better ChatGPT" or "a Notion competitor." We are creating the AI-native operating system category: the default environment in which an individual, team, or enterprise does cognitive work, with AI as the substrate rather than a feature. The OS analogy is literal:

#1.4 Why now

1. Frontier models crossed the agentic-reliability threshold (tool use, long-horizon planning, reflection) in 2024–2026 — agents now complete multi-step work reliably enough to trust with the right guardrails.
2. MCP standardized tool/integration plumbing, collapsing the integration tax that previously made "do everything" platforms impossible to maintain.
3. Context windows and retrieval matured to where a unified memory across all of a user's work is technically and economically feasible.
4. Buyer fatigue with point-AI tools — enterprises have 40+ AI pilots and are consolidating budget toward platforms.

#1.5 Founder-market fit

Ex-DeepMind founder → credibility on the research/agent frontier and recruiting. The strategic risk is that research-led companies under-invest in the legibility/interaction layer that determines consumer and SMB adoption. This blueprint treats interaction design as a first-class, defensible moat (Section 5), not a skin.

#2. The Consolidation Thesis — One Product, Twenty Surfaces

The single most important architectural decision in this document: the twenty "products" are not twenty applications. They are twenty surfaces over a shared substrate. Building them as separate apps recreates the fragmentation we exist to kill. Building them as views over common primitives is the entire moat.

#2.1 The shared substrate (five primitives)

Everything in Continuum reduces to five primitives:

1. Entity — a node in the knowledge graph (document, message, person, file, task, agent, memory…). Universally addressable, permissioned, searchable, embeddable.
2. Thread — a unit of interaction over time (a conversation, an agent run, a task's activity log). Append-only, replayable, branchable.
3. Agent — a configured policy (instructions + tools + memory scopes + model) that can be invoked in any thread.
4. Memory — layered, structured + vector knowledge that any agent reads/writes within permission scopes.
5. Tool — an MCP-exposed capability (read/write to an external or internal system).

A "product" is then a lens: a default arrangement of these primitives plus a tailored UI. The Project Management product is threads + tasks + agents with a board/timeline lens. The Research Assistant is threads + memory + web/tools with a report lens. The Coding Assistant is threads + repo-tools + a diff lens. Same substrate, different lens. This is why we can credibly ship 20 things: we ship ~5 things and 20 lenses.

#2.2 Consolidation as the user-visible promise

The user never "switches apps." They switch lenses over the same workspace, the same search, the same notifications, the same memory, the same agents. Concretely:

• One global search spans documents, messages, tasks, code, emails, memories, agent outputs (Section 3.3, 4.2).
• One notification stream unifies @mentions, agent approvals-needed, task changes, automation results (Section 3.10).
• One memory means an agent that learned your writing style in the Doc lens applies it in the Email tool and the Meeting summary.
• One permission model means an enterprise admin configures access once, and it holds across every lens (Section 8.7).

#2.3 What this buys us strategically

• Land-and-expand is free. A consumer who comes for chat finds project management, docs, and automation already there — no new login, no new data import.
• Data network effects compound across surfaces. Every interaction in any lens enriches one memory graph, which makes every other lens better.
• Engineering leverage. A feature built in the substrate (e.g., approval workflows) appears in all 20 products at once.

Tie to the interaction-model role: the person who owns chat, IA/navigation, multi-account/workspace org, and onboarding is, in this architecture, the person who owns the substrate's surface — i.e., the single most leveraged design role in the company, because their work is what makes "20 products" feel like "one product."

#3. Information Architecture

The IA is the load-bearing wall. Get the entity model and hierarchy right and navigation, search, permissions, and the "one coherent experience" promise follow; get it wrong and we recreate the silos.

#3.1 The entity hierarchy

Organization                         (billing, SSO domain, compliance boundary)
│
├── Member (User ↔ Org via Membership; a User can belong to many Orgs)
│
├── Team                             (a group of members; cross-workspace)
│
└── Workspace                        (the primary collaboration & permission container)
     │
     ├── Project                     (a goal-scoped container: docs, threads, tasks, agents)
     │    ├── Document                (rich text / canvas / table — CRDT)
     │    ├── Thread                  (Conversation | AgentRun | TaskActivity)
     │    │    └── Message            (turn: user | agent | tool | system)
     │    ├── Task                    (unit of work; assignable to human or agent)
     │    ├── Automation              (trigger → condition → action graph)
     │    └── Agent (project-scoped)
     │
     ├── Knowledge Base               (curated, governed entities + connectors)
     ├── Agent (workspace-scoped)
     ├── Memory (workspace/team scope)
     └── Connector (MCP server binding: Gmail, GitHub, Drive…)

User (global, identity)
 ├── Personal Workspace              (consumer surface; one per user)
 ├── User Memory (cross-org, private) (writing style, preferences — never shared without consent)
 └── Account (multi-account: personal + each org appears as a switchable account)

#3.2 Entity relationships (the parts people get wrong)

• User ⟷ Organization is many-to-many via Membership. A person has one identity and N accounts (personal + each org). This is the multi-account model (Section 11.14) and a core part of the interaction-model role.
• Workspace is the permission root for collaboration. Projects, KBs, agents, memory inherit from it unless overridden. Personal Workspace is a Workspace with owner_type=user.
• Team is orthogonal to Workspace. Teams are groups of people used as permission subjects ("grant the Design team access"); Workspaces are containers of work. A Team can be granted roles across many Workspaces.
• Thread is polymorphic (kind ∈ {conversation, agent_run, task_activity, meeting}). Same storage, same renderer primitives, different lenses. This is why chat, an agent run, and a task's log all feel like one system.
• Memory has six scopes (Section 4.3) and is the only entity that crosses the Org boundary (User Memory is global-private). Every memory write records provenance and scope; nothing leaks across scopes without an explicit, audited grant.
• Agent is configuration, not compute. An Agent can be defined at user/workspace/project scope; its runs are Threads; its capabilities are Tools; its knowledge is Memory + KB references.
• Automation references Agents, Tools, and Tasks but owns none of them — it's an orchestration graph.

#3.3 Navigation model

Three persistent zones, lens-stable so the user never loses orientation when switching surfaces:

┌────────────┬───────────────────────────────────────┬──────────────┐
│  RAIL      │              CANVAS                     │  CONTEXT     │
│ (who/where)│           (the active lens)             │ (why/what)   │
│            │                                         │              │
│ • Account  │  Chat | Doc | Board | Canvas | Search   │ • Activity/  │
│   switcher │  | Report | Diff | Table                │   Trace      │
│ • Workspace│                                         │ • Memory     │
│   switcher │  (lens-specific, but built from shared  │   used       │
│ • Pinned   │   thread/entity renderers)              │ • Sources    │
│ • Spaces:  │                                         │ • People     │
│   Home,    │                                         │   present    │
│   Chats,   │                                         │ • Approvals  │
│   Projects,│                                         │   pending    │
│   Tasks,   │                                         │              │
│   Agents,  │                                         │              │
│   Knowledge│                                         │              │
│   Automate │                                         │              │
└────────────┴───────────────────────────────────────┴──────────────┘
                         ▲ Command bar (⌘K) overlays everything

• Left rail answers who am I acting as and where am I (account + workspace + spaces). Spaces are lenses, not apps.
• Center canvas is the active lens. Critically, it is chat-first but not chat-only: any thread can spawn or be pinned beside a doc/board/canvas (Section 5.1).
• Right context panel is the home of the throughline: the live Activity/Trace, the memory and sources used, pending approvals, and presence. This panel is the legibility layer made persistent.
• Command bar (⌘K) is the universal entry point: search, navigate, invoke agents, run automations, create entities — one input, ranked by intent (Section 5.1).

#3.4 Global search

Hybrid retrieval over a unified index (Section 4.2). Search is the consolidation proof point: one query, every surface. Results are typed, permission-filtered, and grouped by lens with inline answer synthesis (Perplexity-style) when the query is a question. See 4.2 for the engine; 7.x for the UI.

#3.5–3.15 Entity-by-entity summary

#4. AI Architecture

#4.1 Agent architecture

Design principle: one agent runtime, scaled from a single tool-calling loop to a coordinated multi-agent team, with the same event protocol throughout so the legibility UI (Section 5) never has to special-case complexity.

4.1.1 The core loop (single agent)

A durable plan → act → observe → reflect loop. We run it on Temporal (durable execution) so every step is checkpointed, resumable, and — crucially for the throughline — replayable and undoable.

                ┌──────────────────────────────────────────┐
                │                AGENT RUN                   │
                │                                            │
  user goal ──► │  PLAN ──► ACT (tool call) ──► OBSERVE ──┐  │
                │   ▲                                     │  │
                │   └──────── REFLECT ◄────────────────────┘  │
                │     (revise plan / self-critique / stop)   │
                └──────────────────────────────────────────┘
                          │ emits typed AgentEvent stream
                          ▼
        {plan_step, tool_call, tool_result, memory_read, memory_write,
         decision, confidence, needs_approval, message_delta, checkpoint, error}

• Model gateway (Section 4.4) selects the model per step (cheap model for routing/extraction, frontier model for planning/reasoning). Default frontier model: Claude Opus/Sonnet 4.x via the gateway; the platform is provider-agnostic by design.
• Planner decomposes the goal into a Plan (ordered/typed steps with success criteria). The plan is a first-class, editable object — the user can edit it mid-run (steerability).
• Reflection runs after each major step and at run end: self-critique against the step's success criterion, decide continue/revise/stop. Reflection output is surfaced (not hidden) in the trace.
• Tool use via MCP (4.5). Each call is typed, permission-checked, and (if policy requires) gated behind approval.
• Every transition emits an AgentEvent — the single protocol that powers streaming, the trace panel, audit logs, and replay.

4.1.2 Multi-agent

Two coordination topologies, chosen by task shape (not by default — multi-agent is opt-in because it costs latency and tokens):

• Orchestrator–worker (default for complex tasks): a lead agent decomposes and delegates to specialist sub-agents (researcher, coder, reviewer), each with its own context window and tools, results merged by the lead. Mirrors the proven pattern for breadth-heavy work.
• Blackboard/peer (for collaborative synthesis): agents read/write a shared scratch entity (the "blackboard" = a Thread/Doc) and converge; used for design panels, adversarial review, multi-perspective drafting.

Sub-agent runs are nested Threads under the parent run — so the UI renders a multi-agent run as an expandable tree, never an opaque blob. This is how we make multi-agent legible.

4.1.3 Orchestration & control plane

#4.2 RAG architecture (unified retrieval)

One retrieval system serves chat, search, knowledge base, research, and memory — the consolidation thesis applied to retrieval.

INGEST ─► NORMALIZE ─► CHUNK ─► EMBED ─► INDEX ─► RETRIEVE ─► RANK ─► RERANK ─► SYNTHESIZE

• Ingestion: connector-based (MCP servers) + uploads + native entities. Incremental sync with change-data-capture; per-source ACL capture so retrieval is permission-aware at query time (critical for enterprise — Glean's core moat).
• Normalize: to a common Chunkable doc model (text + structure + metadata + ACL + source pointer).
• Chunking: structure-aware (headings/code-blocks/table rows), ~512–1024 token target with overlap, plus a parent-document pointer for context expansion. Late-chunking for long docs where embedding-then-chunk preserves context.
• Embeddings: a primary dense embedding model (multilingual, ~1k–3k dims) + sparse (BM25/SPLADE) for hybrid. Embeddings versioned; re-embed pipeline on model upgrade.
• Index: hybrid — vector store (Turbopuffer/Qdrant/pgvector at small scale) for dense, OpenSearch for sparse/keyword + filters/ACL. Per-tenant namespacing.
• Retrieval: hybrid fusion (RRF) of dense + sparse, with ACL filter pushed into the query (never post-filter — that leaks counts).
• Rank → Rerank: first-stage fusion, then a cross-encoder reranker on top-k (~50→8), then optional LLM rerank for hard queries.
• Synthesize: answer with inline citations to source entities; every claim links back to a chunk + entity (the "Sources" panel in 5.3).

Freshness & cost: tiered — hot tenants' recent content in low-latency vector store; cold/archival in cheaper tiers; query planner decides depth (cheap lexical for navigational queries, full hybrid+rerank for questions).

#4.3 Memory architecture (six layers)

Memory is the compounding moat. Each layer has a distinct scope, lifecycle, and permission boundary. All writes carry provenance (who/what/when/why) and are surfaced and editable (Section 5.3) — memory you can't inspect or correct is a liability, not an asset.

• Structure: each layer = vector memory (semantic recall) + memory graph (entities + typed relations, for precise/queryable facts) + structured profile (key-values like preferences). Hybrid recall: graph for "who owns X," vector for "what was the vibe of the Q3 decision."
• Write policy: agents propose memory writes; significant/long-term writes can require confirmation; all writes are scoped and audited. No silent cross-scope leakage — User memory never enters a Workspace context without an explicit, logged consent action.
• Forgetting: TTL + decay + explicit user deletion (GDPR-aligned, Section 8.8). "Forget this" is a first-class action.
• Conflict resolution: newer + higher-provenance-confidence wins; conflicts surfaced to the user when material.

#4.4 Model gateway

A single internal service all agents call. Responsibilities: model routing (task→model by capability/latency/cost), prompt caching, structured-output/tool-call enforcement + retry on schema mismatch, streaming normalization to the AgentEvent protocol, per-tenant rate limits and budgets, fallback/failover across providers, and full request/response logging for eval and audit. Provider-agnostic: Claude (default frontier), plus others behind the same interface. This is also where we run safety classifiers and PII redaction in/out.

#4.5 Tool architecture (everything is an MCP server)

Decision: every integration — external SaaS and internal APIs — is exposed as an MCP server. This collapses the integration tax and makes the tool surface uniform for agents, the marketplace, and enterprise admins.

Agent ──(MCP)──► Tool Gateway ──► [ Gmail | Calendar | Slack | Notion | GitHub |
                                     Jira | Drive | Confluence | CRM | Internal APIs ]
                      │
                      ├─ OAuth/secret vault (per user + per org connections)
                      ├─ Per-tool scopes + policy engine (allow/deny/approve)
                      ├─ Rate limiting, retries, idempotency keys
                      ├─ Read vs write classification (writes default to approval)
                      └─ Full audit log of every tool invocation

• First-party connectors (launch set): Gmail, Google/Microsoft Calendar, Slack, Notion, GitHub, Jira, Google Drive, Confluence, Salesforce/HubSpot (CRM), Linear, plus a generic HTTP/OpenAPI and internal-API connector (enterprise registers an OpenAPI/MCP spec; we expose it as governed tools).
• Capability classification: every tool action is tagged read | write | destructive. Default policy: reads auto, writes require approval (configurable per workspace/agent), destructive always confirmed + undoable where possible.
• Marketplace tools (Section 11.5) are MCP servers vetted, sandboxed, and permission-scoped; enterprises can allowlist.

#5. UX Design — The Throughline

This is the section that determines whether Continuum is adopted. The mission: take probabilistic, agent-driven behavior and make it legible and steerable for non-technical users, while consolidating fragmented surfaces into one coherent experience. Everything below serves that sentence.

#5.0 The five interaction principles

1. Always show the work. The agent's plan, steps, tools, data, and confidence are visible by default (collapsible, never hidden). Opacity is the default failure mode of agent products; we invert it.
2. Graduated autonomy, not a binary. Five autonomy levels (5.4) with a single, learnable control — the user dials trust up/down per agent, per task, per workspace.
3. Steer mid-flight. The plan is editable, steps are interruptible, and the user can correct/redirect without restarting. Probabilistic systems need a steering wheel, not just a start button.
4. Reversibility over confirmation-spam. Prefer undo/checkpoint to modal nagging. Confirm only the irreversible.
5. One surface, many lenses. Switching from chat to doc to board to code never changes the navigation, search, identity, or memory. Consolidation is felt as continuity.

#5.1 Conversational experience

• Chat-first, artifact-aware. The thread is the spine; substantial outputs (a doc, a table, a plan, a diff, a research report) render as artifacts beside the thread (split view) rather than as walls of inline text. Artifacts are live entities (editable, addressable, versioned) — not chat bubbles.
• The composer is a command surface. Plain text → chat. @ → reference any entity/person/agent. / → invoke agents, tools, or lens actions. ⌘K → the universal command bar (search + navigate + act). One input, intent-routed.
• Turn model. Streaming with the AgentEvent protocol: message deltas interleaved with tool-call cards, plan updates, and approval prompts — so the user watches reasoning unfold rather than waiting for an opaque pause.
• Branching & checkpoints. Any message can branch a thread (explore alternatives); any agent run has checkpoints to rewind to (5.5).
• Voice & multimodal. Push-to-talk and continuous voice (low-latency streaming STT→agent→TTS), image/file input, screen/canvas sharing. Voice uses the same AgentEvent stream — the trace panel still shows what happened, so voice isn't a legibility black hole.

#5.2 Agent experience

• Creation (Agent Builder, Section 11.4): no-code first. Describe the agent in natural language → system drafts instructions, suggests tools and memory scopes → user refines via a structured form (persona, instructions, tools, knowledge, autonomy level, guardrails) → test in a sandbox thread with a visible trace → publish to user/workspace/marketplace. Power users drop to a config/code view (versioned, diffable).
• Management: an Agents space lists agents with their scope, recent runs, success/intervention rates, cost, and the tools they can touch. Every agent has a "passport" page: identity, capabilities, permissions, memory access, audit history.
• Collaboration: agents are first-class participants — @mention an agent in any thread; agents can be assigned Tasks; multi-agent runs render as an expandable tree. Human and agent collaborators share the same presence/assignment/notification model.

#5.3 Explainability (the legibility layer)

The right-hand Context panel is persistent and answers four questions for any agent action:

Provenance is everywhere: synthesized claims carry inline citations; memory used in a response is shown ("I'm using your stored preference for X") and editable on the spot.

#5.4 Trust — graduated autonomy

A single control, five levels, learnable once and consistent across all 20 surfaces:

L0 Manual      agent suggests; human does everything
L1 Assisted    agent drafts; human approves each step       ← default for new users/agents
L2 Supervised  agent acts; approval only for writes/destructive
L3 Trusted     agent acts; notifies, approval only for high-risk/irreversible
L4 Autonomous  agent acts within budget/policy; reports after  ← power users / proven agents

• Approval workflows: a needs_approval event pauses the durable run and surfaces an inline approval card (what it wants to do, why, the diff/effect, confidence). Approvals can be delegated, batched, and policy-driven (auto-approve under $X, in this workspace, for this tool).
• Confidence indicators: every consequential action carries a calibrated confidence signal (model logprob/self-eval + retrieval coverage + tool reliability), shown as a chip; low confidence auto-escalates the approval level.
• Human review: any output can be routed to a reviewer (human or a reviewer-agent) before it takes effect; review state is part of the Task/Thread.
• Error recovery: failures are typed and surfaced with a remediation path (retry, edit-and-retry, escalate, abandon); the agent proposes a fix rather than dead-ending.
• Undo: durable checkpoints make agent runs rewindable; reversible tool actions (drafts, file edits, task changes) get one-click undo; irreversible actions (send email, delete) are the only hard-gated ones. This is the principle "reversibility over confirmation-spam" made concrete.

#5.5 Onboarding (first-run → activation)

Onboarding is where the legibility/steerability promise is taught, not just stated.

• First-run (consumer): start in chat within 10 seconds (no setup wall). The first real task demonstrates the trace panel and an approval gate, so the user learns the model by doing. Progressive disclosure: surfaces (projects, agents, automations) reveal as the user's needs grow, never dumped up front.
• Connect-to-activate: the highest-leverage onboarding step is the first connector (Gmail/Calendar/Drive). The moment the assistant uses the user's own data legibly (with sources shown), retention inflects. We instrument time-to-first-connector and time-to-first-agent-run as the core activation metrics.
• Daily flow: Home = a unified, agent-curated briefing (what needs you: approvals, mentions, due tasks, automation results) — the consolidation thesis as a daily habit.
• Power-user flow: keyboard-driven (⌘K everything), saved agents, automations, multi-workspace, branching.
• Enterprise flow: admin sets SSO/SCIM, connects org sources, configures policies and default autonomy ceilings, then rolls out workspaces by team with templates (Section 11.15).

Full first-time / daily / power / enterprise journeys are given per-product in Section 11; the patterns above are the shared spine.

#6. Design System ("Substrate")

#6.1 Design principles

1. Legible by default — show the work; opacity is opt-in.
2. Calm — agentic systems generate a lot of motion and events; the UI's job is to reduce anxiety. Restraint, generous whitespace, muted palette, motion only when it conveys state.
3. Continuous — one navigation, one identity, one search across lenses. No surface feels like a different app.
4. Fast — perceived latency is a feature; optimistic UI, streaming, skeletons keyed to real content.
5. Trustworthy — provenance, confidence, and reversibility are visual primitives, not afterthoughts.
6. Accessible — WCAG 2.2 AA is the floor, not a retrofit.

#6.2 Tokens

• Typography: Inter (UI) + a humanist mono (code/traces, e.g. Berkeley Mono / JetBrains Mono). Type scale (rem): 0.75 / 0.875 / 1 / 1.125 / 1.25 / 1.5 / 1.875 / 2.25. Line-height 1.5 body, 1.2 headings. Two weights in product (regular/medium) + semibold for emphasis.
• Spacing: 4px base; scale 0,1,2,3,4,6,8,12,16,24,32,48,64. Tailwind default scale aligns.
• Color: semantic tokens, not raw hues. Neutrals (12-step gray ramp) carry 90% of the UI. One brand accent. Functional: success / warning / danger / info. Agent-state colors are a deliberate sub-palette: thinking, acting, awaiting-approval, done, error — consistent everywhere an agent appears. Full light + dark themes from the same token set (CSS variables).
• Elevation: 4 levels via shadow + border; flat-leaning. Radius: 6/8/12px scale. Motion: durations 100/150/200/300ms; easing cubic-bezier(0.2,0,0,1) (entrance), standard for exit; respect prefers-reduced-motion. Motion is used to encode state transitions of agents (thinking→acting→done), not decoration.

#6.3 Accessibility

WCAG 2.2 AA: full keyboard operability (every action reachable without mouse; ⌘K as the keyboard backbone), focus-visible rings, ARIA live regions for streaming agent output (so screen-reader users get the trace too), 4.5:1 contrast minimum, motion-reduction, target sizes ≥24px. Streaming + live agent activity is the hardest a11y problem — solved with polite live-regions + a static, navigable trace as the source of truth.

#6.4 Component inventory

Primitives: Button (primary/secondary/ghost/danger + icon), Input/Textarea/AutoGrow, Select/Combobox, Checkbox/Radio/Switch, Slider (autonomy dial), Tabs, Tooltip, Popover, Dialog/Sheet/Drawer, Toast, Badge/Chip, Avatar (user + agent variants), Skeleton, Menu/ContextMenu, DatePicker, FileDrop, EmptyState, Pagination, Breadcrumb, Resizable panels.

Data: Table (virtualized, sortable, grouped — powers Airtable-lens), DataGrid (editable cells), Kanban Board, Timeline/Gantt, Tree, List (virtualized), Calendar, Chart set (analytics).

Chat: Thread, Message (user/agent/tool/system variants), Composer (with @///⌘K), StreamingText, ArtifactCard, CodeBlock (+diff), CitationInline + SourcePopover, BranchControl, VoiceBar.

Agent / trust (the differentiated set): TracePanel, PlanStep, ToolCallCard (read/write/destructive variants), DecisionChip + WhyPopover, ConfidenceChip, ApprovalCard, AutonomyDial, AgentPassport, AgentTree (multi-agent), MemoryChip + MemoryEditor, UndoControl, RunCheckpointRail.

Workspace / nav: AccountSwitcher, WorkspaceSwitcher, Rail, SpaceNav, CommandBar (⌘K), ContextPanel, NotificationInbox, PresenceStack, SearchResults (typed/grouped + answer synthesis), ShareSheet/PermissionEditor, ConnectorCard.

Document/canvas: RichTextEditor (CRDT), Canvas (freeform/whiteboard), TableBlock, Mention, Comment/Thread-on-selection, VersionHistory.

Delivered as a headless-core + Tailwind-skin library (Section 7), Storybook-documented, with visual regression tests.

#7. Frontend Architecture

Stack: Next.js 15 (App Router, RSC) · React 19 · TypeScript (strict) · Tailwind v4 · Turborepo + pnpm.

#7.1 Why these choices

• Next.js App Router + RSC: server-render the IA shell and read-heavy lenses (fast first paint, SEO for marketing/shared docs), stream the rest. Server Components keep the client bundle lean despite 20 surfaces.
• Tailwind v4: token-driven (CSS variables = our design tokens), zero-runtime, consistent across a large team. Components are headless-core + Tailwind-skin so behavior and style evolve independently.
• TypeScript strict + end-to-end types: the AgentEvent protocol, entity schemas, and API contracts are shared types from a single package — the same zod schema validates at the API boundary and types the client.

#7.2 State management (four kinds, kept separate)

Key idea: the agent trace, the chat, and the audit log are all projections of the same append-only AgentEvent log. The client holds the log; lenses render views of it. This is the front-end embodiment of "show the work."

#7.3 Routing

App Router, segment per lens, identity in the path so multi-account is shareable and the rail is always oriented:

/(marketing)                      public site, shared/published docs
/(app)
  /[account]                      personal | org slug  ← multi-account root
    /[workspace]
      /home                       unified briefing
      /chat/[threadId]
      /projects/[projectId]/(doc|board|timeline)/[entityId]
      /agents/[agentId]           passport / runs / edit
      /knowledge/[kbId]
      /tasks
      /automations/[automationId]
      /search?q=
      /settings/(profile|members|connectors|billing|admin)
  /admin                          enterprise console (org-scoped)

#7.4 Performance strategy

RSC for shell + data-heavy lenses; route-level code-splitting per lens (a consumer never downloads the admin console); virtualization for all long lists/tables/threads; streaming SSR with Suspense; optimistic mutations everywhere; prefetch on intent (hover/focus); image/asset optimization via the CDN; bundle budgets enforced in CI. Target: interactive shell < 1.5s on warm cache, first token < 500ms, p95 lens-switch < 150ms.

#7.5 Caching & offline

• Caching: RSC cache + TanStack Query persistence + HTTP cache headers; entity-level cache keyed by entityId@version.
• Offline: PWA + service worker for the shell and recently-viewed entities; local-first for docs via Yjs with IndexedDB persistence and sync-on-reconnect. Chat composer queues offline and sends on reconnect. (Full offline agent execution is out of scope — agents need the backend.)

#7.6 Monorepo structure

continuum/
├── apps/
│   ├── web/                  # Next.js client (the unified app)
│   ├── marketing/            # public site
│   ├── desktop/              # Tauri/Electron wrapper (deep OS integration, global ⌘K)
│   ├── mobile/               # Expo / React Native
│   └── admin/                # enterprise console (can be a route group in web; separate for blast-radius)
├── packages/
│   ├── ui/                   # headless-core + Tailwind component library + Storybook
│   ├── design-tokens/        # the token source (→ CSS vars + TS)
│   ├── agent-protocol/       # AgentEvent types, zod schemas, event reducer
│   ├── api-client/           # tRPC/typed client + TanStack Query hooks
│   ├── entities/             # shared entity schemas (zod) + types
│   ├── editor/               # Yjs-based rich text + canvas
│   ├── search/               # search UI + client logic
│   ├── feature-chat/         # feature module (slice)
│   ├── feature-projects/
│   ├── feature-agents/
│   ├── feature-automations/
│   ├── feature-knowledge/
│   └── config/               # eslint, ts, tailwind presets
├── services/                 # backend (Section 8) — co-located for shared types
└── turbo.json / pnpm-workspace.yaml

Feature-module pattern: each lens is a feature-* package exporting routes, components, hooks, and its slice of the AgentEvent reducer — so the substrate stays shared while lenses ship independently. This is the code-level expression of "one product, twenty surfaces."

#8. Backend Architecture

#8.1 Topology

A modular service mesh, not a distributed-monolith-by-accident. Web talks to a BFF (tRPC) which fans out to internal services over gRPC; public access via a REST + webhooks gateway; an event backbone (Kafka) connects everything asynchronously.

            ┌──────────── Edge (CDN, WAF, API GW) ────────────┐
Clients ───►│ tRPC BFF (web)   REST/Webhooks (public)   WS/SSE │
            └───────┬───────────────┬───────────────────┬─────┘
                    ▼               ▼                   ▼
   ┌───────────────────────── gRPC service mesh ─────────────────────┐
   │ identity │ workspace │ thread │ agent-runtime │ memory │ search  │
   │ tools/connectors │ automation │ document/collab │ notification   │
   │ billing │ admin/policy │ analytics-ingest │ model-gateway        │
   └───────────────────────────────┬─────────────────────────────────┘
                                    ▼
        Kafka (events) · Temporal (durable workflows) · Redis (cache/pubsub)
                                    ▼
   Postgres · pgvector/Qdrant · OpenSearch · ClickHouse · S3 · object/secret vault

#8.2 Services (responsibilities)

• identity — users, auth (WorkOS for SSO/SCIM), sessions, multi-account.
• workspace — orgs/workspaces/teams/projects, membership, the permission tree.
• thread — threads/messages, the AgentEvent log (append-only, source of truth).
• agent-runtime (Python + Temporal) — the plan/act/reflect loop, multi-agent orchestration.
• memory — the six layers; read/write with provenance + scope enforcement.
• search — ingestion pipeline + hybrid retrieval + rerank.
• tools/connectors — MCP gateway, OAuth vault, policy engine, audit.
• automation — trigger/condition/action graphs, scheduling.
• document/collab — Yjs sync server, version history.
• notification — unified event → inbox/push/email fan-out.
• model-gateway — routing/caching/budgets/failover (Section 4.4).
• billing, admin/policy, analytics-ingest — as named.

#8.3 APIs

• tRPC for the web app (end-to-end types, fastest iteration).
• Public REST API (OpenAPI-described) + webhooks for developer ecosystem & enterprise integration.
• gRPC internal (typed, fast, streaming).
• MCP as the tool interface — and we also publish Continuum's own capabilities as MCP servers, so other agents can call Continuum.
• WebSocket/SSE for streaming (AgentEvent) and presence.

#8.4 Events & queues

Kafka as the backbone (entity-change events, agent events, audit, analytics). Temporal for durable, long-running work (agent runs, automations, ingestion) — chosen over a bare queue because agent runs need checkpointing, retries, signals (approvals), and replay (undo). Redis for low-latency pub/sub (presence, live cursors) and caching.

#8.5 Observability & monitoring

OpenTelemetry traces across the mesh (a single agent run is one distributed trace); Prometheus/Grafana metrics; structured logs to a central store; LLM-specific observability — every model call logged with prompt/version/tokens/cost/latency/tool-calls, feeding an eval harness and cost dashboards. Per-tenant SLOs; error budgets; PagerDuty alerting. Agent-run replay is both a user feature (undo) and an ops/debug tool.

#8.6 Security

Defense in depth: TLS everywhere; secrets in a vault (per-user + per-org connector creds encrypted with envelope encryption); per-tenant data isolation (row-level security in Postgres + namespaced indexes); least-privilege service identities; the tool policy engine gates every external action; prompt-injection defenses (input/output classifiers in the model gateway, tool-call allowlists, untrusted-content sandboxing in retrieval). SSO/SAML/OIDC + SCIM provisioning. Pen-tested; bug bounty.

#8.7 Permissions model

A unified RBAC + ABAC system, evaluated centrally and cached at the edge:

• Subjects: user, team, agent (agents are first-class subjects — an agent has permissions, separate from the user who invoked it).
• Objects: any entity.
• Roles: owner/admin/editor/commenter/viewer at org/workspace/project, plus custom enterprise roles.
• Policies (ABAC): attribute rules (e.g., "agents may not send external email in the Legal workspace," "auto-approve writes under $50"). The same engine enforces retrieval ACLs (Section 4.2) and tool gates (4.5) — one model, every surface.

#8.8 Compliance

• SOC 2 Type II — controls from day one (access logging, change management, audit), audited ~year one.
• GDPR/CCPA — data residency options, DSAR/export/delete (memory "forget" wired to this), DPA, sub-processor list, consent for cross-scope memory.
• HIPAA readiness — BAA path, PHI tagging, encryption at rest/in transit, audit logging, the ability to disable model-training/retention per workspace; HIPAA-eligible deployment tier.
• Enterprise controls: customer-managed keys (CMK/BYOK), no-training guarantees, data-retention controls, full audit log of every agent action and tool call (Section 9), eDiscovery export.

#9. Database Design

Primary store: PostgreSQL (Aurora/Citus for horizontal scale), with row-level security per tenant. Specialized stores alongside: pgvector/Qdrant (vectors), OpenSearch (lexical/search), ClickHouse (analytics/events), Redis (cache/ephemeral), S3 (blobs).

#9.1 Core schemas (abbreviated DDL)

-- Identity & tenancy
users(id pk, email uniq, name, avatar_url, created_at)
organizations(id pk, slug uniq, name, sso_domain, plan, compliance_tier, created_at)
memberships(id pk, user_id fk, org_id fk, status, created_at,
            UNIQUE(user_id, org_id))                       -- user↔org many-to-many
teams(id pk, org_id fk, name, created_at)
team_members(team_id fk, user_id fk, PRIMARY KEY(team_id,user_id))

workspaces(id pk, org_id fk NULL, owner_user_id fk NULL,   -- personal ws => owner_user_id set
           name, kind, settings jsonb, created_at)
projects(id pk, workspace_id fk, name, status, archived_at, created_at)

-- Roles / permissions (unified RBAC+ABAC)
role_grants(id pk, subject_type, subject_id,               -- subject_type ∈ user|team|agent
            object_type, object_id, role, created_at,
            UNIQUE(subject_type,subject_id,object_type,object_id))
policies(id pk, scope_type, scope_id, rule jsonb,          -- ABAC rules
         priority, created_at)

-- Content
documents(id pk, project_id fk NULL, workspace_id fk, title,
          type, yjs_state bytea, current_version, created_by, updated_at)
document_versions(id pk, document_id fk, version, snapshot bytea, author_id, created_at)

threads(id pk, workspace_id fk, project_id fk NULL,
        kind, title, created_by, created_at)               -- kind ∈ conversation|agent_run|task_activity|meeting
messages(id pk, thread_id fk, role, author_id NULL, agent_id NULL,
         content jsonb, parent_message_id fk NULL,         -- parent => branching
         created_at)
agent_events(id pk, thread_id fk, run_id, seq, type,        -- the append-only legibility log
             payload jsonb, created_at)                     -- type ∈ plan_step|tool_call|...

-- Agents
agents(id pk, scope_type, scope_id, name, instructions,
       model, tools jsonb, memory_scopes jsonb,
       autonomy_level int, guardrails jsonb, version, created_by, created_at)
agent_runs(id pk, agent_id fk, thread_id fk, workflow_id,   -- workflow_id => Temporal
           status, cost_tokens, cost_usd, started_at, ended_at)

-- Tasks & automations
tasks(id pk, project_id fk, title, status, assignee_type,   -- assignee_type ∈ user|agent
      assignee_id, priority, due_at, created_at)
automations(id pk, workspace_id fk, trigger jsonb,
            graph jsonb, enabled bool, created_by, created_at)
automation_runs(id pk, automation_id fk, status, started_at, ended_at, log jsonb)

-- Memory
memories(id pk, scope_type, scope_id,                       -- scope_type ∈ session|conversation|user|workspace|team|org
         kind, content text, embedding vector(1536),
         provenance jsonb, confidence real,
         expires_at NULL, created_at)
memory_edges(src_memory_id fk, dst_memory_id fk, relation,  -- the memory graph
             PRIMARY KEY(src_memory_id,dst_memory_id,relation))

-- Knowledge / connectors / search
knowledge_bases(id pk, workspace_id fk, name, created_at)
connectors(id pk, workspace_id fk NULL, user_id fk NULL,    -- per-org and per-user connections
           provider, status, scopes jsonb, secret_ref, created_at)
chunks(id pk, source_entity_type, source_entity_id,
       text, embedding vector(1536), acl jsonb, metadata jsonb)  -- ACL pushed into retrieval

-- Notifications & audit
notifications(id pk, user_id fk, type, entity_ref jsonb,
              read_at NULL, created_at)
audit_logs(id pk, org_id fk, actor_type, actor_id,          -- actor_type ∈ user|agent|system
           action, object_ref jsonb, tool, result,
           metadata jsonb, created_at)                       -- immutable, append-only

#9.2 Indexes & scaling

• Tenant-first composite indexes on every hot table: (workspace_id, …) / (org_id, …) so queries are tenant-pruned and RLS is cheap.
• Threads/messages: (thread_id, created_at), (thread_id, parent_message_id) for branch trees. agent_events (run_id, seq) for ordered replay.
• Search/memory: HNSW indexes on embedding; partial indexes by scope_type; OpenSearch mirrors chunks for BM25; ACL stored on the chunk and filtered in-query.
• Audit/analytics: audit_logs and agent_events time-partitioned; analytics mirrored to ClickHouse (append-only, columnar) so reporting never touches OLTP.
• Sharding strategy: shard by org_id (tenant) once a single Postgres cluster is saturated — Citus distributed tables keyed on tenant; large enterprises can get a dedicated shard/cluster (and the HIPAA tier gets isolated infra). Vector and search indexes namespaced per tenant from day one so the move to per-tenant isolation is a config change, not a migration.
• Hot/cold tiering: recent threads/memories in Postgres + hot vector store; archival to cheaper storage with on-demand rehydrate.

#10. Infrastructure

#10.1 Cloud & runtime

• Kubernetes (EKS/GKE), multi-AZ per region, multi-region active-active for the stateless tier; stateful tier (Postgres, Kafka) per-region primary with cross-region replicas.
• Service mesh (Linkerd/Istio) for mTLS, retries, traffic shaping.
• Containers built reproducibly (distroless base), signed, scanned.
• Edge: Cloudflare/Fastly CDN + WAF; static/RSC payloads at the edge; regional API ingress nearest the user; agent compute pinned to the tenant's data region.

#10.2 CI/CD

GitHub Actions (build/test/lint/typecheck/visual-regression/eval-harness) → container registry → Argo CD GitOps (declarative deploys) with progressive delivery (canary + automated rollback on SLO breach). Terraform for all infra (IaC, reviewed like code). Preview environments per PR (ephemeral namespaces) so designers/PMs review real builds.

#10.3 Scale & global deployment

• Target: 100M+ users, millions of concurrent conversations/agent runs.
• Stateless tier (BFF, gateways, web) autoscales horizontally on CPU + queue depth; agent-runtime scales on Temporal task-queue depth with per-tenant fairness so one heavy org can't starve others.
• Model gateway is the cost/throughput chokepoint: prompt caching, batching, model-tiered routing, and provider failover keep latency and spend bounded.
• Multi-region routing by user geography + data-residency policy (EU data stays in EU). Tenants pin a home region; enterprise can require single-region.

#10.4 Reliability & DR

SLOs: 99.9% (consumer) / 99.95% (enterprise) API availability; first-token p95 < 500ms; lens-switch p95 < 150ms. DR: continuous Postgres PITR + cross-region replicas; Kafka mirrored; RPO ≤ 5 min, RTO ≤ 30 min; quarterly failover game-days. Per-tenant rate limits and circuit breakers contain blast radius. Agent runs are durable (Temporal) — a regional failover resumes in-flight runs rather than losing them.

#11. The Twenty Products

#11.0 The nine canonical personas (defined once, referenced throughout)

Below, each product names its primary personas by these IDs. The four journey archetypes (first-time / daily / power / enterprise) are given compactly; the shared spine is Section 5.5.

#Product 1 — Consumer AI Assistant

• Vision. The default place a person thinks, asks, and gets things done — chat-first, connected to their real life (mail, calendar, files), with every action legible. Problem: today's consumer AI is a stateless answer box disconnected from the user's data and tools. Differentiation: memory + connectors + legibility + the fact that it grows into a full OS as needs expand. Market: the consumer-AI TAM (hundreds of millions); land surface for everything else.
• Primary personas: P1, P2, P8.
• Journeys. First-time: chat in <10s → first connector (Gmail) → assistant uses your data with sources shown. Daily: morning briefing on Home; ad-hoc questions; draft/replies with approval. Power: saved agents, automations, voice, multi-workspace. Enterprise: upgrades into the Enterprise Assistant (Product 2) under org policy.
• Features. MVP: chat, streaming + trace, memory (user layer), 3 connectors, voice input, mobile. V2: artifacts (docs/tables), automations, image/multimodal. V3: proactive agent (suggests before asked), full connector suite. Long-term: ambient/always-on personal OS across devices.

#Product 2 — Enterprise AI Assistant

• Vision. The Consumer Assistant under governance: grounded in company knowledge, permission-aware, audited. Problem: employees paste company data into ungoverned consumer AI (shadow AI). Differentiation: permission-aware retrieval (Glean-grade) + agentic action + full audit, in the same UI employees already like. Market: every knowledge-work enterprise.
• Primary personas: P5, P7, P9 (+ all employees).
• Journeys. First-time: SSO login → sees org knowledge already searchable. Daily: "what's the status of X," "draft the customer reply per our policy," with sources from internal systems. Power: builds team agents/automations. Enterprise: admin governs scopes, autonomy ceilings, audit.
• Features. MVP: SSO/SCIM, permission-aware search over connectors, audited tool use, no-train guarantee. V2: workspace/team memory, approval policies, eDiscovery export. V3: department agent templates, analytics. Long-term: the org's institutional brain.

#Product 3 — Multi-Agent Platform

• Vision. Coordinate teams of agents on long-horizon work, rendered legibly as an expandable tree. Problem: real work needs decomposition + specialists + review; single-agent chat can't sustain it. Differentiation: durable orchestration (Temporal) + the legibility tree + human approval woven into the run. Market: power users → enterprises automating workflows.
• Primary personas: P3, P4, P8, P5.
• Journeys. First-time: pick a template ("research + draft + review"), watch the orchestrator delegate. Daily: kick off runs, approve gates, harvest outputs. Power: design custom topologies. Enterprise: governed agent teams with budgets/audit.
• Features. MVP: orchestrator-worker, nested-thread tree UI, budgets, approvals. V2: blackboard/peer topology, agent-to-agent messaging, scheduled runs. V3: self-improving plans, learned routing. Long-term: autonomous departments under human oversight.

#Product 4 — Agent Builder

• Vision. Anyone builds a reliable agent in minutes; experts go deep. Problem: building agents today means code + glue + eval no one has. Differentiation: natural-language-first → structured config → sandbox-with-visible-trace → publish; versioned and evaluable. Market: prosumers, internal tooling teams, marketplace creators.
• Primary personas: P4, P5, P8, P6.
• Journeys. First-time: describe agent in English → system scaffolds instructions/tools/memory → test in sandbox. Daily: iterate from real runs (turn a good run into a saved agent). Power: config/code view, eval sets, A/B. Enterprise: governed publishing, required reviews.
• Features. MVP: NL→config, tool/memory pickers, sandbox trace, versioning. V2: eval harness, templates, sharing. V3: auto-optimization from run feedback, guardrail library. Long-term: agents that build/refine agents.

#Product 5 — Agent Marketplace

• Vision. The app store for agents and tools (MCP servers). Problem: agent capability is locked in silos; no trusted distribution. Differentiation: agents share Continuum's substrate (memory/permissions/legibility) so installed agents are governable, not black boxes; revenue share for creators. Market: two-sided — creators + every Continuum user/org.
• Primary personas: P4, P8, P9 (admin allowlisting).
• Journeys. First-time: browse → install an agent → it runs with visible permissions. Daily: discover via in-context suggestions. Power: publish + monetize. Enterprise: private org marketplace + allowlist + security review.
• Features. MVP: listings, install with scoped permissions, ratings. V2: paid agents, revenue share, private catalogs. V3: certified/vetted tier, usage analytics for creators. Long-term: the default distribution channel for AI capabilities.

#Product 6 — AI Memory System

• Vision. A unified, inspectable, editable memory across all of a user's/team's work. Problem: AI forgets; or remembers opaquely and leaks. Differentiation: six explicit scopes, full provenance, user-editable, "forget" as first-class, no silent cross-scope leakage (Section 4.3). Market: the substrate under every other product; also a standalone trust differentiator.
• Primary personas: all (esp. P1, P7, P9).
• Journeys. First-time: assistant says "I'll remember X" — visible, confirmable. Daily: memory used is shown inline and correctable. Power: curate workspace/team memory. Enterprise: admin governs scopes, retention, export/delete.
• Features. MVP: user + conversation memory, provenance, edit/forget. V2: workspace/team memory, memory graph UI. V3: conflict resolution, decay/TTL controls, suggestions. Long-term: the org's queryable institutional memory.

#Product 7 — AI Knowledge Base

• Vision. Governed, living knowledge that agents and people share. Problem: wikis rot; knowledge is fragmented and stale. Differentiation: agent-maintained (proposes updates from activity), permission-aware, the same retrieval that powers search/chat. Market: teams and enterprises.
• Primary personas: P5, P7, P9, P3.
• Journeys. First-time: connect sources + import docs → instantly queryable. Daily: ask the KB; agents cite it. Power: curate canonical entries, set ownership. Enterprise: governance, freshness SLAs, audit.
• Features. MVP: ingest + hybrid search + cited answers. V2: agent-proposed updates, ownership/freshness, glossary. V3: auto-structured knowledge graph, staleness detection. Long-term: self-maintaining knowledge.

#Product 8 — Enterprise Search Engine

• Vision. One search across every system an employee can access — permission-aware, with synthesized cited answers. Problem: enterprise knowledge is scattered across 40+ apps; people can't find anything. Differentiation: ACL-at-query-time retrieval + answer synthesis + action ("not just find it — do something with it"). Market: the Glean wedge into the enterprise.
• Primary personas: all employees; P9 governs.
• Journeys. First-time: search returns results from Drive/Slack/Jira respecting your permissions. Daily: question → cited answer + jump-to-source. Power: search-driven workflows. Enterprise: connector governance, audit, analytics on knowledge gaps.
• Features. MVP: hybrid search + ACL + answer synthesis over launch connectors. V2: personalized ranking, verticals (people/code/tickets). V3: proactive surfacing, gap analytics. Long-term: the enterprise's front door to all knowledge.

#Product 9 — AI Research Assistant

• Vision. Perplexity-grade web research + deep multi-step inquiry with full provenance and reproducibility. Problem: research is slow, sources are unverifiable, depth is shallow. Differentiation: multi-agent deep research + adversarial verification + cited, reproducible reports as live artifacts. Market: students, researchers, analysts, knowledge workers.
• Primary personas: P2, P3, P5, P7.
• Journeys. First-time: ask a question → fast cited answer; "go deeper" → a researched report. Daily: research tasks producing artifacts. Power: configure depth, sources, verification rigor. Enterprise: research over internal + external sources, governed.
• Features. MVP: web search + cited synthesis, follow-ups. V2: deep multi-agent research → report artifact, source verification. V3: reproducible runs, custom source sets, scheduled monitoring. Long-term: a tireless research department.

#Product 10 — AI Coding Assistant

• Vision. Cursor/Devin-class coding inside the OS — connected to the team's knowledge, tasks, and review. Problem: coding AI is disconnected from project context (specs, tickets, decisions). Differentiation: code agent shares the substrate (the task, the KB, the thread) and renders work as legible diffs with tests + reversibility. Market: every engineering team.
• Primary personas: P4 (+ P8 at small co's).
• Journeys. First-time: connect repo → ask for a change → review a diff with tests. Daily: delegate tickets to the code agent; review PRs. Power: background agents on long tasks, multi-file refactors. Enterprise: governed repo access, mandatory review, audit.
• Features. MVP: repo connector, diff-based edits, run/test, PR creation. V2: background long-horizon tasks, ticket→PR, codebase Q&A. V3: multi-agent (plan/code/review), test generation, migrations. Long-term: autonomous engineering under human review.

#Product 11 — AI Project Management Platform

• Vision. Linear-grade PM where agents are assignees, not just suggesters. Problem: PM tools track work but don't do it; AI is bolted-on summaries. Differentiation: tasks assignable to agents, status that maintains itself, the board is a lens over the same threads/tasks as everything else. Market: startups → enterprises.
• Primary personas: P5, P8, P4, P7.
• Journeys. First-time: describe a project → agent scaffolds tasks/milestones. Daily: board/timeline; agents progress assigned tasks; auto status. Power: automations from triggers, dependency graphs. Enterprise: portfolio rollups, governance.
• Features. MVP: projects/tasks/board/timeline, agent assignees, auto-status. V2: dependencies, sprints, automations, reports. V3: predictive (risk/ETA), agent-run delivery. Long-term: self-managing projects with human steering.

#Product 12 — AI Workflow Automation Platform

• Vision. Zapier/n8n power with agentic intelligence and a legible, steerable builder. Problem: automations are brittle, deterministic, and break on edge cases; agentic ones are opaque. Differentiation: trigger→condition→action graphs where any node can be an agent (handles ambiguity), with run traces, approvals, and undo. Market: ops, RevOps, every team with toil.
• Primary personas: P5, P8, P9, P4.
• Journeys. First-time: describe automation in English → graph generated → test with a visible run. Daily: automations run; approvals as needed; failures surfaced with fixes. Power: complex graphs, branching, agent nodes. Enterprise: governed, audited, with cost ceilings.
• Features. MVP: triggers (event/schedule/manual), action nodes over connectors, run logs. V2: agent nodes, conditionals/branching, error handling + retries. V3: NL→workflow, self-healing, marketplace templates. Long-term: the autonomic nervous system of the org.

#Product 13 — Team Collaboration Platform

• Vision. Slack-class real-time collaboration where threads, docs, tasks, and agents live in one place — no app-switching. Problem: chat (Slack) is severed from work (docs/tasks/code), so context is lost across tools. Differentiation: a "conversation" and a "project thread" and an "agent run" are the same primitive — collaboration is continuous with the work. Market: all teams.
• Primary personas: P5, P6, P4, P8.
• Journeys. First-time: a workspace with channels = threads; @mention people and agents alike. Daily: discuss, decide, spin work out of the conversation. Power: threads branch into projects/docs. Enterprise: governed channels, retention, audit.
• Features. MVP: channels/threads, presence, mentions (human+agent), files. V2: huddles/voice, thread→task/doc, agent participants. V3: auto-summary/decisions-captured-to-memory. Long-term: collaboration where AI is a teammate by default.

#Product 14 — Workspace Management Platform (multi-account / workspace org)

• Vision. Effortless organization of identities, workspaces, and context — the connective tissue that makes "one product, many surfaces" feel coherent. Problem: people juggle personal + multiple org accounts and lose track of which hat they're wearing and what's shared. Differentiation: one identity, N accounts, instant switching, always-clear context (who am I acting as, what's visible), with clean separation of personal vs org data. Market: everyone — but it's the interaction-model core (your role).
• Primary personas: all; P9 governs org side.
• Journeys. First-time: sign up personal → join/create org → see both as switchable accounts. Daily: switch account/workspace via rail or ⌘K; context (memory, search, notifications) re-scopes correctly and visibly. Power: multiple orgs, cross-workspace teams, saved contexts. Enterprise: admin provisions workspaces, templates, defaults.
• Features. MVP: multi-account switcher, workspace CRUD, clear active-context indicator, personal/org data isolation. V2: workspace templates, team-based provisioning, cross-workspace search scoping. V3: smart context suggestions, guest/external access. Long-term: fluid identity across the consumer↔work boundary without leakage.

#Product 15 — Enterprise Administration Console

• Vision. One console to govern identity, access, policy, cost, compliance, and audit across the org. Problem: AI sprawl is ungovernable; admins lack visibility and control. Differentiation: because every action flows through one substrate, admins get complete audit and enforceable policy over agents and tools — impossible in a multi-tool stack. Market: IT/security buyers (the economic buyer for enterprise).
• Primary personas: P9, P7.
• Journeys. First-time: connect SSO/SCIM, set org policies + autonomy ceilings, connect sources. Daily: review audit, approvals, spend, security alerts. Power: custom roles, fine-grained ABAC policies. Enterprise: compliance reporting, eDiscovery, BYOK.
• Features. MVP: SSO/SCIM, roles, connector governance, audit log, no-train controls. V2: ABAC policy engine, cost dashboards/budgets, autonomy ceilings. V3: anomaly detection, compliance packs (SOC2/GDPR/HIPAA), DLP. Long-term: autonomous governance with policy-as-code.

#Product 16 — Analytics Platform

• Vision. Insight into work, knowledge, agents, and cost — for individuals up to the C-suite. Problem: orgs can't see how AI is used, what it costs, or where knowledge gaps are. Differentiation: analytics over the unified event stream (every action is a typed event) → unprecedented visibility; powered by ClickHouse. Market: PMs, execs, admins.
• Primary personas: P7, P9, P5.
• Journeys. First-time: dashboards auto-populate from activity. Daily: check adoption, agent ROI, spend. Power: custom queries/explorations. Enterprise: org-wide rollups, exports, alerts.
• Features. MVP: usage/adoption, agent run stats, cost. V2: knowledge-gap analytics, custom dashboards, ROI attribution. V3: predictive insights, NL→analytics query. Long-term: the org's decision cockpit.

#Product 17 — Document Platform

• Vision. Notion-grade docs/canvas/tables that are live entities AI reads and writes legibly. Problem: docs are dead text disconnected from work and AI. Differentiation: CRDT multiplayer + AI as a transparent co-author (suggests with visible reasoning, you accept/steer) + docs are first-class memory/search entities. Market: all knowledge workers.
• Primary personas: P6, P5, P3, P2.
• Journeys. First-time: open a doc, write with an AI co-author whose edits are reviewable. Daily: docs/tables/canvas; AI drafts/transforms with accept/reject. Power: databases (Airtable-lens), templates, embeds. Enterprise: governed, versioned, audited.
• Features. MVP: rich text + tables + real-time collab + AI co-author (diff-style suggestions). V2: canvas/whiteboard, databases/views, comments. V3: AI doc generation from threads/tasks, structured-data agents. Long-term: documents that maintain themselves.

#Product 18 — Meeting Assistant

• Vision. Capture, understand, and act on meetings — feeding the same memory and tasks as everything else. Problem: meeting tools transcribe but don't connect outcomes to the work. Differentiation: transcripts/decisions/action-items flow into memory, tasks, and threads automatically and legibly; agents execute follow-ups. Market: all teams.
• Primary personas: P5, P7, P8, P6.
• Journeys. First-time: join a meeting → live notes + action items captured. Daily: post-meeting summary → tasks created → follow-up agents kick off. Power: meeting agents that prep briefs from memory beforehand. Enterprise: governed recording, retention, audit.
• Features. MVP: transcription, summary, action-item extraction → tasks. V2: live agent in-meeting, pre-meeting briefs from memory, calendar integration. V3: decisions-to-knowledge, cross-meeting intelligence. Long-term: meetings that schedule and execute their own outcomes.

#Product 19 — Personal Productivity Assistant

• Vision. A proactive personal chief-of-staff: inbox, calendar, tasks, and life admin handled with oversight. Problem: individuals drown in coordination toil. Differentiation: proactive (acts before asked, within autonomy levels) across the user's connected life, fully legible and reversible. Market: consumers + busy professionals (overlaps Product 1, but here the emphasis is proactivity + life-ops).
• Primary personas: P1, P7, P8.
• Journeys. First-time: connect mail/calendar → "I can triage your inbox and prep your day — want me to?" Daily: morning briefing, drafted replies awaiting approval, scheduled-and-protected focus time. Power: standing instructions ("always decline X," "book travel under $Y"). Enterprise: executive-assistant tier with delegation + audit.
• Features. MVP: inbox triage, calendar mgmt, task capture, daily briefing — all approval-gated. V2: proactive suggestions, standing instructions, travel/scheduling agents. V3: full delegated autonomy within policy, cross-domain orchestration. Long-term: a genuine chief-of-staff for everyone.

#Product 20 — Unified AI Operating System

• Vision. Not a 20th product — the integration of the other 19 into one coherent OS. This is the whole thesis (Section 2): one identity, one memory, one search, one permission model, one notification stream, one agent runtime, many lenses. Problem: the meta-problem — fragmentation itself. Differentiation: the only platform where all of the above is one substrate, not a bundle of acquired tools. Market: the entire knowledge-work TAM; the consolidation play.
• Primary personas: all nine.
• Journeys. First-time: enter via any single product (chat), discover the rest is already there. Daily: Home as the unified briefing; move between lenses without friction. Power: orchestrate work across all surfaces with agents + automations. Enterprise: one platform replacing 10+ tools, governed centrally.
• Features. MVP: the shared substrate + 3–4 lenses shipped coherently (Section 15). V2: progressive lens rollout on the same substrate. V3: cross-lens agents and automations as the default way work happens. Long-term: the default operating environment for human + AI cognitive work — the category we own.

#12. Business Model

Shape: consumer freemium → prosumer subscription → team seats → enterprise platform, with usage-based AI consumption underneath and a marketplace take-rate on top. The model mirrors the product: land with consumer, expand to team, monetize the enterprise's need for governance.

Revenue lines.

• Subscriptions (seats) — the core ARR engine; expands via seat growth (collaboration) and tier upgrades (governance).
• Usage-based AI — metered model/agent consumption above plan allowances (credits). Aligns price with the cost driver (inference) and with value (agents that do real work justify real spend). Enterprise gets committed-use discounts.
• Agent Marketplace — ~20–30% take rate on paid agents/tools; drives ecosystem + lock-in.
• Public API — usage-priced access to Continuum's substrate (memory, search, agents) for developers — turns the platform into infrastructure.
• Long-term monetization — outcome/work-unit pricing (charge per task completed by an agent, not per token), vertical solution packs, and a compute-margin business as we optimize inference. The strategic prize: as agents do more work, pricing shifts from "seats" (capped by headcount) to "work" (uncapped by headcount) — the largest expansion vector in software.

Unit-economics note. Gross margin is gated by inference cost; the model gateway (caching, model-tiering, batching) is therefore a business system, not just an engineering one. Free-tier abuse is the main risk — bounded by allowances + cheap-model routing for free users.

#13. Go-To-Market

Sequencing: bottom-up consumer/prosumer adoption → team viral expansion → enterprise land-and-expand. (Detailed phasing in Section 15.)

• Launch. Consumer assistant with a sharp wedge: "the AI that actually uses your stuff — and shows its work." Lead with legibility + connectors as the visible differentiator vs. ChatGPT/Claude. Invite-driven beta for scarcity + quality; design-press and founder-network amplification (ex-DeepMind credibility).
• Growth loops. (1) Connector loop — connecting Gmail/Drive makes it useful → user invites it into more of their life. (2) Collaboration loop — sharing a thread/doc/agent pulls in teammates (each share = an acquisition surface). (3) Marketplace loop — creators publish agents → bring their audiences → those users build/publish. (4) Memory loop — the more you use it, the better it gets, the harder to leave (retention as growth).
• Virality. Shared artifacts (research reports, docs) carry "made with Continuum" + are forkable; agent installs are shareable; published docs are public/SEO surfaces.
• Enterprise sales. Land via bottom-up usage (employees already love it) → IT discovers shadow usage → sell governance (the Admin Console is the enterprise wedge: "you already have 500 people using this — here's how to secure it"). Security review + SOC2/HIPAA as table stakes. Design-partner program with 5–10 lighthouse accounts.
• Community & developers. Open the MCP tool spec + public API early; agent-builder hackathons; template library; creator revenue share. The developer ecosystem is both a moat and a distribution channel.

#14. Competitive Analysis

The recurring pattern: incumbents are strong in one surface and structurally constrained from consolidating (channel conflict, legacy architecture, or business-model lock-in). We win on consolidation + legibility, not on out-modeling the labs.

The defensible wedge no incumbent can easily copy: a single substrate (one memory, one permission model, one search, one agent runtime) with interaction design that makes agents legible and steerable. Incumbents can add features; they cannot easily un-fragment their architecture or business model.

#15. Build Sequencing & Roadmap (the realism section)

You cannot build 20 products at once, and you shouldn't pretend to in front of investors. The credible story is one substrate + a deliberate lens-by-lens rollout, where each lens reuses the substrate so velocity increases over time.

PHASE 0  (0–3 mo)  Substrate v0 + Consumer Assistant (P1)
  → identity/multi-account, workspace, thread, AgentEvent log,
    single-agent runtime, user memory, 3 connectors, the trace/approval UX.
  Goal: legibility + connectors wedge live. THIS is where the interaction-model role is decisive.

PHASE 1  (3–6 mo)  Memory (P6) deepened + Search (P8) + Document lens (P17)
  → unified retrieval, workspace memory, docs as live entities.
  Goal: prove "one search, one memory" across lenses.

PHASE 2  (6–12 mo) Team Collaboration (P13) + Project Mgmt (P11) + Multi-agent (P3) + Agent Builder (P4)
  → seats + collaboration loop; agents as assignees/teams.
  Goal: team expansion + the agent platform.

PHASE 3  (12–18 mo) Enterprise Assistant (P2) + Admin Console (P15) + Analytics (P16) + Knowledge Base (P7)
  → SSO/SCIM, ABAC, audit, SOC2. Goal: enterprise monetization.

PHASE 4  (18–24 mo) Automation (P12) + Coding (P10) + Research (P9) + Meeting (P18) + Marketplace (P5) + Personal (P19)
  → breadth lenses + ecosystem. Goal: the full OS (P20) realized.

Why this order: legibility/connectors first (differentiation + retention), then the memory/search substrate (compounding moat), then collaboration (revenue expansion), then governance (enterprise dollars), then breadth + ecosystem. Each phase ships real product and de-risks the next. P14 (workspace/multi-account) and P20 (the unified OS) are not phases — they are continuous concerns owned across every phase.

Phase 0 success criteria (verifiable): time-to-first-token < 500ms; time-to-first-connector < 5 min for 50% of new users; first-week retention > 35%; users can correctly answer "what did the agent just do and why?" in usability tests > 90% of the time (the legibility metric).

#16. Org Design & Hiring (design team build-out)

Tie-in to the advisory part of the role. The interaction model is the moat (Section 2), so design is staffed as a first-class discipline, not a service function.

• Near-term design org (first 5–8 hires):
  1. Founding Product Designer — Interaction Model (the substrate surface: chat, IA/nav, multi-account, onboarding). The most leveraged role; owns the "one product, many lenses" coherence.
  2. Design Engineer (React/TS/Tailwind; ships the component substrate + design system).
  3. Product Designer — Agent/Trust surfaces (trace, approvals, autonomy, explainability — the hardest novel UX).
  4. Product Designer — Enterprise/Admin (governance, permissions, density).
  5. UX Researcher (legibility/steerability is an empirical claim — it must be measured).
  • later: brand/marketing designer, content designer, second design engineer.
• Hiring bar & signals: systems thinkers who can hold the whole IA in their head; people who ship in code (design-engineering hybrid bias given the stack); evidence of taste under constraint. Red flag: portfolio of pretty screens with no model behind them.
• Work trials: a 1-day paid trial on a real, scoped problem — e.g., "design the approval + undo flow for an agent sending email on the user's behalf" — judged on the interaction model (states, edge cases, legibility, reversibility), not visual polish. This directly tests the throughline skill.
• Interview loop: portfolio deep-dive (systems & rationale) → live IA critique (give them a fragmented flow, watch them consolidate) → work trial → team/founder fit. Calibrate interviewers; rubric-scored.
• Design work streams (organize by substrate, not by product): (1) Interaction Model & IA, (2) Agent/Trust, (3) Design System & Design Eng, (4) Enterprise/Admin, (5) Research/Insights. This mirrors the architecture — design owns surfaces of the substrate, so the org doesn't re-fragment what the product consolidates.

#17. Risks & Open Questions

• Scope vs. focus. The biggest risk is building 20 mediocre lenses instead of one great substrate + a few excellent lenses. Mitigation: Section 15 sequencing; ruthless Phase-0 focus on the legibility wedge.
• Inference economics. Gross margins depend on the model gateway's efficiency. Open question: at what usage tier does usage-based pricing become necessary to protect margin?
• Trust/safety of agentic action. Autonomous action on user data/tools is the value and the liability. Mitigation: graduated autonomy + approvals + undo + audit as non-negotiable primitives.
• Incumbent distribution. Microsoft/Google can bundle. Mitigation: be 10x on consolidation + legibility + cross-vendor neutrality, and win bottom-up before they react.
• Frontier-model dependence. We route to others' models. Mitigation: provider-agnostic gateway, and own the application/memory/interaction layer that doesn't commoditize.
• The legibility claim is empirical. "Legible and steerable" must be measured (Section 15 metric), not asserted. If users still can't predict/control agents, the thesis fails — so research is funded from day one.

End of v0.1 blueprint. Next artifacts to derive from this: (a) a clickable prototype of the Phase-0 substrate surface; (b) the Phase-0 engineering spec; (c) the design-system Figma + packages/ui scaffold.