Running a Chess YouTube Channel entirely by AI — Stephan Steinfurt, TNG

At-a-Glance

• Verdict: Watch fully
• Core thesis: An AI agent system built on Gemini 3.1 Pro + chess engines + structured tools can autonomously produce high-quality chess educational videos from Lichess games, analyzing positions, generating narration, and uploading nightly without human oversight—at ~20-30 cents per video.
• Why it matters: This is a working example of agentic AI generating monetizable, domain-specific content at scale; it demonstrates tool-use patterns, cost structures, error rates, and trade-offs in human-in-the-loop vs. full automation that apply to Ken's agent systems, content automation, and AI-native product thinking.
• Best use: Study the architecture (LLM + chess engine + CCT tool + conflicting info strategy) as a template for multi-tool agent design; note cost/error trade-offs and the shift from Python scripts to reasoning-model-driven tool orchestration; consider parallels for AI-generated analysis/content in other verticals.

Executive Summary

Stephan Steinfurt and his team at TNG have built an end-to-end AI pipeline that downloads chess games from Lichess nightly, analyzes them using a custom agent, and uploads fully narrated, visually annotated chess tutorial videos to YouTube—all without human intervention. The system uses Gemini 3.1 Pro (chosen for its superior chess understanding after post-training) as the reasoning core, supplemented by a suite of tools: legal move validation, chess engine evaluation, checks-captures-threats (CCT) analysis, Maia engine (for human-like move prediction), board state manipulation, and optional web search for historical context. The agent decides which moves to highlight, which arrows to draw, which positions to call 'brilliant' or 'blunder,' and generates the script that ElevenLabs v3 TTS converts to audio. The result is videos like the two-minute tactical breakdown shown in the talk, which explain complex chess positions with narrative arc, emphasis cues (e.g., 'excited'), and multi-variation analysis.

The key architectural insight: the team initially used Python scripts to assemble chess data and feed structured prompts to an LLM, but with reasoning models (O1, Gemini Flash Thinking, Grok 4—Grok 4 was the best before Gemini 3.1), they shifted to letting the agent think and call tools itself. This delegation increased quality and flexibility. The agent is intentionally given conflicting information (best engine move vs. human-likely moves, checks vs. captures) so it can reason about what a human viewer might consider and explain why certain intuitive moves fail. The CCT tool, for example, lists all checks, captures, and threats in a position; some are obviously bad, but the agent uses that diversity to explain common misconceptions—e.g., in the example shown, the best move is a non-obvious rook sacrifice, but the agent can discuss why checking moves look tempting yet fail.

