NotebookLM Automation

1What it does

A pipeline-oriented automation project — scripts that take NotebookLM from "upload → click → wait" to "feed sources in, artifacts out" as a batchable operation. Where single-purpose automators do one thing (generate a podcast), this repo is built around the pipeline: ingest a set of sources into a notebook, run the generation step (audio overviews are the flagship artifact), and collect the outputs — structured for cron-driven or CI-driven runs rather than one-shot sessions. The codebase treats the session-management problem as solved infrastructure so the interesting part is the workflow definition: which sources, which artifacts, what to do with the results. It's the shape you want if NotebookLM is a stage in a larger system — content pipeline, research digest service, automated study-pack generator — rather than the destination.

2When to use it

Reach for it when NotebookLM is a step in a bigger automation — daily digest generation, scheduled study-pack builds, a bot that ingests RSS and outputs audio. The pipeline framing pays off at volume: dozens of notebooks, recurring schedules, output routing to storage. For a single artifact type at low volume the podcast automator is simpler; for a supported enterprise deployment the Enterprise API is the right contract. Skip it if you want a managed service — this is scripts you run and maintain, not infrastructure someone else babysits.

3How to get started

Clone, install dependencies, and handle the same auth reality as every consumer NotebookLM tool — a Google session export per the README, kept local. The first milestone is a dry run through the full pipeline on a throwaway notebook: ingest a couple of sources, trigger one artifact, confirm the output path. Only then wire the scheduler — a pipeline that fails at hour six of a cron job is harder to debug than one that fails at minute two of your terminal. The repo's structure separates the pipeline stages; read the main entry script to see where your sources and artifact choice plug in.

4Configuration

Configuration is the pipeline definition — source sets, artifact types, output routing — plus the session credentials and the schedule. Because it runs unattended, the two knobs that matter most are pacing (how aggressively it hits the consumer endpoints; a tight loop is an account flag waiting to happen) and idempotency (what happens when a run half-completes — whether the pipeline can resume or re-runs everything). Log outputs to somewhere you'll actually read — an automation that silently fails for a week produces a week of missing digests you only notice later.

5Things to know

• Same consumer-surface fragility as the whole category — it automates endpoints that aren't a public contract, so it inherits the breakage risk; budget maintenance accordingly.
• Pipeline-shaped = more moving parts — more value at scale, more surface to debug; start with the SDK if your job is single-artifact.
• Session auth on an unattended process is the sharpest edge — a dedicated Google account and deliberate credential expiry are table stakes, not optional hardening.
• The Enterprise API is the "supported" answer to the same question — this repo serves the gap where consumer accounts need the pipeline anyway.
• The pipeline is file-oriented end to end — artifacts land on disk, which keeps the automation composable with whatever storage or feed system you already run.
• Runs are resumable by design — the pipeline tracks which stages completed, so a mid-run failure retries the failed stage rather than duplicating finished work.
• Treat it as scaffolding to adapt, not a product — the value is the pipeline shape; expect to rewrite the task definitions for your own source types.
• The repo pairs naturally with the SDK — several pipeline stages are SDK-shaped calls; using both keeps the protocol layer maintained upstream while your pipeline code stays workflow-shaped.

6Related on the map

References

• Repository
• NotebookLM Enterprise API docs