How I turned a static site into a fully agentic AI course site using MCP and AI agents First Break AI built a fully agentic AI course site using Quarto for static content and an MCP server for AI agent interactions. The site serves pre-rendered HTML via Cloudflare Pages while agents handle context-aware answers, progress tracking, and validation through a CLI and on-site widget. This architecture separates content from agency, allowing learners to interact with the course via multiple surfaces without sacrificing speed or SEO. When we started building First Break AI https://cohort.bubblnet.com , 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 https://quarto.org . 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. 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. 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 https://cohort.bubblnet.com/roadmap or a lesson on Hugging Face https://cohort.bubblnet.com/lessons/lesson-1-huggingface-beyond-upload , 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 https://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 https://www.npmjs.com/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: firstbreakai validate 1 runs local rubric checks → results can sync to their profile if they are logged in. ask , find , validate , and next tools the cohort exposes everywhere else.Same brain, many surfaces. The site stays static. The agents are shared infrastructure. 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: