Strategy: in-app AI course builder for users without an agent of their own

[johnfire]

From the same 2026-09-15 strategy conversation as #140/#141/#142. Chris: "im already seriously thinking og building in an AI (using API key) that can, in app, build a new set of decks for a user that doesnt have AI. it would interview the user, find out what they desire to learn, then build a custom course for the user."

The idea

An in-app AI, paid for with flashkarte's own API key rather than the user's — the second of two ways to be "AI-native" (see ~/Downloads/mcp-app-guide-pattern.md's BYOA-vs-built-in split). It would interview a user with no connected agent of their own ("what do you want to learn?"), then drive the same course-building service that build_a_course already drives over MCP, to produce a real course.

This isn't a competing bet against #140's MCP-first direction — it's the mass-market front door next to it. #140-142 assume the user already has a capable agent in tow; most people arriving at flashkarte in 2026 don't. Two front doors, one service layer: BYOA/MCP for users who bring an agent, in-app AI for users who don't.

Why this matters

The AI-native pitch on the landing page only reaches users who already have an AI to hand it to. Without an in-app option, everyone else still has to build decks by hand — which undercuts the pitch for exactly the audience that would benefit most from it (people who don't already have an agent workflow, i.e. most non-technical users).

Decisions to make

• Grounding. The landing page's core claim is "grounds content in real sources, doesn't make facts up." An open-ended interview ("what do you want to learn?") starts with no source material — the AI would be generating from its own knowledge, the exact case the pitch says it avoids. Resolve by having the interview end in a real source (link, pasted notes, a syllabus) before building, or by explicitly labeling unsourced cards as "built from the model's own knowledge, verify as you go."
• Cost model. This is flashkarte's first standing LLM opex line — today, inference cost is entirely offloaded onto whatever agent the user brings via MCP. An in-app builder means flashkarte pays per interview/course-build. Needs a cost-control story (rate limits, plan tiers, caching) before shipping, not after.
• Which model powers it. Raised but not resolved in the source conversation — Opus and Fable were both floated. This is a separate question from "should another model help brainstorm the design" (decided: no, not needed yet) — it's about what actually runs in production.
• Report-back applies here too. Same trust-layer need as Agent report-back: structured summary after MCP-driven course/deck builds #141 — a user who wasn't part of a live chat with the in-app AI still needs a legible account of what it built and why, probably more than an MCP-driven build does, since there's no existing chat transcript for the user to scroll back through.

Reuse

Builds on the same course-building service layer already speced caller-agnostic in docs/plans/2026-09-15-courses-design.md — this would be a second caller alongside the MCP tool, not a rewrite. See also ~/Downloads/mcp-app-guide-pattern.md's "Open question: is BYOA still the default" section for the fuller framing.