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

**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 #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.

Start by reading docs/plans/2026-09-15-courses-design.md and the existing build_a_course MCP entry point to understand the caller-agnostic service boundary. Resolve the grounding, cost, production-model, and report-back requirements before proposing the in-app caller; done means those decisions are documented and the scope is actionable.

Written by the indexing model from the issue text.