Text-to-Animation Engine (TTA)

The obvious approach — asking an LLM to write Manim animation code directly — failed in production. The pure generative baseline succeeded only ~40% of the time: the model called non-existent functions, produced malformed object layouts, and generated code that didn't compile. I designed TTA's architecture specifically to fix that failure mode, by combining generative reasoning with deterministic, template-driven execution — lifting the success rate from ~40% to 99.4% in production.

The Text-to-Animation Engine converts a raw academic topic (e.g. "Gauss's Law") into a fully rendered, narrated educational video, with no human in the loop. It serves CBSE/JEE/NEET students, targeting Physics, Chemistry, and Mathematics (PCM) content at production scale.

Manim is unforgiving: a single invalid construct breaks the entire render. When given full creative latitude over both the content and code structure of an animation, an LLM frequently invents APIs that don't exist, misordered object lifecycles, or produces structurally incoherent scenes — producing a ~40% baseline success rate. This made pure generative pipelines unfit for unattended, large-scale production use.

The product requirement I set was not "make the AI better at writing code." It was "constrain what the AI is allowed to decide, so that failure becomes structurally difficult."

• —Generate narrated educational animation videos automatically from a topic input, with no manual editing step.
• —Achieve a production-grade 99.4% success rate (vs the ~40% pure generative baseline).
• —Support PCM subjects at launch, with an architecture that allows new subjects to be added without rewriting the orchestration layer.
• —Guarantee that every submitted topic produces some usable video, even if it falls outside a supported domain.
• —Keep rendering latency within a usable range (P95 ≈ 85 seconds).
• —Keep narration and visuals synchronised tightly (<100ms audio sync).

The defining design decision is a hybrid philosophy:

• —Use generative models for reasoning and content synthesis (what to explain, in what order).
• —Use deterministic templates to enforce execution structure (how the code is built, so it can't fail in unbounded ways).
• —Use routing logic to ensure the right template is selected for the right domain.
• —Isolate failure boundaries so that one component's failure doesn't cascade through the system.

This reframes the LLM's job from "write correct code" to "fill structured slots inside code that is already guaranteed to be valid."

Templates over fine-tuning. I rejected fine-tuning because it would still leave failure modes unbounded — a fine-tuned model can still hallucinate. Templates gave a hard ceiling on what could go wrong, at the cost of upfront engineering time per subject and less creative flexibility in scene composition. For a student-facing product, reliability is worth more than expressiveness.

85% confidence threshold for routing, not 100%. Too high a threshold would push legitimate PCM topics into the generic fallback. Too low would let ambiguous topics break templates. I tuned empirically against misclassification cost, not topic coverage.

Coverage over depth in the fallback path. For exam-prep students, "video exists but is somewhat generic" beats "no video, try a different topic." A hard rejection breaks trust in the product.

Separating rendering from the request path. Generation and rendering run as separate phases so a long render can't block API responsiveness. This added orchestration complexity but was necessary at concurrent-user scale.

Subject Classification & Confidence-Gated Routing — Every incoming topic predicts a subject domain with a confidence score. If confidence exceeds 85%, the topic routes to a domain-specific template. Below threshold → Wikipedia-grounded fallback pipeline.

Domain-Constrained Template Architecture — Structured template modules per subject: Mathematics, Physics, Physical Chemistry, Organic Chemistry, Computer Science. Each template enforces scene sequencing, allowed Manim constructs, naming conventions, and explicit animation boundaries.

Multi-Agent Fallback Pipeline — For topics that don't confidently match a supported domain, an orchestrator retrieves a Wikipedia summary, extracts core sections, and converts them into a structurally valid (if more generic) Manim script.

Orchestration Layer — A central AgentOrchestrator decides which template to invoke, when to trigger validation, how to handle regeneration, and when to initiate rendering and storage. New subjects can be added by registering a new template — no routing rewrite needed.

Script Validation & Rendering — Code generation and code execution are distinct phases. Render failures trigger bounded retries before falling back to a simplified render. Rendering is decoupled from the API request path.

Narration & Audio Synchronisation — Narration is generated as structured blocks, passed through TTS, then aligned to scene transitions. Decoupled from animation code so the voice model can be iterated independently.

Cloud Storage & Asset Lifecycle — Rendered videos upload to Google Cloud Storage. The system returns a public asset URL on success.

The 99.4% figure represents the gap closed between naive LLM-driven generation (~40% success) and a production-viable pipeline, achieved entirely through structural constraint rather than improving the underlying model.

I treat this system as a case study in production AI reliability engineering rather than prompt engineering. The core insight driving every design decision: when a generative model's output must be executed by a strict, failure-intolerant runtime like Manim, the way to get reliability is not to make the model smarter — it's to shrink the space of mistakes the model is structurally permitted to make.