Google launched agentic video understanding for Gemini on September 1. Instead of sampling a whole video at a fixed rate, the model can search the audio, transcript, and frames for the moments that answer a question. Google reports token use fell by up to 88%, cost by up to 66%, and accuracy improved by up to 7% in its tests.
That makes long tutorials easier to inspect. It does not make a video a dependable chatbot knowledge base by itself. Before training, turn each useful tutorial into a video source packet with six parts: tutorial version, audience and prerequisites, timestamped steps, text visible only on screen, exceptions, and a reviewed answer set. The packet is the asset to keep. The video remains the evidence behind it.
Start with a source map, not a transcript
A transcript records what someone said. A support answer may depend on what the viewer saw.
Imagine a screen recording about changing a billing address. The presenter says, "Choose Edit and save your changes." The screen shows that Edit appears only for account owners. A warning says the new address affects future invoices, not invoices already issued. Neither detail reaches the transcript if the presenter does not read it aloud.
Training a chatbot on that transcript produces a smooth but incomplete answer. It may tell a team member to look for a control they cannot access. It may promise that an old invoice will change. The words were transcribed correctly. The source was still wrong.
Map four evidence channels before extracting answers:
- Speech. The narration, questions from participants, and verbal corrections.
- Screen text. Button labels, field names, warnings, error messages, and captions.
- Visible state. The selected plan, user role, device, product version, and whether a control is disabled.
- Action order. What happens before and after a click, including confirmation and rollback steps.
If a fact appears in only one channel, label it. Reviewers can then return to the exact frame instead of watching a 40-minute recording from the beginning.
Build one record for each supportable procedure
Do not pour the complete transcript into one file and hope retrieval finds the right sentence. Split the tutorial into procedures a customer might ask about. A single video may yield records for setup, permissions, normal use, failure recovery, and cancellation.
Use a compact schema for every record:
| Field | What to store | Example |
|---|---|---|
tutorial_id | Stable name for the source video | billing-address-2026-09 |
product_version | Interface or release shown | Web app, September 2026 |
audience | Role allowed to follow the steps | Account owner |
segment | Start and end time | 08:14-09:02 |
goal | Customer task in plain language | Change the billing address |
procedure | Ordered steps with exact UI labels | Billing, Address, Edit, Save |
constraints | Preconditions, exceptions, and effects | Future invoices only |
visual_evidence | Text seen but not spoken | "Owner access required" |
reviewed_at | Date a product owner checked it | 2026-09-08 |
source_url | Durable link to the recording | Canonical tutorial URL |
This record is small enough to review and specific enough to retrieve. It also preserves the evidence needed to fix an answer later.
Keep timestamps even when customers will never see them. A timestamp is a cheap audit trail. When a procedure looks suspicious, the reviewer knows which 48 seconds to inspect.
A worked example from one messy minute
Suppose a returns tutorial contains this narration at 12:40:
Open the order, choose Return item, select a reason, and submit. If the button is gray, ask an admin to check your permissions.
The screen adds facts the narration misses:
Role shown: Store manager Banner: Returns close 30 days after delivery Checkbox: I have confirmed the item was not final sale Success message: Request submitted for review
A transcript-only chatbot might answer, "Open the order and click Return item." That skips eligibility, role, the final-sale check, and the fact that submission starts a review rather than guaranteeing a refund.
The source packet should say:
Goal: Submit a return request Audience: Store manager or admin with return permission Eligibility: Within 30 days of delivery and not marked final sale Steps: 1. Open the order. 2. Select Return item. 3. Choose the return reason. 4. Confirm the item was not final sale. 5. Submit the request for review. Exception: If Return item is disabled, an admin must check the user's role. Outcome: Submission creates a review request. It does not confirm a refund. Evidence: Returns tutorial v4, 12:40-13:31, reviewed 2026-09-08.
Now ask, "Why can't I return this order?" The chatbot has several supported paths. It can check the 30-day limit, final-sale status, and permission requirement. If it cannot see the customer's order or role, it can name those checks without pretending to know which one failed.
That last distinction matters. Video training should improve the explanation, not encourage the chatbot to invent account state.
Choose the training format by answer risk
The source packet can feed several training formats. Pick the format that matches how exact the answer needs to be.
Use a document for a full procedure with prerequisites, steps, exceptions, and troubleshooting. TXT and DOCX work well because reviewers can compare revisions without replaying media. Keep one procedure per section and use descriptive headings that match customer language.
Use a Q&A pair for a rule that must be stated precisely. Good candidates include eligibility deadlines, plan limits, permission requirements, and statements that distinguish a request from an approved outcome. Write natural question variants, but keep one reviewed answer as the source of truth.
Use a text snippet for a short notice that will expire soon, such as a temporary interface change or a known issue affecting the tutorial. Add an owner and removal date inside the text.
Use a website page when the video accompanies a maintained help article. The article should hold the procedure. The video should demonstrate it. If the two disagree, define which source wins instead of asking retrieval similarity to settle the conflict.
The broader chatbot training guide covers how website pages, documents, Q&A pairs, and text snippets fit together. For video, the important choice happens one step earlier: decide what evidence deserves to become training text.
Chunk around decisions, not equal lengths
Fixed-size chunks can separate a step from the warning that changes it. Keep these items together:
- the task and its prerequisites;
- a control label and the role that can see it;
- a rule and every exception stated in the tutorial;
- an error message and its recovery steps;
- an action and the confirmation that proves it finished.
Split when the customer goal changes. "Invite a teammate" and "remove a teammate" belong in separate sections even if the presenter covers them in one continuous minute. Retrieval works better when each section answers one intent.
Avoid copying filler into the packet. Greetings, sponsor reads, repeated introductions, cursor narration, and failed takes add noise. Keep a failed attempt only when it teaches a real recovery path.
The document source pipeline guide goes deeper on OCR, headings, metadata, and clean chunks. Video adds one extra duty: reconcile speech with the interface before chunking begins.
Put freshness inside the source
Tutorials age quietly. The URL stays live while buttons move, permissions change, and policy text expires. A confident answer from a three-year-old recording can be worse than no answer because the customer follows steps that no longer exist.
Give every source packet a product version, publication date, review date, and owner. Add an explicit replacement link when a new tutorial supersedes it. Remove the old packet from the active training set rather than leaving both versions for the model to reconcile.
Set review triggers around events, not only a calendar:
- the interface label or navigation path changes;
- a permission or plan requirement changes;
- support logs show customers cannot find a named control;
- a new tutorial replaces the recording;
- the chatbot cites two versions for the same procedure.
For high-traffic procedures, review the packet with every product release that touches the workflow. For stable tutorials, a quarterly check may be enough. The useful interval is the one that catches changes before customers do.
If stale sources are already a recurring problem, the chatbot memory testing guide has tests for expired facts and false recall. Apply the same discipline to retrieved video records.
Test questions that force the video evidence to matter
Happy-path questions prove very little. Build tests around details that disappear in a raw transcript.
| Test | Example question | Passing behavior |
|---|---|---|
| Visual label | Where is the Return item button? | Uses the current navigation and exact label |
| Permission | Why is Return item disabled? | Names the role check without claiming account access |
| Exception | Can I return a final-sale item? | Applies the exception and does not quote the general rule alone |
| Outcome | Does submitting guarantee a refund? | Says it creates a review request |
| Freshness | These steps do not match my screen. What now? | Exposes version limits and routes to current help |
| Evidence | Where did this instruction come from? | Names the tutorial and useful timestamp |
Start with 20 questions per important tutorial. Include paraphrases, missing context, wrong assumptions, and requests that combine two procedures. Save the expected answer, expected source record, and whether the chatbot should ask a follow-up question.
Grade source selection separately from prose quality. A polished answer from the wrong tutorial version fails. So does a correct answer that cites a timestamp where the rule never appears. The chatbot citations guide explains how to test relevance, support, authority, and freshness as separate checks.
Review the questions again after changing the transcript tool, extraction model, chunking rules, chatbot model, or source packet. Each component can alter which evidence reaches the answer.
Know when the video is insufficient
Some recordings should not become authoritative training data.
A webinar may contain opinions, roadmap promises, and improvised answers that no product owner approved. A sales demo may use a private beta or a sample account with permissions customers do not have. A support call may expose personal data. A tutorial may show a policy but never state its effective market or date.
Use those videos to discover candidate questions. Send the facts to an owner for review before adding them to the knowledge base. Redact personal data before processing or storing transcripts and frames. If the owner cannot establish what is current, the chatbot should not present the recording as policy.
Video models are getting better at finding the right moment. That is useful, especially across long recordings. A production support answer still needs a smaller, reviewed record that states what the moment proves, who it applies to, and when it expires.
Turn the next high-traffic tutorial into a source packet, test the details visible only on screen, and keep the packet versioned beside the recording. In Agentkit, you can train with documents and text snippets, pin exact rules with priority Q&A pairs, then use conversation logs to find the next question the packet missed.
No credit card required.
