When we started building First Break AI, we had a constraint that turned out to be an advantage: we wanted a real course site — lessons, blogs, office hours, a roadmap, docs — but we did not want to run a full web application just to serve content. No LMS. No Next.js rewrite of a curriculum. No server rendering pages on every request. Static sites are fast and cheap,but they can't interact with your site visitors, answer questions, or help them in their journey. We realized we need to stop treating AI as a FAQ bot — instead treat it as an agentic layer that runs your full site.

We chose Quarto. You write .qmd files, run quarto render, and get static HTML. We deploy that output to Cloudflare Pages. Pages load fast. URLs stay clean. Everything lives in Git. Learners can fork the repo and follow along. For a free, open cohort, that foundation was exactly right.

But this static site had the same problem, It does not remember who you are & cannot check your progress or tell you what to do next. Paste a generic chatbot widget on top and you get answers — but not answers grounded in your content, and certainly not an agent that can validate your repo or sync progress across your terminal and your browser.

So we asked a different question: what if the site stayed static, and AI agents became the dynamic layer on top?

That is how First Break AI became what we call a fully agentic cohort — not because we replaced the site with agents, but because agents now answer questions in context, validate work against rubrics, track progress, and show up inside your IDE. The HTML is still plain Quarto output. The learning experience is not.

The problem with "AI-powered" courses

Most "AI-powered" courses mean one of two things: a chatbot that knows nothing about the course, or a platform that locked you into their stack from day one.

We wanted neither. We wanted learners to read lessons as fast static pages, ask "what is GGUF?" and get an answer from our lesson content, run a command in the terminal to see if Step 1 actually passed, and install the same tools in Cursor that we use in office hours. Same cohort, same rubric, whether you are on the website, in the CLI, or pair-programming with Claude.

That required an architecture where content and agency were separate — and deliberately connected.

How the pieces fit together

Think of it in two layers.

The content layer is boring in the best way. Quarto builds the site. Cloudflare Pages serves it. When you open the roadmap or a lesson on Hugging Face, you are reading pre-rendered HTML. Google sees real text. There is no JavaScript required to read the lesson. That matters for speed, for accessibility, and for SEO.

The agentic layer sits beside that content, not inside it. A Cloudflare Worker hosts our MCP server — the Model Context Protocol endpoint that AI assistants call when they need cohort tools. FetchLens.ai powers the on-site "Ask Anything" widget and gives us observability into how agents use the site. A small npm package, @aiedx/firstbreakai, gives learners a CLI and a local MCP server for offline checks. Discord OAuth ties identity together: log in once, and the same learner record follows you on the site, in the terminal, and in the widget.

Nothing in that second layer replaces Quarto. We did not convert .qmd into React components or move lessons into a database. We added connective tissue — HTTP endpoints, scripts, and tools — so static pages could talk to agents that actually do things.

Here is the flow in plain language:

1. A learner reads a lesson (static HTML, fast).
2. They have a question → the FetchLens widget calls the Worker → the agent answers from cohort knowledge, not the open web.
3. They finish the exercise → firstbreakai validate 1 runs local rubric checks → results can sync to their profile if they are logged in.
4. They work in Cursor → the remote MCP URL gives their IDE agent the same ask, find, validate, and next tools the cohort exposes everywhere else.

Same brain, many surfaces. The site stays static. The agents are shared infrastructure.

Layer by layer — what we actually built

Ask Anything on every page

The lightest entry point is the widget. After Quarto renders a page, we include a deferred script that mounts a floating "Ask Anything" button. It points at our FetchLens-backed endpoint on the Worker. From the learner's perspective, it feels like a tutor that has read the entire cohort — because, in effect, it has.

We did not change how Quarto builds pages. We only added an include at the site level:

<script src="/public/scripts/fba-lens-widget.js" defer
  data-endpoint="https://fba-mcp.throbbing-thunder-4d33.workers.dev/widget/mcp"
  data-button-label="Ask Anything"></script>

Static delivery unchanged. Agent loads asynchronously. If the script fails, the lesson still works.

MCP in the IDE

