Onboarding for agent-carrying users: can an unauthenticated agent create an account?

**From the same 2026-09-15 strategy conversation as #1/#2 (agents-in-tow as the primary market).**

## The idea

Someone arriving with an agent already open (Claude, ChatGPT, etc.) may never touch flashkarte's signup form directly — they'd want to tell their agent "sign me up for flashkarte and start building me a course" and have the agent do it. Today the MCP server assumes an already-authenticated, already-scoped API key; there's no path for an *unauthenticated* agent to create an account on a user's behalf.

That's meaningfully more surface area than currently exists: account creation, email verification, and initial API-key issuance would all need an MCP-reachable (or MCP-adjacent) path, which also means thinking hard about what an agent should be allowed to do *before* a human has verified anything.

## Why this matters

If the landing page's core pitch is "hand this to your AI," the actual first interaction — creating the account — is currently the one thing that still requires the human to leave their agent and go fill out a web form. That's a gap between the marketing promise and the real flow.

## Decisions to make

- **Should this exist at all, or is "human signs up once, then hands the agent a scoped key" an acceptable permanent pattern?** (This is the safer default — worth deciding explicitly before building anything.)
- **If built: what's the trust boundary?** An unauthenticated MCP endpoint that creates accounts is a spam/abuse vector; would need rate limiting, CAPTCHA-equivalent, or email verification before any deck/course capability unlocks.
- **What's the minimum an agent needs before it's useful?** E.g. maybe the real fix is just a *very* frictionless human signup (magic link, no password) that an agent can walk the user through conversationally, rather than the agent doing it unsupervised.

## Reuse

None yet — this would be new surface area (`packages/server`'s auth domain, `packages/mcp`'s tool registration for pre-auth operations). Flagging as an idea, not scoping a build.

Start by reading the authentication domain in packages/server and the tool registration in packages/mcp. Decide whether unauthenticated account creation should exist, define the trust boundary and pre-verification capabilities, and document the minimum viable onboarding flow before implementation is scoped.

Written by the indexing model from the issue text.