Greencat-AI: A Knowledge Engine Trained on a Decade of Coaching
Scott Patrick runs a coaching business that produces an extraordinary volume of teaching. Every week there is a live group call with his coaching students, a stack of personal Loom recordings answering individual questions, a growing course library, and a short opening monologue that frames each session. On top of that sit his books and years of email Q&A. His small team answers the same recurring student questions by hand, every week, drawing on knowledge that lives scattered across recordings nobody has time to re-watch.
The goal: an assistant that can answer a student's question grounded in everything Scott has ever taught, in his own voice, and that keeps learning automatically as new content is produced. I designed and built Greencat-AI, the system that turns his entire coaching corpus into a queryable knowledge engine.
Context
The raw material was rich but unusable in its native form: hundreds of hours of video and audio, each a different shape. Weekly Zoom group calls where a dozen students each ask a question. Per-client Loom recordings where Scott answers someone individually. A course library of recorded lessons. The weekly opening monologue. None of it was searchable, and re-watching it to answer a recurring question was not something a support team could scale.
What the team needed was not "search the videos." It was a single assistant that had effectively internalized the corpus, one that could take a new student question, retrieve the most relevant things Scott has said across two years of teaching, and answer the way he would. That meant two problems: turning every content type into clean, structured, retrievable text, and keeping the whole thing current without anyone doing manual work each week.
My Role
Engineer & Technical Partner
I owned the full technical scope: pipeline architecture and transcription strategy, the per-content-type processing and enrichment design, the retrieval-augmented assistant and its system prompt, the bulk question-answering tooling, and the end-to-end weekly automation. I worked directly with the client on an ongoing basis, speccing each corpus, confirming the editorial conventions that preserve his voice, and shipping in small, reviewable increments.
Architecture
Each kind of content flows through its own ingestion pipeline but converges on a common output: clean, structured Markdown "knowledge documents," which are indexed into an OpenAI vector store and served to a retrieval-augmented assistant.
The unifying idea is that the document, not the video, is the unit of knowledge. A single Zoom call becomes one Markdown file per student question; each file carries the student's question, distilled advice, key principles, and topic tags. That structure is what makes retrieval precise: a query matches against tightly-scoped, self-contained answers rather than against a wall of raw transcript.
The Four Pipelines
Weekly group calls
The highest-volume source. Each call is transcribed, then segmented into individual student exchanges, then enriched into one document per (student, call). Segmentation is deliberately tight: call-opening pleasantries, community shoutouts, and wrap-ups are stripped, so each document is just the substance of one person's question and Scott's answer. Multiple questions from the same student in one call merge into a single document; the same student across different weeks stays as separate documents.
Per-client Loom recordings
Scott records short personal answers to individual students as Looms. The pipeline pulls each recording's transcript and reunites it with the student's original question (recovered by matching against a submissions sheet), so the resulting document captures both sides of the exchange, not just the answer in isolation.
The course library
His course is a tree of recorded lessons. The pipeline walks the library, extracts audio from each video, transcribes it, and enriches it into a lesson document, preserving the course's module structure in the folder layout so the hierarchy survives into the knowledge store.
Weekly opening monologues
Each call opens with a 10 to 15 minute monologue. A single enrichment pass identifies that portion of the call, strips the greetings and the transition into Q&A, removes filler, and rewrites it as clean prose with distilled advice and key principles, turning an ephemeral opening talk into a durable teaching document.
Key Technical Decisions
Use the transcript you already have
Zoom now emits a native transcript with speaker names baked in. For new weekly calls the pipeline uses that directly (free, fast, and already diarized) and only falls back to a paid transcription service for older recordings that predate it. The same instinct runs through the system: the cheapest, most accurate text is the one that already exists, so reach for a paid model only when there's no free signal.
Preserve the voice, not just the facts
A knowledge engine that answers in a flattened, generic register would be worthless here: the whole value is that it sounds like the coach himself. The cleanup rules are tuned to that: drop the uh/um filler and collapse stutters, but keep his characteristic phrasing. The enrichment prompts and bullet densities were calibrated against documents the client had hand-authored, so generated output matches what he'd write himself.
The system prompt is the highest-leverage lever
When the client asked whether we should build a "map" document to orient the model to the corpus, I argued the system prompt was the stronger lever: it's always present, deterministic, and doesn't compete with real content for retrieval slots. The assistant's system prompt now explains the four kinds of source material and how to weigh them, with a thin orientation document added only as belt-and-suspenders for queries that bypass the pipeline. Higher impact, lower cost: a few hundred tokens per request instead of a derived layer that needs constant regeneration.
Answer questions in bulk, in parallel
The team answers recurring student questions in batches. I parallelized that processor with a bounded thread pool; a real benchmark showed a 3.3x speedup on a small batch, with 5 to 8x expected on the realistic 20-to-30-question batches: same model, same prompts, byte-identical output, no added cost.
Automation
The part that makes this sustainable is that no one has to run it. The weekly flow is fully automated through GitHub Actions: the team commits the new call transcript to the repository, a workflow processes it into knowledge documents, commits those back, and syncs them to the vector store. A separate universal sync workflow uploads any new or changed knowledge document to its matching vector store, so the corpus stays current with zero manual steps. Schema validators and a stats command guard the output: counts, gaps, and conformance to each corpus's structure are checkable on demand.
Outcomes
- ~1,800+ knowledge documents generated across the four corpora, spanning content from early 2024 to the present.
- The weekly flow is fully automated end to end: new calls become indexed, queryable knowledge with no manual intervention.
- Continuous coverage: the backfill plus the automated weekly path mean the corpus has no gaps from 2024 to today.
- Bulk question answering parallelized for a measured 3.3x (and projected 5 to 8x) speedup at no additional cost.
- A foundation for expansion: the same pipeline shape is ready to absorb the remaining material on the roadmap, including books, additional courses, and product support content.
Reflections
The document is the unit of knowledge, not the video. The single most important decision was resolving every content type down to small, self-contained, structured documents. Retrieval quality is a direct function of how tightly scoped each document is.
Preserve the voice. In a personal-brand knowledge engine, fidelity to how the expert speaks is not a nice-to-have. It's the product. The editorial rules that keep his cadence are as important as the extraction itself.
The system prompt beats the index doc. An always-present, deterministic instruction that explains the corpus outperforms a derived "map" that competes for retrieval space. Spend the tokens where they're guaranteed to be read.
Listen to the domain expert's "minor" signals. The accompanying context around each recording (the student's original question, the submissions sheet) turned out to be essential for making each document a complete exchange rather than a disembodied answer.
Automate the weekly path completely. The system earns its keep by being something the team never has to think about. Commit a transcript; everything downstream happens on its own.