ai.com is the agent-native workspace for teams of 2–50: every person gets their own agent — one each — in their Rooms, DMs, Meetings, and morning brief, doing real work in the tools they already use, with approval before anything goes out.
This document takes the roadmap (see roadmap-deck.html) down to build depth: features, epics, stories, acceptance criteria, and mockups. The strategy in one line: close the gap between what the landing page promises and what the product does — then extend past it. Three bets order everything: one-each becomes real (T2), trust you can watch (T3), habitual before viral (T4, with T5 last on purpose).
How to read this doc
If you're picking up a feature to build: read its article in full, then Product invariants (they apply to every feature and are never repeated in ACs), then Definition of done. The Feature index and build order tell you where your feature sits.
Priority — P0 blocks the honest launch · P1 is the differentiation build · P2 is later. Effort — S / M / L / XL, team-weeks scale, gut-level.
Starting point (cyan bar) — what already exists in the codebase. Most of T1 is enabling, not building; read these before estimating. Benefit (dark bar) — the user value and the business reason, in that order.
Facts row (pill strip under each feature) — dependencies, what it blocks, and the telemetry events it must emit (defined in Telemetry).
Stories carry acceptance criteria as unchecked boxes — together with the invariants, they are the definition of done for scope.
Mockups (solid frames) are directional, in the product's visual language — layout and content, not final design. Wireframes (dashed frames) are structure only — information architecture, not visual intent.
Data shapes in Data contracts are proposals to anchor discussion — confirm against the gateway before building on them.
Vocabulary is the approved list only: agent, Routine, Connector, Vault, Command Center, Room, Recap, checkpoint, verified done — definitions in the Glossary.
Feature index
Everything in this spec, one screen.
The full backlog at a glance: what each feature gives the user, how big it is, what already exists, and what it waits on. Each ID links to the full article.
Capabilities and Routines that travel between teams
P2
—
Epic-level only
Post-R4
T2.5 · T3 · T4.2
Release plan
Four releases, no dates.
Sequence over schedule. Each release has a single sentence it must make true — ship when the sentence is true, not before.
R1 The honest launch
“Everything on the landing page is true for a team of one.” — T1 complete, T2.6 hardening complete. Free tier live, brief live, billing reachable, one vocabulary.
R2 Teams
“Four people. Four agents. One workspace — for real.” — T2 complete. Workspaces, invites, seats, shared Rooms, team billing, admin basics.
R3 Trust, visible
“Every safety claim is something you can watch on screen.” — T3.1–3.4 shipped; the watchable-workspace decision (3.5) made and either scoped or closed.
R4 The habit
“The agent shows up before it's asked, wherever you are.” — T4 complete. Brief on channels, Routine authoring, Goals, voice, Scribe. T5 begins after.
Foundations
The rules and shapes every feature inherits.
Read once, apply everywhere. The invariants are global product requirements — feature acceptance criteria assume them and never repeat them. The app map, patterns, and flows are the shared UX skeleton the mockups hang on.
Product invariants
These are non-negotiable behaviors of the whole product. A PR that violates one is a bug regardless of what its feature spec says. Referenced from stories as INV-n.
ID
Invariant
Enforced by / surfaced in
INV-1
Nothing external without a checkpoint. No email, message, connector write, or publish leaves the workspace without explicit approval — allow once / always allow (scoped) / deny. Allow-always grants are inspectable and revocable.
The write gate. An inference can never overwrite an owner-stated fact. The gate is deterministic and LLM-free. Editing a fact promotes it to owner-stated permanently.
Graceful walls. Every cap, limit, and exhausted budget degrades with a named path forward (top-up, upgrade, extend). Silent failure is a stop-ship bug.
Verified means verified. A “verified” badge renders only with the independent verifier's evidence attached. Unverified completion never shows as verified done.
Targets marked proposed are defaults to anchor discussion — confirm or replace them at kickoff; the rest are stated elsewhere in this spec or already true of the platform.
Area
Requirement
Target / note
Performance
First brief after connecting a Connector
~10 min, and the UI sets that expectation explicitly (T1.1-S2)
Command Center warm render
< 1.5 s p75 · proposed
Checkpoint action → visible confirmation
< 2 s; execution may continue async with visible status · proposed
Committed secrets rotated, purged from history (T1.7-S2)
External penetration test on the multitenant plane
Findings triaged to done before teams arrive (T2.6-S4)
Privacy
Member removal
Their agent leaves shared Rooms; private data leaves with them (T2.1-S3)
Audit scope
External actions only; internal reads not logged; retention 90 days default (T3.3)
Memory deletion
Immediate, including retrieval traces (T3.4-S2)
Accessibility
New surfaces meet WCAG 2.1 AA; three-verb actions fully keyboard-operable; pending checkpoints announced to assistive tech
proposed
Observability
Per-user ingest cost and latency dashboarded (T1.1-S1); every feature emits its telemetry events; an unapproved external action fires an alert — it is a stop-ship incident (guardrail metric)
—
Compatibility
Evergreen browsers; responsive to 360 px; channel digests legible as plain text
proposed
App map & shared UX patterns
Directional information architecture — where every surface in this spec lives. Dashed frames are wireframes: structure only, not visual design. Nav ids follow labels (T1.6).
Selected surface renders here. Chat-first surfaces (Rooms, DM) share the fused human + agent timeline; every working state carries Stop (INV-3); every outbound step pauses at a checkpoint card (INV-1).
Right panel
Context for the main surface: run steps, artifacts, drafts, per-Room permissions (T2.4).
The Activity tab lives here — id renamed to match its label (T1.6). If T3.5 lands as glass box, its live step feed docks here.
One shell, every feature in this spec reachable in ≤ 2 clicks. Approvals badge is the only global counter (T3.2-S3).
Anatomy — the checkpoint card (the product's core interaction)
Describe in English→Compiled plan + checkpoint→Test run — sends stubbed→Schedule→Run pauses at checkpoint→Verified strip→Run history
Empty, loading & stale states
Every new surface ships with these designed, not defaulted — they are part of each story's done. States marked proposed need copy review.
Surface
State
What the user sees
Command Center
0 Connectors
“Connect one thing to get your brief” + single connector CTA (T1.1-S2)
First sync running
Progress with the ~10-minute expectation set explicitly (T1.1-S2)
Stale > 24 h
Labeled stale with last-updated time — never presented as current (T1.1-S3, INV-7)
Approvals Center
Empty
“Nothing needs you” + when the last item was actioned · proposed
Activity (audit)
Empty
One line explaining what will appear and that only external actions are logged · proposed
Memory inspector
Empty
“Your agent hasn't learned anything yet — facts will appear here with sources” · proposed
Shared Room
No agent addressed yet
Inline hint: @-mention any member's agent; it answers to its own person (T2.2) · proposed
Goals
None yet
One worked example goal (outcome + checks + budget) ready to adapt · proposed
Theme 1 · Priority P0 · Release R1
Make the promise true.
Almost nothing here is new engineering — it's finishing, enabling, and un-hiding what exists. This theme is the launch gate: until it's done, the landing page oversells.
FEATURE T1.1
Command Center, live
P0Effort MBuilt, disabled
Benefit. The user opens ai.com and their day is already triaged — priorities, waiting replies, people context — before they've read a single inbox. For the business: this is the daily habit every other feature hangs off, and the landing page's central promise made true.
Problem. The landing page's Command Center promise — “your day, triaged before you sit down” — is the product's proactive spine, and it currently runs on mock data. The ingest pipeline (Slack, Gmail, Google Calendar, Databricks, Matrix → staged store → brief JSON) is written, and its cron ships disabled.
Starting point: full Python collector pipeline exists; cron seed-jobs ship "enabled": false; collectors assume single-pod filesystem paths. Frontend brief UI is complete and consuming the JSON shape already.
Stories
T1.1-S1Deploy collectors multitenant-safe
Collectors run per-user against shared infrastructure, no pod-path assumptions
One user's ingest failure never blocks another's
Ingest cost and latency per user are measured and dashboarded
T1.1-S2Turn the brief on for connected users
Users with ≥1 connector get a real brief — priorities, Awaiting Reply, people context — with zero mock rows in prod
Empty states are designed: 0 connectors → “connect to get your brief”; fresh connect → progress with the ~10-min expectation set
T1.1-S3Freshness the user can see
Brief shows “updated 7:45” and refreshes on a visible schedule
Stale (>24h) brief states say so rather than presenting old data as current
Mockup — the morning surface
Command Center Mon 7:45 · updated 2 min ago
Meridian renewal — proposal due todayThread went quiet Thursday. Draft reply is ready for your review.
Priority
3 replies waiting since FridayNia (invoice), Tomas (contract), Priya (roadmap doc).
Awaiting reply
Signups up 38% this weekDatabricks · weekly cohort. No action needed.
Context
Brief panel: priorities first, Awaiting Reply second, context last. Freshness timestamp always visible in the header.
Wireframes — the two states before the brief exists (T1.1-S2)
0 Connectors
“Your brief starts with one connection.” Single primary CTA: Connect Gmail or Slack One line of what the brief will do with it — no empty grid, no mock rows.
First sync running
“Reading your last two weeks — ready in about 10 minutes.” Progress indicator + what's being read (counts, not content). The user can leave; the brief announces itself when ready.
These two states are most users' first impression of Command Center — designed, not defaulted (see Empty states).
Open questions
Ingest cadence at scale: continuous vs. N-per-day per user — cost model decides (see Open Questions Q4).
FEATURE T1.2
Decisions — proactive doing, not just reading
P0Effort SBuilt, commented out
Benefit. The agent doesn't just report — it proposes the next step and takes it on one tap, safely through a checkpoint. For the business: the product's aha moment made daily, and the cheapest big win in this backlog.
Problem. The brief tells you what matters; Decisions closes the loop by proposing the next step and taking it on approval. The surface is computed today and its render block is commented out — the cheapest big win in the backlog.
Starting point: “Your Next Steps” data is already computed in the Command Center pipeline; the render section exists in code, commented out. Approval plumbing (allow-once/always/deny) already spans the platform.
Stories
T1.2-S1Ship the Decisions block in Command Center
Each decision card: what the agent proposes, why (source), and Approve / Discuss / Dismiss
Approve executes through the standard checkpoint flow; nothing external happens without it
Dismissed decisions don't reappear for the same underlying item
T1.2-S2Discuss hands off to the DM
“Discuss” opens the agent DM with the decision context preloaded
The decision resolves (done/dismissed) based on the conversation outcome
Mockup — a decision card
Command Center · Decisions Mon 7:45
Send the Meridian follow-up?Draft ready — proposal was due Friday, no reply since. Based on the #meridian thread and Thursday's Recap.
A decision is always: proposal + provenance + the three verbs. Approve routes through the normal checkpoint; nothing sends from the card silently.
FEATURE T1.3
Billing, self-serve end to end
P0Effort S–MBuilt, nav dead-coded
Benefit. Money in without a phone call: see the plan, see usage before the wall, change or cancel any time. For the business: unblocks charging at all, and kills the silent-failure usage wall (INV-8).
Problem. The pricing page promises “upgrade, downgrade, or cancel any time — from the product, not a phone call.” Stripe, all three tiers, and ~15 API wrappers exist; the navigation to reach any of it is dead-coded, and the usage banner returns null. We cannot charge money we can't let people manage.
Starting point: Stripe SDK integration, plan comparison UI, and tier-scoped feature flags all exist behind aic-enable-subscriptions. This is un-hiding plus QA, not a build.
Stories
T1.3-S1Un-hide Billing in settings
Billing appears in settings for every user; current plan, renewal date, payment method visible
Flag flips on for 100% of users; dead-code comments removed
T1.3-S2Upgrade / downgrade / cancel in-product
All three transitions complete without human contact, with proration handled by Stripe defaults
Downgrade and cancel state plainly what is lost and when it takes effect
T1.3-S3Usage, visible before the wall
Usage meter (percentage of plan) lives on the Billing screen and warns at 80% in-product
Hitting the cap degrades gracefully with a clear path to top-up or upgrade — never a silent failure
Mockup — plan & usage
Settings · Billing jeet@meridian
Team — $29 per person / month4 seats · renews Aug 12 · Visa ····6411
Current plan
Usage this cycle
62% of plan · resets in 19 days
Usage is a percentage of plan (the word “credits” stays in marketing only). Change plan opens the three-tier comparison already built.
FEATURE T1.4
Free-first onboarding — to the aha in minutes
P0Effort MRework
Benefit. The first five minutes deliver the product's core feeling — a real task ending in “nothing sends until you approve” — with no credit card in the way. For the business: this is activation; the R1 north-star metric lives here.
Problem. Onboarding routes everyone through plan selection and payment, and a waitlist state exists. “Start free” must start free, and the flow should sprint to the product's aha — the first agent run ending in an approval card — not to a checkout.
Starting point: the claim-handle flow (signup → @handle → name your AI → plan → payment → provisioning) is complete; this is re-sequencing plus a first-run script, not new infrastructure.
Stories
T1.4-S1Remove plan + payment from the default path
Free path: signup → @handle → name your AI → in the product. Payment appears only when the user picks a paid tier
Waitlist state removed (or explicitly re-justified as a capacity valve with its own copy)
T1.4-S2Scripted first run to the approval card
First DM suggests one concrete task that ends in an approval card (“Needs you — nothing sends until you approve”)
Median time signup → first approval card is measured; target under 5 minutes
T1.4-S3Connect-one-thing prompt
After the first run, the product asks for exactly one connector (Gmail or Slack), framed by what the brief will do with it
Skipping is one tap and non-punitive
Mockup — the path, before and after
Sign up→@handle→Name your AI→Pick a plan→Payment→First run → approval card→Connect one thing
Struck steps leave the default path and return only when the user chooses a paid tier.
FEATURE T1.5
Memory graph, on by default
P0Effort MBuilt, flagged off
Benefit. The trust pillar becomes real: what you tell the agent stays authoritative over anything it infers (INV-4). For the business: the strongest IP finally doing work, and the prerequisite for the memory inspector (T3.4).
Depends multitenant validationBlocks T3.4Instrument rollout dashboards — retrieval hit rate, latency delta vs. embedding memory
Problem. “Its memory can't overwrite what you've told it” is a trust pillar on the landing page — enforced by the bi-temporal graph with its deterministic, LLM-free write gate. It ships dark. Our strongest IP is doing nothing for any user.
Starting point: graph schema, write gate, and integration seams are complete behind knowledgeGraph.enabled / AIBOT_KG_FORCE_ON. Work is multitenant validation and a staged rollout, not features.
Stories
T1.5-S1Validate per-user graphs under multitenancy
Isolation test: no query path can cross user boundaries
Write-gate property tests pass: an inference can never overwrite an owner-stated fact
T1.5-S2Staged rollout with a kill switch
Rollout 5% → 25% → 100% with per-stage quality checks (retrieval hit rate, no regression in response latency)
Kill switch degrades to the existing embedding memory, invisibly to the user
The user-facing surface for this — the memory inspector — is T3.4; this feature is the engine going live.
FEATURE T1.6
One vocabulary
P0Effort SCopy + refactor pass
Benefit. Every screen calls the same thing the same name; the product reads like one team wrote it. For the business: inconsistency spends the trust the brand is buying — and support, docs, and onboarding all get cheaper.
Depends string freeze after T1.1–T1.4 landBlocks launch copyInstrument string audit in CI (INV-10)
Problem. The AI is named four ways on adjacent screens; the same action is Add, Install, or Get; the same area is subscription, billing, and Billing. Every inconsistency spends trust the brand is trying to earn. One pass, one list, done before launch traffic arrives.
The rename table (backlog, one row = one sweep)
Today (kill)
Ship
Where it lives
assistant · bot · “your ai”
agent
Profile defaults, BriefCard, DecisionCard, onboarding, danger zone
Activity (tab id: computer)
Activity — id renamed to match
Right-panel tabs; ids aligned to labels across all four mismatches
Install · Get
Add
Marketplace rows, room dialog, dev build
playbook · workflow
Routine (a run; a checkpoint)
Rail testids, toasts, data-model labels in UI copy
huddle · meeting vs call drift
Call (Recap after)
/huddles and /calls redirects removed; calendar copy
subscription · billing · Billing
Billing
Settings pages and modal — also collapse the duplicated settings surfaces
Unpublish vs Revoke · Remove vs Uninstall
Unpublish · Remove
Marketplace management actions
Acceptance: a full-product string audit finds zero occurrences of the kill column; the approved-vocabulary list is added to the PR checklist.
FEATURE T1.7
Launch housekeeping
P0Effort S
Benefit. The landing page becomes a description of the product, not a promise. For the business: legal pages, secrets hygiene, and the third-backend question stop being launch risks.
“Four people. Four agents. One workspace” is the landing page's centerpiece and the largest genuinely new build in this spec. The model to hold: a workspace is a group of people; each person owns exactly one agent; agents are private to their person and visible in shared Rooms.
FEATURE T2.1
Workspaces, invites, seats
P0Effort XLNew build
Benefit. A team becomes a first-class thing: invite four people and get four agents in one workspace, with seats that bill honestly. For the business: the positioning claim becomes product — everything in T2 stands on this.
Problem. There is no org model: no workspace, no invites, no seats, no roles. Everything else in this theme stands on this.
Starting point: multitenant infrastructure is in place (per user). Matrix already handles multi-party rooms. The missing object is the workspace itself: membership, roles (owner / member), seat count, and the invite flow. Depends on T1.7-S3 — the third backend must have an owner before this is scoped there or here.
Data model (minimum)
Workspace { id, name, plan, seat_count } · Membership { user, workspace, role: owner | member } · each user keeps exactly one agent; the agent joins the workspace with its person. One workspace per user at launch (multi-workspace deferred — see Open Questions).
Stories
T2.1-S1Create a workspace
Any user can create a workspace from settings or post-onboarding prompt; they become owner
Existing solo users can create one without disturbing their agent, history, or connectors
T2.1-S2Invite by link or email
Owner generates an invite link or sends email invites; invites are revocable
Invitee lands in signup → @handle → name your AI → joins the workspace — the free-first path (T1.4) with a workspace waiting at the end
T2.1-S3Member list & roles
Members screen shows each person, their agent, role, and seat status
Owner can remove a member: their agent leaves shared Rooms; their private data leaves with them
Mockup — members
Meridian Labs · Members 4 of 5 seats
Maya · @mayaagent @mika — 3 Routines running
Owner
Jon · @jonagent @juno — Salesforce, Gmail connected
Member
Priya · @priyaagent @pico — watching Datadog
Member
Invite someonemeridian.ai.com/join/x7f2 · or send by email
A member row is always person + their agent together — the one-each frame made structural.
FEATURE T2.2
Shared Rooms with several agents
P1Effort LPartially built
Benefit. Teammates see each other's agents working in one timeline — attributed, addressable, and stoppable by anyone (INV-2, INV-3). For the business: this is the demo that sells teams.
Problem. Rooms today hold one person and their agent. The promise is a team timeline where multiple members' agents work side by side — each answering to its own person, all visible to everyone, Stop always in reach.
Starting point: fused human+agent Matrix timeline, streaming plans, and Stop all exist for the single-agent case. The build is multi-agent presence, attribution, and addressing — not the chat itself.
Stories
T2.2-S1Any member's agent can be addressed in a Room
@-mention any agent in the workspace; it responds in-thread with clear identity (name + whose it is)
An agent only takes instructions from its own person; others' requests become suggestions its person approves
T2.2-S2Attribution that can't be confused
Agent messages are visually distinct per agent (avatar + “Maya's agent” label), never confusable with human messages
Live status (“working… Stop”) shows which agent is doing what, to whom it answers
T2.2-S3Stop is universal
Any member can Stop any agent's work in a shared Room; the owner is notified with the stopped state preserved
Mockup — two agents, one timeline
#shipping-week Maya, Jon, + their agents
Maya
@mika pull Thursday's release notes together. @jon can juno check which customers asked for the export fix?
mika · Maya's agent
Drafting release notes from the merged PRs and #eng recaps.
Read 21 merged PRsDrafting — Stop
juno · Jon's agent
Jon approved. 6 accounts asked for the export fix — list in the thread. Two are renewal-quarter.
Each agent carries its person's mark. Note juno's line: a request from Maya became work only after Jon's approval.
FEATURE T2.3
Team billing
P0Effort MStripe exists, per-seat-of-one
Benefit. One subscription for the whole team that follows membership automatically — add a member, the seat appears; remove one, the credit does. For the business: revenue tracks the org model with zero manual ops.
Problem. The pricing page sells $29 per person and a flat $299 Command tier. Stripe today knows one seat. Billing must follow the workspace, not the individual.
Stories
T2.3-S1Workspace-level subscription
Plan attaches to the workspace; seat count syncs to membership automatically (add member → prorated charge; remove → credit)
Owner sees per-seat breakdown on the Billing screen (extends T1.3 mock)
T2.3-S2Command tier, flat
$299 flat covers the workspace regardless of seats ≤50; tier-scoped flags (priority routing, budgets, API access) apply workspace-wide
T2.3-S3Free workspace rules
Free tier workspace bounds defined (members, connectors, Routines) and enforced with graceful walls that name the Team tier
Wireframe — workspace billing (extends the T1.3 screen)
Settings · Billing Meridian Labs · owner view
Team — $29 per person / month4 seats · $116/mo · renews Aug 12 · Visa ····6411
Current plan
Seats follow membersMaya · Jon · Priya · Leo — add a member and the seat prorates; remove one and it credits (T2.3-S1)
Command — $299 flat, up to 50 seatsPriority routing, budgets, API access — workspace-wide
Billing lives on the workspace, owner-visible. The per-seat math is always shown as people, never as an abstract quantity.
FEATURE T2.4
Admin & per-room permissions, productized
P1Effort MBuilt, flagged off
Benefit. The owner sets the workspace's risk posture in three switches, not forty tool toggles — and every Room inherits it. For the business: the control story that closes safety-conscious buyers, without building enterprise RBAC.
Problem. Per-room tool grants exist behind a flag; the admin console is an external iframe behind a single boolean. A team needs a real, minimal admin surface: members, defaults, and per-room control — no enterprise RBAC.
Starting point: tool×group permission grants with allow/deny RPC are complete. The work is a first-party UI and workspace-level defaults, replacing the iframe.
Stories
T2.4-S1Workspace defaults for external actions
Owner sets default posture per action class (external email, external messages, connector writes): allowed with checkpoint / off
New Rooms inherit defaults; per-room overrides win
T2.4-S2Per-room permission panel, in-product
The flagged permission tab ships for owners in every shared Room
Changes take effect immediately and are visible to the room (“Maya turned off connector writes here”)
Send external emailAlways pauses at a checkpoint first
External messages (Slack, WhatsApp)Off in this Room
Connector writes (Salesforce, Jira)Off in this Room
Three action classes, not forty tool toggles. The full tool matrix stays available under “advanced.”
FEATURE T2.5
Team-scoped capabilities
P1Effort SData model exists
Benefit. A Skill, App, or Dashboard built by one person serves everyone, with the builder's name on it. For the business: the first seed of the compounding thesis, proven at team scale before it goes cross-team (T5-E1).
Problem. Skills, Apps, and Dashboards an agent builds are personal. The data model already carries a team scope — wire it so a capability built once serves the whole workspace.
T2.5-S1Share to workspace
Builder can flip a capability from private to workspace; it appears in every member's library, attributed
Unshare removes it cleanly from members who didn't build it
Wireframe — the share control, in the Library
Library · weekly-metrics dashboard built by Priya's agent
Share with Meridian LabsEveryone in the workspace can use it · shows “built by @priya”
Used byMaya · Jon — unsharing removes it from their libraries cleanly
One switch: private ↔ workspace. Attribution is permanent; secrets and Connector credentials never travel with a shared capability.
FEATURE T2.6
Multitenant hardening
P0Effort LEngineering track
Benefit. Teams can be put on the platform without inheriting single-user-era risk. For the business: this is the R1 gate — the security basics that block both launch traffic and the first sales conversation.
Depends —Blocks R1 ship (gate)Instrument pen-test findings burndown · isolation suite green in CI
Problem. The gateway grew up single-user and says so: no inbound rate limiting, plaintext state on disk, “not hardened for public exposure” in its own security docs. The audit predates the multitenant migration; this track re-establishes the baseline before teams arrive. Gate for R1, not R2.
T2.6-S1Inbound rate limiting on all public surfaces
T2.6-S2State encrypted at rest (config, sessions, permission files) — not just volume-level
T2.6-S3Tenancy isolation test suite: no data path crosses users; run in CI
T2.6-S4External penetration test on the multitenant plane; findings triaged to done
Theme 3 · Priority P1 · Release R3
Trust you can watch.
Every mechanism here already runs in the backend. The theme gives each one a surface — because trust that can't be seen is a badge, and we don't do badges.
FEATURE T3.1
Verified done, on screen
P1Effort MVerifier complete, no UI
Benefit. “Done” arrives with evidence you can expand — the independent verifier's word, not the agent's (INV-9). For the business: the trust claim becomes demo-able, and it's what justifies the price over a chat window.
Depends verifier backend (built) · T4.3 for the Goals surfaceBlocks T4.3-S3Instrumentevidence_card_shown · evidence_expanded · verification_failed_shown
Problem. The independent verifier re-runs a goal's success checks and confirms with evidence — invisibly. “Done means verified” converts buyers only if they can see the evidence.
Starting point: maker/checker goal worker + evidence-based verifier are backend-complete (HTTP-only). Build is an evidence card component and its data contract.
Stories
T3.1-S1Evidence card at completion
When verified work completes, the Room/DM shows: claim, checks run, evidence per check (link, count, artifact), verifier verdict
Failed verification shows what failed and what the agent will do next — never a silent retry
T3.1-S2Verification beyond Goals
Routine runs with external sends get a lightweight verified strip (“6 sent, verified — every send confirmed with evidence”)
Mockup — the evidence card
Routine · monday client report run 142 · Mon 8:24
Run 142 complete — 6 sent, verified
6 emails found in Sent, matching drafts you approvedAll 6 recipients match the client contact listNo bounces after 15 minutes
Checked independently by the verifier — not the agent's word.
Verified
Evidence is concrete and checkable: each line is a real check with a real source, expandable to the raw artifact.
FEATURE T3.2
Approvals Center
P1Effort MTransport exists
Benefit. Everything waiting on you, one screen, three verbs — “you're always the one who says go” becomes a place. For the business: approval latency is the trust metric; one inbox is how it falls.
Depends approval transport (built)Blocks —Instrumentapprovals_opened · approval_actioned{verb, source} · always_rule_revoked
Problem. Checkpoints happen in four places — command approvals, Routine gates, goal budgets, Decisions — each surfaced only where it occurred. One inbox makes “you're always the one who says go” a place, not a sentence.
Starting point: the unified allow-once / allow-always / deny transport already spans exec, Routines, and grants. Build is aggregation + one screen + badge counts.
Stories
T3.2-S1One inbox for every pending checkpoint
All pending approvals in one list: what, where from, waiting since, with the standard three verbs inline
Acting in the inbox and acting at the source are perfectly interchangeable
T3.2-S2“Always” rules are inspectable
A rules tab lists every allow-always grant with scope, and one-tap revoke
T3.2-S3Waiting-on-you signal
Badge count in the rail; optional channel nudge when something has waited > N hours (user-set)
Mockup — the inbox
Approvals 3 waiting
4 invoice follow-ups → send via GmailRoutine · invoice chaser · run 7 · waiting 12 min
Log 9 calls to SalesforceConnector write · #sales · waiting 1 h
Goal budget: extend research run by ~2 hGoal · competitor scan · waiting 3 h
Every pending gate, one screen, three verbs. Provenance (which Routine, which Room, how long waiting) always visible.
FEATURE T3.3
Audit log
P1Effort MNew build
Benefit. “What did the agent do while I was out” gets a queryable answer, and every external row traces to who said go. For the business: the trust surface small teams actually ask for — and the first enterprise brick, laid early.
Depends T2.1 for the workspace-wide viewBlocks later enterprise trackInstrumentaudit_opened · audit_filter_used
Problem. The platform's own docs say “No audit log.” “What did the agent do while I was out” deserves a queryable answer for a 10-person team — and this is the first brick of the eventual enterprise track, laid early because small teams want it too.
Stories
T3.3-S1Append-only event stream for agent actions
Every externally-visible agent action logs: actor agent, action, target, Room, approval reference, timestamp
Log is append-only; retention default 90 days (tier-scoped later)
T3.3-S2Filterable activity view
Filter by agent, action class, Room, date; each row links to the approval that authorized it
Owner sees workspace-wide; member sees their own agent
Mockup — activity view
Workspace activity filtered: external actions · this week
When
Agent
Action
Authorized by
Mon 8:24
mika (Maya)
Sent 6 emails · Gmail · run 142
Maya · checkpoint 8:19
Mon 9:02
juno (Jon)
Logged 9 calls · Salesforce
Jon · always-allow #sales
Mon 11:40
leo's agent
Sent invoice follow-up · Gmail
Leo · checkpoint 11:38
Every external row traces to who said go and when. Internal reads aren't logged here — bold inside, careful outside.
FEATURE T3.4
Memory inspector
P1Effort MGraph distinguishes already
Benefit. See what the agent knows, who said so, and correct or delete either — the write gate (INV-4) made checkable by the person it protects. For the business: converts the memory IP from architecture into a visible differentiator.
Problem. “It can't overwrite what you've told it” becomes checkable only when users can see what the agent knows, which facts they stated versus which it inferred, and correct or delete either.
Starting point: the bi-temporal graph already separates owner-stated from inferred facts, with provenance. Build is a read/edit surface over an existing distinction.
Stories
T3.4-S1“What your agent knows” view
Facts listed by subject (people, projects, preferences), each marked You said / It inferred with source
Search across facts
T3.4-S2Correct and delete
Editing a fact marks it owner-stated — inference can never overwrite it after
Delete removes the fact and its retrieval traces; effect is immediate
Mockup — the inspector
Your agent's memory search: Meridian
Meridian's renewal decision-maker is Dana ChoFrom your DM, Jun 12
You said
Meridian prefers Thursday demosInferred from 4 scheduled calls
It inferred
Meridian budget cycle ends in MarchInferred from the Feb 3 email thread
Two provenance chips only. Editing an inferred fact promotes it to “You said” — the write gate then protects it forever.
FEATURE T3.5
The watchable workspace — a framed decision
P1 decisionSpike: S per optionExplore
Benefit. The strongest demo moment returns deliberately — or is retired deliberately — with per-user cost known before any promise is made. For the business: fills the wow-moment vacuum without writing an infra check by accident.
Depends two spikes (cost model · glass-box prototype)Blocks any “watch it work” language in marketingInstrument spike outputs, not product telemetry
Problem. Watching the agent drive a real screen was our strongest demo moment; it was removed with the computer. Decide deliberately whether and how it returns — with multitenant cost on the table — instead of drifting.
Wireframes — the three options, side by side
A · Live view
Streamed cloud browser, on demand.
Maximum wow · real per-user streaming cost · heaviest infra
B · Glass box
Live feed of steps, artifacts, drafts in the right panel as the agent works.
Most of the payoff · zero streaming infra
C · Hybrid
Glass box by default; “watch” button spins up the live view for that session only.
Payoff on demand · cost only when tapped
Decision framework
Option A — live view: watchable cloud browser on demand. Maximum wow; real per-user streaming cost and infra weight. Option B — glass box: rich live feed of steps, artifacts, and drafts as the agent works. Most of the payoff, none of the streaming. Option C — hybrid: glass box default; live view spun up only when the user taps “watch.”
Spikes to run: (1) per-session cost model for A at p50/p95 usage; (2) glass-box prototype in a Room, measured against the first-approval aha in onboarding tests. Decision owner: product + infra leads, after both spikes. Until decided: no “watch it work” language anywhere public.
Theme 4 · Priority P1–P2 · Release R4
Proactive & habitual.
Retention is the agent showing up before it's asked. Most of this engine exists; it needs finishing and a front door.
FEATURE T4.1
The brief, on your channels
P1Effort SChannels built
Benefit. The brief arrives where the user already lives — WhatsApp, Slack, iMessage — and “handle #2” works from there. For the business: the daily habit forms without asking anyone to open a tab; retention without a new surface.
Problem. The morning brief lives in the web app; the user lives in WhatsApp, Slack, and iMessage. Twenty channel integrations exist — deliver the brief where the person already is, and the daily habit forms without opening a tab.
Stories
T4.1-S1Channel delivery, user-scheduled
User picks channel + time; brief arrives as a compact digest with deep links into Command Center
Reply in-channel reaches the agent with brief context (“handle #2” works)
T4.1-S2Decisions in the digest
Approvable items appear with reply-to-approve semantics routed through the standard checkpoint
Mockup — WhatsApp digest
WhatsApp · mika 7:45
Morning — 3 things. 1 · Meridian proposal due today — draft ready 2 · 3 replies waiting since Friday 3 · Signups +38% this week
Reply 1 to review the draft. Full brief: ai.com/cc
Compact, numbered, actionable by reply. The web Command Center stays the deep surface.
FEATURE T4.2
Routine authoring, finished
P1Effort LEngine complete
Benefit. Describe a job in English, see the exact plan with its checkpoint, test it with sends stubbed, then trust it on a schedule. For the business: converts one-off tasks into standing automation — the strongest retention primitive in the product.
Problem. The Routine engine is durable, journaled, and checkpointed — closer to Temporal than to a toy. The authoring half is unfinished: describe in English → see the compiled plan → adjust → trust it on a schedule.
Starting point: workflow engine with replay-on-resume and restart-surviving approvals is complete. Build is the compile-preview-edit loop and a test-run mode.
Stories
T4.2-S1Describe → compiled plan preview
Plain-English description compiles to a numbered step list with sources and proposed checkpoints, before anything runs
User can move/add/remove a checkpoint; external steps can never drop below one checkpoint unless workspace policy allows
T4.2-S2Test run
Dry-run executes reads but stubs external writes, showing exactly what would have been sent
T4.2-S3Schedule & observe
Schedule in plain language (“every Monday 8:00”); run history shows per-run status, checkpoint decisions, and verified strips (T3.1)
Mockup — compile preview
New Routine draft — not yet scheduled
Every Monday, pull last week's Jira activity per client, draft an update email for each, and send after I approve.
mika
Here's the plan — 5 steps, one checkpoint:
1 · Pull last week's activity — 6 projects · Jira2 · Summarize per client · internal3 · Draft 6 updates · Gmail4 · Send to each contact · checkpoint — needs you5 · File replies, close the run
Before it runs
Test run first? External sends are stubbed — you'll see exactly what would go out.
The compiled plan is the contract: steps, sources, and the checkpoint visible before the first run.
FEATURE T4.3
Goals, in the product
P1Effort MBackend complete
Benefit. Hand the agent an outcome and a budget; it works unattended and comes back with verified completion or an honest pause (INV-8, INV-9). For the business: the unattended-work story, told safely — what “agent” is supposed to mean.
Problem. Set a goal, let the agent work unattended within a budget, get evidence-verified completion — fully built, reachable from no screen.
Stories
T4.3-S1Create a goal with a budget
Goal = outcome + success checks + budget (time/usage); checks are visible and editable before start
T4.3-S2Progress you can glance
Goal card: status, budget consumed, latest step; Stop always available
Budget exhaustion pauses and asks (Approvals Center item) — never silently continues
T4.3-S3Verified completion
Completion renders the T3.1 evidence card; unverified claims cannot show as done
Mockup — a running goal
Goal · competitor pricing scan running · 2h 10m in
Compare pricing pages of 8 competitors; produce a table with sources
Budget: 54% used · latest: reading 6th pricing page
Running
Outcome, budget bar, latest step, Stop. On completion this card becomes the verified-done evidence card.
FEATURE T4.4
Real-time voice on the web
P2Effort LFrontend wired, no backend
Benefit. Talking to your agent in the browser makes it ambient — the “always there” feel without picking up a phone. For the business: the surface that makes daily use feel like a relationship, not a tool.
Problem. LiveKit is fully wired on the frontend with no backend counterpart; browser voice has no server end. Talking to your agent in the browser is the “always there” feel — and telephony/batch TTS already prove the audio stack elsewhere.
Push-to-talk in the agent DM; latency target < 800 ms round trip
Voice replies render as text in the timeline too — the record stays chat
Wireframe — voice in the DM
DM · mika voice · push-to-talk
You · spoken
“What's blocking the Meridian send?”
mika · spoken + text
One checkpoint — the follow-up draft is waiting on your approval. Want me to read it out?
round trip < 800 ms · everything transcribed into the timeline
Voice is an input mode, not a separate surface: every exchange lands in the DM as text, so the record — and every checkpoint — stays chat.
FEATURE T4.5
Scribe, out of the whitelist
P2Effort SBuilt, whitelist-flagged
Benefit. Every paid workspace gets meeting Recaps, not a whitelist. For the business: an already-working feature stops being invisible inventory.
Depends quality bar reviewBlocks —Instrumentrecap_generated · recap_opened
Meeting Recaps work; Scribe sits behind {enabled, whitelist[]}. Graduate it: quality bar review, then GA to all paid tiers. Acceptance: whitelist flag deleted; Recap/Scribe Note naming per the vocabulary list.
Theme 5 · Priority P2 · Post-R4
The compounding layer.
The network is earned, not announced. Epic-level only for now — each gets its own spec when its dependency ships.
Epic
One-liner
Depends on
T5-E1 · Publish & install
A team publishes a Skill/App/Dashboard its agents built; another team installs it. Review gate + provenance label required.
T2.5 team scope; trust surfaces (T3)
T5-E2 · Routine templates
A proven Routine installable by another team — checkpoints intact, secrets never included.
T4.2 authoring; T5-E1 rails
T5-E3 · Developer platform, packaged
OpenAI-compatible API, plugin SDK, MCP — documented and positioned as the Command tier's spine.
T2.3 tiering live
T5-E4 · Agent to agent
Your agent working with mine across workspaces. Spec deliberately not written until E1–E2 prove sharing demand.
Everything above
Sequencing
Dependencies & build order.
What waits on what, and a suggested order inside each release. The order optimizes for two things: security before traffic, and the shortest path to each release sentence being true.
The dependency spine
This
Waits on
Why
T1.2 Decisions
T1.1 Command Center
Decisions are computed by the Command Center pipeline; no pipeline, no proposals
T1.4 Onboarding
T1.3 Billing
The plan step can only leave the default path once paid tiers are reachable in-product
T1.6 Vocabulary
T1.1–T1.4 landed
The sweep is a string freeze — running it before the P0 surfaces settle means running it twice
All of T2
T1.7-S3 / Q1
The workspace model can't be scoped until the third backend has an owner and a home is chosen
T2.2 · T2.3 · T2.4 · T2.5
T2.1 Workspaces
Rooms, billing, admin, and sharing all attach to the workspace object
T3.4 Memory inspector
T1.5 Graph on
The inspector is a surface over the live graph's owner-stated / inferred distinction
T4.3 Goals
T3.1 evidence card
Goal completion renders the evidence card; build the component once, in T3.1
T4.1 Brief on channels
T1.1
The digest is the brief, re-formatted — there must be a real brief first
T5 epics
T2.5 · T3 · T4.2
Sharing needs someone to share with, trust surfaces, and proven Routines — in that order
R1 ship
T2.6-S1..S4
Hardening gates the honest launch, not the team release — public traffic arrives at R1
Suggested order inside R1 and R2
R1 · first security before traffic
T1.7-S2 secrets rotation · T2.6-S1 rate limiting · T2.6-S2 encryption at rest. Nothing public-facing ships ahead of these.
R1 · core parallel tracks
Track A (product): T1.3 billing un-hide → T1.4 onboarding re-sequence. Track B (pipeline): T1.1 collectors multitenant → brief on → T1.2 Decisions. Track C (platform): T1.5 graph staged rollout · T2.6-S3 isolation suite.
R1 · last freeze and verify
T1.6 vocabulary sweep (string freeze) · T1.7 remaining stories · T2.6-S4 pen test → findings to done → ship when the R1 sentence is true.
R2 one spine, then fan out
Answer Q1 (third backend) → T2.1 workspaces end to end → then T2.2 shared Rooms and T2.3 team billing in parallel → T2.4 admin · T2.5 sharing. R3/R4 features (T3.2, T3.3, T4.2) have no T2 dependency and can absorb spare capacity any time.
Engineering notes
Done, contracts, and telemetry.
The cross-cutting material a build team needs on day one: what “done” means beyond the ACs, the data shapes to align on, and the exact events each feature must emit.
Definition of done — every story, every feature
A story is done when its acceptance criteria pass and all of the below hold. These never appear in feature ACs — they're assumed.
DOD-1Invariants hold
No external action bypasses the checkpoint transport (INV-1) — covered by a test, not a review comment
Tenancy isolation suite (INV-5) updated if the feature touches any per-user data path
DOD-2States designed
Empty, loading, stale, and error states shipped per the empty-states table — no framework defaults
DOD-3Strings clean
All UI copy from the approved vocabulary (INV-10); string audit passes in CI
DOD-4Instrumented
The feature's telemetry events (facts row) fire and are visible in the dashboard before the flag flips
DOD-5Reversible
Behind a flag with a documented kill path; staged rollout for anything touching memory, ingest, or billing
DOD-6Accessible
Keyboard-operable, labeled for assistive tech, AA contrast on new surfaces
Data contracts — proposed
Proposals to anchor the conversation, not statements about the codebase. Confirm each against the gateway (and the third backend, per Q1) before building on it. Shapes deliberately mirror what the mockups render.
// BriefItem — one row of the Command Center brief (T1.1)
{
"id": "bri_8f2",
"kind": "priority | awaiting_reply | context",
"title": "Meridian renewal — proposal due today",
"summary": "Thread went quiet Thursday. Draft reply is ready.",
"sources": [{ "connector": "gmail", "ref": "thread/187c…" }], // INV-6"decision_id": "dec_31a | null", // links a T1.2 card"computed_at": "2026-07-27T07:45:00Z" // drives INV-7 freshness
}
The frontend already consumes a brief JSON shape (T1.1 starting point) — reconcile this with it rather than inventing a second one.
// Decision — a proposed next step (T1.2)
{
"id": "dec_31a",
"proposal": "Send the Meridian follow-up",
"provenance": ["#meridian thread", "Recap · Thu"],
"artifact": { "type": "email_draft", "ref": "draft_99" },
"checkpoint_id": "chk_204", // Approve executes through this — INV-1"state": "open | approved | discussing | dismissed"
}
Dismiss must record the underlying item so the same decision never reappears (T1.2-S1).
One shape across all four sources is what makes the Approvals Center an aggregation rather than four integrations. The existing unified transport should already be close to this.
// EvidenceCard — verified done (T3.1, rendered by T4.3 and Routine runs)
{
"claim": "Run 142 complete — 6 sent",
"checks": [
{ "desc": "6 emails found in Sent matching approved drafts",
"evidence_ref": "gmail:sent-query/…", "pass": true }
],
"verdict": "verified | failed", // failed → what the agent does next, never a silent retry"verifier_run": "ver_88" // the verifier's identity, not the agent's — INV-9
}
// AuditEvent — append-only, external actions only (T3.3)
{
"ts": "…",
"agent": "mika", "owner": "maya",
"action_class": "external_email",
"summary": "Sent 6 emails · Gmail · run 142",
"room": "#clients",
"authorized_by": { "checkpoint": "chk_204", "mode": "allow_once" } // every row traces to who said go
}
// Workspace & Membership — the T2.1 minimum, restated
Workspace { id, name, plan, seat_count }
Membership { user, workspace, role: "owner | member" }
// one agent per user, always; the agent joins the workspace with its person (INV-2)// one workspace per user at launch — but keys must not foreclose multi-workspace (Q2)
Telemetry — the event dictionary
Every event a feature must emit (from the facts rows), and the success metric it feeds. Naming: object_verb, snake_case, properties in braces.
Event
Fires when
Feeds
signup_completed
Account exists, handle claimed (T1.4)
Activation funnel start
first_approval_shown / _actioned
The scripted first run reaches its approval card (T1.4-S2)
R1 north star — median signup → first approval
connector_connected
Any Connector completes OAuth (T1.1, T1.4-S3)
Activation depth; brief eligibility
brief_rendered / brief_delivered{channel}
Brief shown on web / arrives on a channel (T1.1, T4.1)
Habit metric — ≥4 of 7 days
decision_shown / decision_actioned{verb}
A Decision card renders / user picks a verb (T1.2)
Proactive-loop engagement
approval_actioned{verb, source}
Any checkpoint resolved, anywhere (T3.2)
Trust metric — median time-to-approve
workspace_created · invite_sent · invite_accepted
T2.1 flows
R2 north star — workspaces with ≥3 active agents; invite acceptance
plan_changed{up|down|cancel} · seat_synced
Self-serve billing transitions (T1.3, T2.3)
Monetization — free → Team conversion
usage_warned_80 · free_wall_hit
Usage crosses 80% / a free bound (T1.3-S3, T2.3-S3)
Graceful-wall health (INV-8)
evidence_card_shown / _expanded
Verified done renders / user opens evidence (T3.1)
Guardrails · alwaysZero unapproved external actionsAbsolute. Any incident is a stop-ship. Plus: verified-done accuracy (verifier catches ≥ X% of seeded failures).
To resolve
Open questions.
Owned by product unless noted
Q1 · The third backend. ~101 frontend calls hit a service outside both repos. Who owns it, and does the workspace model (T2.1) live there or in the gateway? Blocks T2 scoping. (eng + product)
Q2 · Multi-workspace. One workspace per user at launch. When a consultant belongs to two teams, what happens? Deferred, but the data model shouldn't foreclose it.
Q3 · Watchable workspace. Option A/B/C per T3.5 — decide after the two spikes.
Q4 · Command Center economics. Ingest cadence per user at multitenant scale — continuous, or N syncs/day by tier? Cost model decides; affects T1.1-S1 and the free tier's shape. (infra)
Q5 · Free tier bounds. Exact connector/Routine/member limits for the free workspace — set with the pricing CONFIRM pass (T1.7-S5).
Q6 · Agent-to-agent etiquette in shared Rooms. T2.2 keeps agents answering only to their person. Is a lightweight agent↔agent handoff (juno passes context to mika) in scope for R2 or parked to T5-E4?
Vocabulary
Glossary.
The approved vocabulary (T1.6), defined once. If a word isn't here, it doesn't go in the UI. The kill-list of banned synonyms is in the T1.6 rename table.
Term
Means
Never say
agent
The one AI each person owns. Answers only to its person (INV-2); named by them at onboarding.
assistant · bot · “your ai”
workspace
A group of people (2–50) and their agents. Owns the plan and the seats. One per user at launch.
org · team account
seat
One person + their agent inside a workspace's plan. Syncs to membership automatically.
license · user slot
Room
A shared timeline where members and their agents work together. Rooms carry permissions (T2.4).
channel · space
Command Center
The proactive surface: the brief (priorities, Awaiting Reply, context) plus Decisions.
dashboard · home
brief
The triaged morning view inside Command Center; also deliverable to channels (T4.1).
digest (except channel copy) · feed
Decision
A proposed next step with provenance and three verbs: Approve · Discuss · Dismiss (T1.2).
suggestion · next step (as a label)
checkpoint
The pause before anything external: allow once · always allow (scoped) · deny (INV-1).
confirmation · permission prompt
Routine
A scheduled, checkpointed automation. One execution is a run; runs pause at checkpoints.
playbook · workflow
Goal
An outcome + success checks + a budget the agent works toward unattended (T4.3).
task · mission
verified done
Completion confirmed by the independent verifier with expandable evidence (T3.1, INV-9).
done ✓ (without evidence)
Connector
A linked external tool — Gmail, Slack, Salesforce, Jira, Databricks — via OAuth.
integration · app (for connections)
Vault
Where secrets and API keys live — encrypted per user, masked in the UI.
keychain · credentials store
Recap
The structured summary an agent produces after a Call.
huddle notes · meeting summary
Library
A member's collection of Skills, Apps, and Dashboards — shareable to the workspace (T2.5).
marketplace (that's the public one)
ai.com · Product spec & backlog · v2 · July 2026 · Internal · Confidential — companion to roadmap-deck.html (strategy) and roadmap-content.md (evidence anchors). Mockups are directional, not final design; wireframes are structure only; data contracts are proposals pending confirmation against the codebase.