The same Worker exposes a public MCP server over HTTP. If you use Cursor, Claude Desktop, Claude Code, or OpenAI Codex, you paste one URL and your AI assistant gains cohort tools: ask questions, find lessons, validate submissions, suggest next steps.

For Cursor, the config is a few lines in ~/.cursor/mcp.json:

{
  "mcpServers": {
    "fba-cohort": {
      "url": "https://fba-mcp.throbbing-thunder-4d33.workers.dev/mcp"
    }
  }
}

This was the moment the cohort stopped being "a website you visit" and became "infrastructure your agent can call." A learner debugging their Quarto blog in Cursor can ask their agent to check cohort requirements without switching tabs. That is agentic learning in practice — not a chatbot on a sidebar, but tools wired into where people already work.

A CLI that validates for real

Some checks should not be left to an LLM's judgment. Step 1 asks you to ship a Quarto blog on GitHub. Did you create _quarto.yml? Is there a .qmd file? Is the Git remote pointing at GitHub? Those are file-system facts. We encode them in rubrics and run them locally:

npm install -g @aiedx/firstbreakai
firstbreakai doctor      # Git, Python, Quarto, HuggingFace CLI — env sanity
firstbreakai validate 1  # rubric checks for Step 1
firstbreakai status      # where you are on the roadmap
firstbreakai mcp         # local MCP server for your IDE

AI agents handle open-ended Q&A. Rubrics handle pass/fail. That split keeps validation honest — no hallucinated "looks good to me" — while still letting agents guide learners through ambiguity between steps.

The CLI also publishes as @aiedx/firstbreakai on npm, so npx @aiedx/firstbreakai doctor works without a global install. Same package, same MCP tools, whether you prefer terminal or IDE.

Identity without turning the site into an app

Static sites do not have sessions. We did not want to bolt on a Node backend just for login. Discord OAuth runs on the Worker: click "Log in" in the navbar, authenticate, store a token in localStorage, and the widget and CLI can both use that identity. Progress — which steps you validated, which lessons you marked complete — lives in D1 behind the Worker.

The Quarto repo still builds the same HTML for everyone. Auth is an overlay. That was important to us: the curriculum stays open and forkable; personalization is optional, not a paywall.

What we deliberately did not do

We did not rebuild the cohort in React or Next.js. Quarto was the right tool for long-form lessons and a blog-shaped learning path.

We did not embed a generic ChatGPT iframe and call it "AI-powered."

We did not hide lessons behind login. Materials are public. Discord and auth exist for community and progress, not for gating content.

We did not try to make the static site "smart." We made agents smart, and pointed them at static content.

Why this stack held up in production

Speed stayed good because agents load after content. SEO stayed good because crawlers get full HTML, JSON-LD for the course, and FAQ schema on the homepage — not an empty shell waiting for JavaScript.

Cost stayed low: Cloudflare Pages for static files, a Worker and D1 for the agentic layer. No always-on app server for lesson delivery.

Most importantly, the model scaled with the cohort. Adding a lesson is still "write a .qmd, render, deploy." Adding agent capability is "expose a tool on the MCP server or extend a rubric." Content and agency evolve on separate tracks, which is how a small team can run a cohort without drowning in infrastructure.

Quarto is the content machine. AI agents are the learning machine. Together they are closer to a teaching assistant that scales than a video platform with a comment section.

If you want to try it

First Break AI is free — no applications, no prerequisites. Cohort 01 runs May through July 2026; everything stays online after that.

Start with the roadmap or Lesson 0. Install the CLI with npm install -g @aiedx/firstbreakai. Add the MCP server to your IDE. Join Discord if you want humans in the loop too.

We are still iterating — roadmap checkmarks when you are logged in, more validation rubrics, deeper FetchLens observability on agent traffic. But the core idea is stable: static site for content, agents for everything that needs to act.

If you are building something similar — MCP, agentic tooling, static sites that need to feel alive — I would genuinely like to hear how you are approaching it. And if you are looking for your first break in AI, the cohort is open.

First Break AI is built by AIEdx. Agentic infrastructure is powered by FetchLens.ai.