The channel has grown to 4,000+ subscribers and ~500k views, mostly in the past month. Each video costs 20-30 cents in API calls; longer, more in-depth videos can cost a few euros. The error rate is ~1 in 20 videos (e.g., missing a checkmate or a bad tool call), which Steinfurt considers acceptable for automated upload. The team has not yet monetized (below YouTube's threshold) and is still deciding whether to review every video or trust full automation. Trade-offs include cost optimization (redundant tool calls, agent re-analyzing games) vs. quality, and audience targeting (checkmate-in-one is trivial for strong players but valuable for beginners). The system is positioned not to compete with top streamers like GothamChess, but to scale personalized analysis—users could submit their own games and receive custom videos. The German newspaper Süddeutsche Zeitung called the approach 'the holy grail of chess programming,' quoting chess researcher William Weber, because the system explains chess as well as a human trainer—a milestone traditional engines never achieved.

Key Takeaways

• Claim: Gemini 3.1 Pro is the best LLM for chess understanding due to post-training, outperforming previous models and enabling agent-driven tool orchestration. | Evidence: Steinfurt: 'Gemini 3.1 Pro, which recently came out, is actually the best model I've seen so far on chess. I'm pretty sure they've done some in-depth post training on the model. And you can really see in the reasoning traces that it really understands chess a lot better than the previous models.' Before Gemini 3.1, Grok 4 was the best, used in autumn 2023. | Caveat: No public confirmation of post-training from Google; Steinfurt's assessment is based on observed reasoning quality and tool-use behavior, not documented training details. | Implication: For domain-specific agent systems, model selection should prioritize domain understanding (via fine-tuning or post-training) over general benchmarks; reasoning traces are a useful diagnostic for model fit. | Timestamp: timestamp unavailable
• Claim: Shifting from script-driven analysis (Python assembles data, LLM narrates) to agent-driven tool use (LLM reasons and calls tools) dramatically improved quality and flexibility. | Evidence: Steinfurt: 'When we started this whole project, we initially had some Python scripts which would analyze a chess position and would then assemble information... But what changed last year when reasoning models came out was actually that the agents could rather think themselves about the positions. And they were already pretty good.' The agent now decides which tools to call, which variations to explore, and how to explain. | Caveat: Reasoning models are more expensive and can make redundant tool calls (e.g., analyzing the same game twice), which the team has not yet optimized for cost. | Implication: For Ken: reasoning-model-driven agent design can replace hand-coded orchestration logic, but cost/efficiency trade-offs remain; the pattern is to provide tools and let the model decide, rather than pre-compute everything. | Timestamp: timestamp unavailable
• Claim: Providing conflicting or diverse information (best move, human moves, checks, captures, threats) helps the agent explain common human misconceptions and create richer narratives. | Evidence: Steinfurt: 'The checks, captures, and threats tool... we are giving the LLM now in this situation is not only the best move, but we are giving it also access to the checks, captures, and threats... this kind of conflicting information which we provide via the tools is actually very beneficial. So we also have other kind of tools which are more geared towards getting out the more human moves... that also helps to balance the description of not being too much focused on the best moves but also on the most human moves.' Example: in the complex endgame shown, the best move is a non-obvious rook sacrifice, but the agent can discuss why obvious check moves fail. | Caveat: The Maia engine (used for human-like moves) is 'not perfect'; it approximates moves for a given rating but doesn't guarantee human-like reasoning. | Implication: For agent design: deliberately including suboptimal or alternative data can improve explanatory quality and user engagement; don't just feed the agent the 'correct' answer. | Timestamp: timestamp unavailable
• Claim: The system runs nightly, fully automated, with an error rate of ~1 in 20 videos; Steinfurt is moving toward full trust and post-hoc review rather than pre-publication screening. | Evidence: Steinfurt: 'We are automatically creating these videos every night and uploading them to YouTube... I would say every 20th video maybe has a very weird description in which there's, I don't know, a checkmate and that's missed or something like that... I've actually much more now switched to okay, I don't care anymore. And even if there's a bad video, then I'll take it down afterwards maybe.' He initially wanted to review every video but now accepts occasional errors as part of scaling. | Caveat: Errors include missing checkmates or bad tool calls; error diagnosis (e.g., missing tool call at the end) is valuable for iteration but not yet eliminated. No formal error-handling or quality gates are described. | Implication: For AI content systems: a 95% success rate may be acceptable for scale if errors are non-catastrophic and post-hoc fixable; the shift from 100% human review to spot-checking is a key scaling threshold. | Timestamp: timestamp unavailable
• Claim: Each video costs 20-30 cents in API calls; longer, more complex videos cost a few euros; the channel is not yet monetized but has 4,000+ subscribers and 500k views, mostly in the past month. | Evidence: Audience question on cost; Steinfurt: 'It's something on the order of 20, 30 cents... we also have created a couple of other videos which are much, much longer. And there it can also get to euros and something like that.' On monetization: 'Currently we don't make any money yet because we haven't reached the monetization stage yet. And so it's net minus at the moment.' Growth: '500k views... more than 4000 subscribers. Most of them actually were subscribed within the last month.' | Caveat: Cost estimates exclude infrastructure, Lichess data access, hosting, and human review time; only API calls (Gemini, ElevenLabs) are counted. YouTube monetization requires 1,000 subscribers + 4,000 watch hours (or 10M Shorts views in 90 days); they recently crossed the subscriber threshold but watch hours are unclear. | Implication: Unit economics are viable for scale if monetization kicks in; cost per video is low enough to support personalized content (e.g., user-submitted games) as a product; rapid subscriber growth suggests product-market fit. | Timestamp: timestamp unavailable

Detailed Brief

System Architecture: LLM + Chess Engine + Tool Suite

• Claims: The agent uses Gemini 3.1 Pro for reasoning, supplemented by a chess engine, legal move validator, checks-captures-threats (CCT) tool, Maia engine for human-like moves, board state manipulation, and optional web search.; The CCT tool lists all checks, captures, and threats in a position, including obviously bad moves, to give the agent a diverse set of candidate moves to reason about.; The agent decides which moves to highlight, arrows to draw, and which moves to label 'brilliant' or 'blunder'; it also generates the script with emphasis cues (e.g., 'excited') for TTS.; ElevenLabs v3 TTS converts the script to audio; visual annotations (arrows, highlights) are generated programmatically from the agent's structured output.
• Evidence: Steinfurt lists tools: 'legal moves, to just prevent it from ever thinking about something completely illegal... complete chess board... run a chess engine... checks, captures, and threats... web search.'; CCT tool example: in a complex endgame, the tool shows several check moves, some obviously bad (e.g., Qxa4), and the best move (rook sacrifice on e3); the agent uses this diversity to explain why intuitive moves fail.; Agent autonomy: 'the agent also decides by itself which squares it wants to highlight, which arrows it wants to draw and if something should be considered a brilliant move or not.'; TTS: '11labs v3 for text to speech... audio texts where you can put this excited in there and it would then sound excited.'
• Caveats: The team has not yet optimized for redundant tool calls (e.g., agent analyzing the same game twice), which inflates costs.; The Maia engine for human-like moves is 'not perfect' and only approximates play at a given rating.; No detail on video rendering pipeline (how arrows/highlights are composited, frame rate, resolution).
• Implications: The tool suite is a blueprint for multi-domain agent design: domain-specific oracle (chess engine), structured search (CCT), human-behavior model (Maia), and general reasoning (LLM).; The trade-off between cost and quality is managed by accepting some redundancy and not micro-optimizing agent behavior yet.; The system is modular enough to extend to other games, puzzles, or decision-analysis domains (e.g., poker, Go, military strategy).

Reasoning Model Shift: From Script Assembly to Agent Orchestration

• Claims: Initially, Python scripts analyzed positions, assembled data, and passed structured prompts to an LLM for narration; the LLM was a writer, not a thinker.; With reasoning models (O1, Gemini Flash Thinking, Grok 4), the team shifted to letting the agent think and call tools itself, improving quality and flexibility.; Grok 4 was the best model in autumn 2023; Gemini 3.1 Pro is now the best due to post-training on chess.; The agent now reasons about which positions to analyze, which variations to explore, and how to explain common mistakes.
• Evidence: Steinfurt: 'When we started this whole project, we initially had some Python scripts which would analyze a chess position and would then assemble information from various positions... And then we would pass it on to the language model to then have a whole description.'; Shift: 'What changed last year when reasoning models came out was actually that the agents could rather think themselves about the positions. And they were already pretty good. So the best model which we've been using in autumn last year was GROC 4.'; Current state: 'the agents could rather think themselves about the positions... the other models from OpenAI and so on, they also have quite some decent base chess knowledge to be able to then call the tools at the right position and then assemble all the knowledge.'
• Caveats: Reasoning models are more expensive and slower than prompt-based generation.; The team has not published reasoning traces or ablation studies comparing script-driven vs. agent-driven approaches.; No discussion of when script-driven is sufficient (e.g., for simple positions or tactical puzzles).
• Implications: For Ken: the shift from 'assemble data, prompt LLM' to 'give LLM tools, let it reason' is a general pattern applicable to research, analysis, and content generation agents.; Reasoning models unlock richer, more context-sensitive outputs but require accepting higher cost and some inefficiency.; The pattern suggests a two-tier architecture: reasoning model for high-value, complex tasks; cheaper models for repetitive or simple tasks.

Cost, Error Rate, and Scaling Trade-offs

• Claims: Each video costs 20-30 cents; longer videos cost a few euros; the team has not optimized for cost yet.; Error rate is ~1 in 20 videos (missing checkmates, bad tool calls); errors are usually diagnosable and inform tool/prompt improvements.; Steinfurt is moving from pre-publication review to post-hoc takedown of bad videos, accepting occasional errors for scale.; The channel is not yet monetized (below YouTube's threshold) but is growing rapidly (4,000+ subs, 500k views, mostly in the past month).
• Evidence: Audience Q&A: 'What is the cost of the video? It's something on the order of 20, 30 cents... we also have created a couple of other videos which are much, much longer. And there it can also get to euros and something like that.'; Error rate: 'I would say every 20th video maybe has a very weird description in which there's, I don't know, a checkmate and that's missed or something like that... that's usually also then valuable information.'; Trust shift: 'I've actually much more now switched to okay, I don't care anymore. And even if there's a bad video, then I'll take it down afterwards maybe.'; Monetization: 'Currently we don't make any money yet because we haven't reached the monetization stage yet. And so it's net minus at the moment.'
• Caveats: Cost estimate excludes infrastructure, data ingestion, hosting, and human review time.; No detail on whether the 20-30 cent cost includes Gemini API, ElevenLabs TTS, and rendering, or just LLM calls.; YouTube monetization threshold is 1,000 subscribers + 4,000 watch hours (or 10M Shorts views in 90 days); watch hours not disclosed.; No discussion of content policy risk (e.g., AI-generated content labeling, copyright on Lichess games, fair use).
• Implications: Unit economics are viable for scale if monetization is achieved; at 20-30 cents per video, even low CPMs (e.g., $2-5 per 1k views) could be profitable.; The 95% success rate is sufficient for an automated content pipeline; post-hoc review is a pragmatic scaling strategy.; Rapid subscriber growth suggests the content quality is competitive with human-created chess content, validating the AI-native approach.; For Ken: cost per unit (video, report, analysis) is a key metric for AI content systems; accepting a small error rate enables scale, but error diagnosis must be systematic.

Use Case and Market Positioning

• Claims: The system is not competing with top streamers (e.g., GothamChess) but enables personalized, scalable chess analysis for non-elite players.; The input is human games from Lichess; users could submit their own games for custom video analysis (though this is not yet a product).; The team avoids 'slop' aesthetics (e.g., exploding kings on checkmate) and focuses on chess quality and educational value.; Audience targeting is unclear: checkmate-in-one puzzles are trivial for strong players but valuable for beginners; the team is still deciding what to publish.
• Evidence: Steinfurt: 'There are a lot of interesting and great streamers. So for example, Gotham Chess is one, maybe the most well known streamer. But he would probably not describe one of your games or my games in his videos. But we now have a way to also scale for other people who are not the best players in the world.'; Input: 'We basically download chess games from Lichess every night and analyze them... we could be creating videos of your games and you could send the videos then to your friends and family.'; Aesthetics: 'We are not trying to put in these artificial things like exploding positions or exploding kings or something like that on checkmate which might be beneficial for the view count... we are really trying to get the most out of the chess quality.'; Targeting challenge: 'Sometimes we also have videos with a checkmate in one, which for good players is ridiculous... But on the other hand there are real beginners who really don't see that and need an explanation.'
• Caveats: No product or pricing for personalized videos yet; the system is not yet user-facing.; No data on which video types (tactical puzzles, endgames, opening traps) perform best on YouTube.; Audience segmentation (beginner vs. advanced) is manual and not yet data-driven.; No discussion of competition (e.g., chess.com's auto-analysis, Lichess studies, other AI chess channels).
• Implications: The product opportunity is personalized chess education at scale, enabled by AI; this is a template for AI-native SaaS in education, coaching, and entertainment.; The decision to avoid 'slop' aesthetics is a quality/brand trade-off vs. virality; it positions the channel as premium/educational, not clickbait.; For Ken: the challenge of audience segmentation (beginner vs. advanced) is common to AI content systems; data-driven targeting and A/B testing are missing but high-leverage.; The system demonstrates that AI can compete with human creators on quality, not just cost, in niche educational content.

Notable Concepts & Terms

• Checks, Captures, and Threats (CCT): A beginner chess heuristic for candidate move selection; the team built a tool that lists all checks, captures, and threats in a position, including bad moves, to give the agent diverse options to reason about and explain why intuitive moves fail.
• Maia Engine: A chess engine trained by the University of Toronto to predict human-like moves at a given rating (e.g., 1200, 1800); used as a tool to surface moves a human might consider, even if suboptimal, for educational explanations.
• Gemini 3.1 Pro post-training on chess: Steinfurt's hypothesis that Google post-trained Gemini 3.1 Pro on chess data, making it the best LLM for chess understanding (better than O1, Grok 4); evidenced by reasoning traces showing superior chess logic.
• Reasoning model shift: The architectural transition from script-driven (Python assembles data, LLM narrates) to agent-driven (LLM reasons and calls tools itself); enabled by models like O1, Grok 4, Gemini 3.1, and improves quality/flexibility at higher cost.
• Conflicting information strategy: Intentionally providing the agent with diverse or conflicting data (best move, human moves, checks, captures) so it can reason about common misconceptions and create richer explanations, rather than just narrating the optimal line.
• Holy grail of chess programming: A quote from chess researcher William Weber (via German newspaper Süddeutsche Zeitung) describing AI systems that explain chess as well as a human trainer, not just calculate best moves; the team's system is presented as achieving this milestone.

Operator Notes / Why Ken Should Care

• This is a working example of agentic AI generating monetizable, domain-specific content at scale; the architecture (LLM + domain oracle + structured tools + conflicting info) is a template for agent design in research, analysis, and content verticals.
• The shift from script-driven to reasoning-model-driven orchestration is a general pattern for AI systems; it trades cost/efficiency for quality/flexibility and is a key design decision for Ken's agent stack.
• Cost per unit (20-30 cents per video) and error rate (~5%) are critical metrics for scaling AI content; the team's move from pre-publication review to post-hoc takedown is a pragmatic scaling threshold.
• The rapid subscriber growth (4,000+ in the past month) validates that AI-generated content can compete on quality with human creators in niche educational verticals; this has implications for AI-native media, education, and SaaS.
• The product opportunity (personalized chess analysis for non-elite players) is a template for AI-native services: scale what human experts can't economically deliver (e.g., personalized coaching, game analysis, tutoring).
• The decision to avoid 'slop' aesthetics (no exploding kings, focus on chess quality) is a quality/brand trade-off; it suggests that AI content can be premium, not just cheap/viral.
• The team has not yet solved audience segmentation (beginner vs. advanced) or optimized for cost; these are high-leverage next steps and common challenges for AI content systems.
• The system demonstrates that reasoning models (O1, Gemini 3.1) can replace hand-coded orchestration logic, but require accepting higher cost and some inefficiency; the trade-off is context-sensitive.

Watch Map

• 00:00: Intro: title change to 'holy grail of chess programming' based on German newspaper (Süddeutsche Zeitung) quote from William Weber; presentation of AI-generated chess video example.
• 02:00: Two-minute demo video: AI-narrated tactical breakdown of a chess position (rook sacrifice, knight fork, queen trap); shows voice emphasis, visual annotations, variation analysis.
• 04:00: System overview: nightly automated pipeline from Lichess games to YouTube upload; uses Gemini 3.1 Pro + chess engine + tools (legal moves, CCT, Maia, board state, web search).
• 06:00: Checks-Captures-Threats (CCT) tool example: complex endgame position, tool lists all checks/captures/threats (including bad moves), agent uses diversity to explain why intuitive moves fail; best move is non-obvious rook sacrifice.
• 08:00: Reasoning model shift: from Python scripts assembling data + LLM narration to agent-driven tool use; Grok 4 was best in autumn 2023, Gemini 3.1 Pro now best due to post-training.
• 10:00: Conflicting information strategy: providing best move + human moves + checks/captures helps agent explain misconceptions; Maia engine used for human-like moves.
• 12:00: Video creation workflow: agent generates structured format, ElevenLabs v3 TTS for audio (with emphasis cues), agent decides highlights/arrows/labels.
• 14:00: Channel stats: 4,000+ subs, 500k views (mostly past month); not yet monetized; error rate ~1 in 20 videos; Steinfurt moving from pre-review to post-hoc takedown.
• 15:00: Q&A: cost per video 20-30 cents (longer videos a few euros); audience targeting (beginner vs. advanced) still unclear; no user-facing product yet but could enable personalized game analysis.

Source/Metadata

• Title: Running a Chess YouTube Channel entirely by AI — Stephan Steinfurt, TNG
• Transcript words: 2782
• Duration seconds: 991
• Timestamp note: No timestamps in transcript; watch_map entries are approximations based on segment order and 991-second duration.