/60 Chat — Full Experience Plan
The goal: every feature 60 has — 40 canonical MCP functions, the skill registry, meeting intelligence, ops tables, the brain, voice — reachable and genuinely useful from one chat surface, in the V3 stream design. This plan turns the working prototype (live gateway, 11 tools, stream UI) into the complete product experience.
1. Where we actually are
Working today (prototype at localhost:5181): V3 stream shell (headline answers, evidence racks, receipts, deck, canvas, composer, living dot field) · live MCP via gateway tools/call with 11 production tools · honest narration + insight headlines from real data · sim fallback · browser-speech voice fallback.
The two structural gaps:
- Raw tools ≠ the copilot brain.
tools/callgives us data reads, but the real product intelligence — skill orchestration, write workflows with approvals, artifact generation, structured response envelopes, memory — lives behind/api/chat(session JWT, the same path the production app uses). The prototype currently re-implements a tiny router client-side; that will never reach parity with 48 response types. - Cards are terminal. A meeting card that says "Open in App" is a dead end. Every entity needs a destination inside the chat — the canvas as a full workspace (watch, transcript, query, edit), not a bigger card.
The architecture decision that follows: two integration tiers, used together —
| Tier | Endpoint | Auth | What it's for |
|---|---|---|---|
| T1 — Tools | POST /mcp tools/call |
sk-sixty key | Fast reads, narration receipts, canvas data (transcript pages, table rows), anything deterministic |
| T2 — Copilot | POST /api/chat[/stream] |
user JWT | The brain: intent → skills → structured CanonicalResponsePayload → archetype adapters; all writes (approval envelopes); artifacts |
Chat turns route T2-first (full intelligence), and the stream's narration + source chips come from the tool telemetry T2 already emits. T1 stays for canvas interactions (paging a transcript, sorting a ledger) so they're instant and don't burn a model call.
2. Meeting experience — the flagship canvas
A meeting query renders the meeting rack card; opening it launches the Meeting Canvas (the 50% GPT-style panel / full-screen on mobile) with four tabs:
▶ Watch. The recording player (Recall/loom-style URL from the meetings domain) with chapter markers generated from intelligence moments (decisions, objections, commitments). Clicking a moment seeks the video.
≡ Transcript. Full transcript, virtualised, speaker-coloured, searchable (sixty_get_meeting_transcript_context supplies bounded excerpts; a T1 paging call fetches segments). Every paragraph has a timestamp — click seeks the video tab. Selection → "Ask about this" (quotes the excerpt into the composer as a context chip).
✦ Intelligence. The structured read: key decisions, commitments (each with "Draft the follow-through" action), objections with clips, outcome signals, competitor mentions, sentiment arc. This is sixty_get_meeting_intelligence rendered properly — not three KV tiles.
⌕ Ask. A scoped mini-stream inside the canvas: questions answered only from this meeting's transcript + intelligence ("what did Jay say about pricing?" → answer with timestamped quotes that link into Watch/Transcript). Implemented as T2 chat with the meeting pinned as a context chip — same envelope, rendered in the canvas.
The stream stays terse (headline + rack); depth lives in the canvas. This pattern then repeats for deals (timeline/emails/calls tabs) and contacts.
3. Ops tables — create, run, live
"Build me a table of fintech CTOs in London" →
- Clarify row (columns/source/size) if underspecified — one quiet prompt row.
- Approval card (it's a write + credits): source, column set, row estimate, cost.
- Job receipt — creation is long-running:
receipt-progresswith live row count ("Ops table building — 84/240 rows · Apollo"). - The Ops Table Canvas — the Ledger grown up: virtualised rows, column sorting/filtering as T1 calls, per-cell enrichment status, row → contact canvas. Header actions: add column ("add a 'raised last round' column" via chat), export, start a campaign from selection.
- The table is an artifact — pinned, versioned, reopenable from history; "start the outreach for rows 1–20" flows into the campaign workflow checklist.
Backed by the existing ops stack (/build-ops-table, OpsTableInlinePreview, Ops*StatusResponse shapes, webset radar) — the chat becomes the front-end for machinery that already exists.
4. Full MCP + skills coverage — the contract
Every one of the 40 canonical tools and every skill maps to one archetype + optionally one canvas. The complete matrix:
| Capability family | Tools (examples) | Stream archetype | Canvas |
|---|---|---|---|
| Meetings | search_meetings, get_meeting_prep/recap/intelligence, transcript_context, calendar_health | Rack (violet) | Meeting Canvas |
| CRM reads | search_records, record_timeline, account_context, relationship_map | Rack ≤6 / Ledger ≥7 | Deal / Contact Canvas |
| Pipeline & manager | pipeline_health, forecast_risks, rep_activity, team_coaching, targets_progress | Stat rack + one chart | Report Canvas |
| Outreach & growth | find_leads, enrich_contact, campaign_health, draft_followup, draft_sequence | Job receipt → Ledger / Draft Sheet | Ops Table / Campaign Canvas |
| Writes | plan_action, check_permission, run_write_workflow | Approval card (blue, single-use server approvals; email = Gmail draft, stated verbatim) | — |
| Context & brief | get_context, org/user_brief | Source chips + morning brief entry | Brain panel |
| Learning | record_proof/outcome, learn_from_outcome | Invisible — fired on approve/edit/reject | — |
| Discovery | discover_tools, find_best_tool, classify_request | Clarify row / intent routing | — |
| Skills/ops | load_skill, list_playbooks, integration/agent_health | Slash palette + status receipts | — |
Skills: the slash palette reads the real platform_skills registry (T1 sixty_load_skill / command_centre list). Every skill's output must arrive as a canonical envelope → archetype; the five categories (writing / research / pipeline / outreach / coaching) each get one reference skill fully wired first (e.g. /follow-up, /prep-me, /pipeline-review, /build-ops-table, /deal-risk) to prove the category's path, then the long tail is config, not code.
5. The brain
- Context chips get real: backed by conversation memory + brain recall — chips show what 60 actually retrieved (meeting, deal, org brief, memory fact), removable, inspectable (click = "why do you know this?").
- Brain panel (third section of the old landing): "what 60 learned today" receipts — corrections you made, preferences captured, per-domain autonomy shifts. One tap to forget any item.
- Morning brief = brain synthesis: overnight
didreceipts + judgement deck + brief entry #1 assembled server-side, delivered as one envelope. - Learning loop wired to UI: every Approve/Edit/Reject on deck and approval cards fires
sixty_learn_from_outcome— the confidence dials genuinely move over time.
6. Voice, done properly
Mint at /api/realtime-session with the JWT; server-side instruction composition at mint (user/org/meeting context — the known gap from the launch audit). Tool calls from the voice model surface in the stream as the same narration + rack cards in real time; approvals spoken ("shall I send it?") still render the blue card — voice never bypasses the approval envelope. Hang-up leaves the full transcript as stream entries.
6.5 Locked decisions — showcase review, 6 Jul
Andrew reviewed six working demo flows in the prototype and locked the direction:
- Ops table: the Fable reveal wins. Approval opens the FULL-SCREEN table while it builds — rows materialise live, cells resolve in enrichment waves, header counter runs. Hybridised with the Opus build's information rigour: sortable columns with affordances, Score/signal filter chips + the clickable score histogram, status column, search, Export, selection footer with live credit cost. "There is a place for both" — the calm progress-receipt flow remains the pattern for background/long jobs the user chooses not to watch.
- Ops tables are full-screen page takeovers, never side canvases. Back-to-chat returns to the stream untouched.
- Proactive brain insight (pulse → insight entry → provenance sheet), meeting intelligence report (editorial brief), meeting analytics chart, and the ops follow-ons (add-column job, outreach → living checklist) are all approved as built — they become the reference implementations for their archetypes.
- The six demo modules in the prototype ARE the Phase spec — port fidelity is measured against them.
7. Delivery plan
Phase A — T2 spine (the unlock). Wire /api/chat with JWT into the prototype: envelope → archetype adapter (headline/receipt/sources synthesized client-side until the envelope addition lands server-side). All 48 response types render at least as an honest generic card day one; the 12 archetype adapters then claim them family by family. Everything else depends on this.
Phase B — Meeting Canvas. Watch + Transcript + Intelligence + Ask tabs. Uses T1 transcript paging + T2 scoped ask. This is the "wow, it's useful" milestone.
Phase C — Ops Tables. Clarify → approval → job → Table Canvas with T1 sort/filter/enrich; artifact pinning.
Phase D — Skills + writes. Real slash registry; five reference skills; approval cards against real run_write_workflow with server single-use approvals; Draft Sheet → real Gmail drafts.
Phase E — Brain + proactive. Real deck from the command-centre queue; pulse toasts; brain panel; learning-loop wiring.
Phase F — Voice. Real mint + composed instructions + streaming tool cards.
Phase G — Port to /60. The prototype is the contract; port onto the stream PRs already open (#2395 tokens / #2396 composer / #2397 StreamView) as Phase-3 archetype adapters in React, one family per PR, flags off, mobile CI invariant enforced.
Dependencies to unblock early: (1) a JWT path for the prototype (paste-in now; a dev login later); (2) the gateway envelope additions (headline, receipt, sources[]) — one additive PR; (3) recording URL + transcript paging exposure through a T1 tool if not already present; (4) /api/chat/stream restoration (known 404 from the revert) for live narration.
Prepared 6 Jul 2026 · builds on the V3 stream design system and the live prototype · companion doc: /60 Stream Redesign — Full Plan.