Give Kortex a topic, a target audience, and whatever source material you have on hand: a PDF, a YouTube link, or nothing more than the topic itself. A few minutes later you have a full course: modules ordered from easiest to hardest, lessons with diagrams the model chose to draw, and a quiz gating every module so nobody advances by clicking fast.
That's Kortex, and it's done. Three AI agents build the course. I built everything else by hand.
How a topic becomes a course
An admin starts it: title, description, target audience, and optionally a few source materials. From there it's a fixed pipeline, three agents, each with one job.
The Architect goes first. It researches the topic, using web search plus whatever materials were supplied, then designs the whole course structure at once: modules and lessons ordered by Bloom's Taxonomy (Remember, Understand, Apply, Analyze, Evaluate, Create), plus a quiz outline for each module.
The Author writes the lessons, one agent invocation per lesson, running in parallel. Each one comes out as MDX with inline Mermaid diagrams and tables where they help, grounded in what the Architect found during research rather than whatever the model already "knew" about the topic.
The Quizmaster writes the actual questions for each module's gatekeeper quiz, the thing standing between a learner and the next module.
None of this happens inside the request that creates the course. It's a background job pipeline: an 18-lesson course takes a few minutes to generate, and none of those minutes block the admin's browser. The pipeline doesn't know anything about any particular subject. The same code has generated working courses in biology, genetics, web development, and machine learning without a single line of per-subject logic anywhere.
What I let the AI build, and what I didn't
AI assistance was used for frontend development only as my design skills are exceptional :) The FastAPI service, the Inngest pipeline, the Prisma schema, and the tRPC routers were all hard coded. I used AI as a mentor while building the backend, not as the thing writing it.
That's an odd thing to admit about a project whose entire premise is "AI writes your course for you," but it was deliberate. The pipeline is the part I wanted to understand completely: the retry behavior, the fan-out, the shared-secret auth between two services that don't otherwise trust each other. In case I decide to deploy in production and pipeline breaks at 2am, I want to already know why, not go spelunking through code I never actually wrote.
What's actually shipped
On the admin side, creating a course means watching it get built: module and lesson counts ticking up, a live log of every research query the Architect runs, and a way to expand any generated lesson's MDX inline before publishing. There's a course list with publish status and enrollment counts, platform-wide analytics (user growth, XP distribution, course popularity), and a per-learner drill-down showing XP, streak, badges, and activity over time.
On the learner side, the catalog is searchable by category, and a course's detail page shows the entire module and lesson list before you enroll, not just a marketing description. Lessons render as formatted MDX with headings, tables, callouts, and whichever diagram type the model picked for that lesson: flowcharts, timelines, state diagrams. Finishing a lesson pays out XP. There's a streak, levels, badges, and a leaderboard. And a module's quiz has to be passed, server-side as well as in the UI, before the next module opens.
What doesn't work yet
- No email or reminder system. It was planned. It was never started.
- No generated video. Diagrams are Mermaid only, on purpose, not as a placeholder for something fancier later.
- No self-serve course creation. Only an admin can start a course; there's no "generate your own" button for learners.
architect.pyandauthor.pyinapps/core/app/agents/are an older, pre-Inngest version of the same two agents. Only their course-deletion cleanup path and a fallback that's unreachable outside a misconfigured production setup are still wired in. They haven't gotten the fixes the real pipeline has since, and I'm not extending them.
The rest of it
This post is the what and why. The how, the event pipeline between the two services, the actual retry and concurrency numbers, and the one Postgres decision I keep re-explaining to people, is its own post: why my AI backend is banned from touching the database.
Why My AI Backend Is Banned From Touching the DatabaseHow Kortex's FastAPI agents get their output back into Postgres without ever touching the database themselves, routed through Inngest events and a shared-secret internal API on the Next.js side.Kortex is AGPL-3.0. Source, setup steps, and the license are all in the Kortex repo, leave a star if you loved it!!