From a strategy conversation on 2026-09-15, right after shipping the landing page's AI-native pitch (#see 9fec9af). Chris's framing: "we need to build things for a different world, one where AI is ubiquitous, and we need to assume all users are going to be arriving w AI agents in tow. that's going to be our market."
The idea
If most users show up with an agent already attached, the MCP surface (packages/mcp) stops being a secondary integration bolted onto the real app and becomes the primary way the product gets used — with the web/Android UI serving as the human's window into what their agent already did, not the main entry point.
Concretely, that reframing would mean the build priority order flips: MCP tool coverage and prompt quality (build_a_course and friends) have to be complete and load-bearing first, ahead of parity UI work, because that's the surface most usage will actually flow through.
Why now
The landing page just started explicitly pitching "hand it to your own AI" as the primary path rather than a footnote. This issue is the natural follow-up: decide whether that's just marketing framing or something that should actually change how work gets prioritized and staffed across packages/mcp vs packages/web / android/.
Decisions to make
- Is this a prioritization shift or a literal architecture shift? Does anything about the current split (server owns logic, web/Android/MCP are three thin clients) actually need to change, or is this purely about which client gets attention first?
- What does "MCP-first" mean for feature sequencing going forward? E.g., should new features (after Courses) ship MCP tools + prompt before or alongside UI, rather than UI-first as most features have shipped so far this cycle?
- Does this affect how
build_a_course and future guide prompts get scoped? If an agent is doing most of the driving, prompt quality is closer to "the product" than any individual screen.
Reuse
No new capability needed to start — packages/mcp already exists and is functionally complete for decks/courses/study. This is a sequencing and prioritization decision, not a build.
From a strategy conversation on 2026-09-15, right after shipping the landing page's AI-native pitch (#see 9fec9af). Chris's framing: "we need to build things for a different world, one where AI is ubiquitous, and we need to assume all users are going to be arriving w AI agents in tow. that's going to be our market."
The idea
If most users show up with an agent already attached, the MCP surface (
packages/mcp) stops being a secondary integration bolted onto the real app and becomes the primary way the product gets used — with the web/Android UI serving as the human's window into what their agent already did, not the main entry point.Concretely, that reframing would mean the build priority order flips: MCP tool coverage and prompt quality (
build_a_courseand friends) have to be complete and load-bearing first, ahead of parity UI work, because that's the surface most usage will actually flow through.Why now
The landing page just started explicitly pitching "hand it to your own AI" as the primary path rather than a footnote. This issue is the natural follow-up: decide whether that's just marketing framing or something that should actually change how work gets prioritized and staffed across
packages/mcpvspackages/web/android/.Decisions to make
build_a_courseand future guide prompts get scoped? If an agent is doing most of the driving, prompt quality is closer to "the product" than any individual screen.Reuse
No new capability needed to start —
packages/mcpalready exists and is functionally complete for decks/courses/study. This is a sequencing and prioritization decision, not a build.