Tienes veinte PDF de clientes, notas de reuniones y documentos técnicos. Claude Code puede leer archivos del proyecto, pero todavía necesitas decidir qué fuentes importan, qué afirmaciones están respaldadas y qué debe hacer el agente con ellas. Aquí NotebookLM puede ayudarte: consulta los materiales y prepara un briefing verificable que luego guardas en el repositorio.

Claude Code ya puede trabajar con memoria de proyecto, archivos CLAUDE.md, skills y documentos .md que usas como contexto. Si lo único que quieres es guardar reglas del repo, comandos, estilo, decisiones técnicas o procedimientos repetibles, no necesitas NotebookLM.

El valor real de NotebookLM es otro: convertir muchas fuentes externas en una base consultable. Es casi como tener un RAG no-code por categoría: uno para finanzas, otro para research, otro para marca, otro para cursos, otro para clientes.

Después Claude Code puede usar ese trabajo como contexto accionable mediante skills.

La conexión más simple no requiere un MCP: pide un briefing con citas en NotebookLM, revisa cada afirmación y copia el resultado a un archivo .md que Claude Code pueda leer. El flujo y un prompt reutilizable aparecen más abajo.

NotebookLM no es memoria para Claude Code

La confusión empieza cuando la gente habla de NotebookLM como si fuera “mejor memoria”.

Pero Claude Code ya tiene formas de recordar contexto dentro de un proyecto. Puedes tener un CLAUDE.md con reglas, una carpeta docs/ con decisiones, archivos .md por tema, skills para procesos repetibles y hasta subagents para tareas específicas.

Entonces, si tu pregunta es:

¿Necesito NotebookLM para que Claude Code recuerde mejor mi proyecto?

Mi respuesta sería: no necesariamente.

Para la memoria operativa del repo, Claude Code ya está bien. El problema que NotebookLM resuelve no es “Claude olvidó mi comando de deploy”. El problema es otro:

Tengo demasiadas fuentes externas y necesito convertirlas en contexto útil.

Ahí sí aparece el valor.

El valor real: RAG no-code por categoría

La forma simple de entenderlo es esta:

NotebookLM = biblioteca inteligente por tema
Claude Code = ejecutor con skills
.md exportado = puente entre ambos

Si lo ves así, todo hace más sentido.

No estás usando NotebookLM porque Claude Code sea malo recordando. Lo estás usando porque no quieres construir desde cero un sistema de chunking, embeddings, base vectorial, búsqueda semántica, resumen de fuentes y citas.

NotebookLM ya hace buena parte de ese trabajo por ti.

Por ejemplo, puedes tener notebooks separados por contexto:

Finanzas: reportes, CSVs, estados de cuenta, notas del contador.
Research: PDFs, papers, documentación técnica, videos, transcripciones.
Marca: posts antiguos, manifiesto, ideas, frases, opiniones fuertes.
Cursos: módulos, landings, preguntas frecuentes, objeciones.
Clientes: llamadas, comentarios, DMs, feedback y tickets.

Cada notebook funciona como una biblioteca inteligente de un tema específico. No es tu memoria global. Es más parecido a tener varios RAGs por categoría, pero sin construir infraestructura.

Cómo se conecta con Claude Code

La parte importante: Claude Code normalmente no consulta NotebookLM de forma mágica.

El flujo práctico es más simple:

Muchos PDFs / Sheets / Docs / videos
        ↓
NotebookLM los organiza y los entiende
        ↓
Le pides un briefing o resumen con citas
        ↓
Copias el briefing revisado a un archivo Markdown
        ↓
Claude Code usa ese .md mediante un skill

Ese archivo Markdown es el puente.

Por ejemplo:

docs/research/finanzas-briefing.md
docs/research/mcp-research-briefing.md
docs/research/audiencia-briefing.md

Luego Claude Code puede usar esos archivos para ejecutar tareas reales:

crear un dashboard
generar queries SQL
escribir un post
mejorar una landing
convertir research en módulos de curso
detectar contradicciones
crear un plan editorial

El multiplicador no es “más memoria”. El multiplicador es convertir documentos dispersos en contexto accionable.

Google explica qué fuentes admite NotebookLM y cómo exportar notas a Google Docs. Para el flujo de este artículo, puedes copiar manualmente un briefing revisado al archivo Markdown del repo; no presupongas una sincronización automática con Claude Code.

Ejemplo 1: finanzas de tu empresa

Este caso me parece muy bueno.

Imagina que tienes información financiera regada en varios lugares:

Google Sheets
CSVs
reportes contables
facturas
estados de cuenta
notas del contador
proyecciones internas

Podrías meter todo eso en un notebook llamado:

Finanzas empresa

Y pedirle a NotebookLM:

Analiza estas fuentes financieras y dame:
- ingresos por línea
- gastos recurrentes
- anomalías
- runway
- riesgos
- preguntas abiertas
- citas por fuente

El resultado lo guardas como:

docs/research/finanzas-briefing.md

Luego Claude Code, con un skill financiero, puede convertir ese briefing en trabajo real:

un dashboard
un reporte mensual
queries para Supabase
alertas de caja
preguntas para el contador
un resumen para socios

El skill no necesita leer todos los documentos originales. Trabaja desde el briefing que ya viene destilado.

Ese es el punto: NotebookLM reduce el costo de convertir fuentes sucias en contexto limpio.

Ejemplo 2: investigación con PDFs

El otro caso obvio es investigación.

Técnicamente puedes meter PDFs en un repo y pedirle a Claude Code que los procese. Pero si quieres hacerlo bien, muchas veces terminas armando tu propio mini-RAG: extraer texto, limpiar documentos, partir en chunks, buscar secciones relevantes, guardar embeddings, citar fuentes y resumir.

NotebookLM te ahorra esa parte.

Por ejemplo, puedes tener un notebook sobre MCPs:

documentación oficial
repos de ejemplo
posts técnicos
transcripciones de videos
papers o specs
notas propias

Le pides:

Dame un briefing para escribir un post sobre MCPs.
Incluye:
- tesis principal
- conceptos que debo explicar
- errores comunes
- ejemplos concretos
- claims que puedo afirmar
- claims que no puedo afirmar
- fuentes que sostienen cada punto

Después Claude Code toma ese briefing y lo convierte en:

post para el blog
landing de curso
estructura de módulos
spec técnica
lista de issues
script para video

NotebookLM piensa con fuentes. Claude Code ejecuta con contexto.

Qué va en NotebookLM y qué va en Claude Code

Esta distinción evita mucho desorden.

Uso	Mejor lugar
Reglas del repo	`CLAUDE.md`
Comandos de build y deploy	`CLAUDE.md`
Procedimientos repetibles	Skills
Research con muchos PDFs	NotebookLM
Finanzas y reportes	NotebookLM + `briefing.md`
Decisiones finales del proyecto	`docs/decisions` o `CLAUDE.md`
Contenido accionable para ejecutar	Claude Code

Mi regla sería:

Si es regla estable del proyecto, va en CLAUDE.md.
Si es procedimiento repetible, va en un skill.
Si son muchas fuentes externas, va en NotebookLM.
Si es una conclusión ya destilada, va en docs/research.

El flujo práctico que usaría

Yo lo armaría así:

notebooks/
  finanzas-empresa/
  investigacion-mcp/
  curso-agentes-ia/
  audiencia-y-clientes/
  competencia-landings/

repo/
  docs/
    research/
      finanzas-briefing.md
      mcp-research-briefing.md
      audiencia-briefing.md
    decisions/
      product-decisions.md

  .claude/
    skills/
      finance-review/
      research-to-post/
      course-landing/
      landing-audit/

El flujo semanal sería:

Subes nuevas fuentes a NotebookLM.
Le pides un briefing claro y verificable.
Guardas el briefing en docs/research/.
Claude Code ejecuta usando un skill.
Las decisiones finales vuelven al repo.

Ejemplo de prompt para NotebookLM:

Convierte estas fuentes en un briefing accionable.
No quiero un resumen genérico.
Quiero:
- decisiones importantes
- riesgos
- oportunidades
- preguntas abiertas
- citas por fuente
- posibles acciones para Claude Code

Ejemplo de prompt para Claude Code:

Usa docs/research/mcp-research-briefing.md.
Convierte el briefing en un post para el blog.
Mantén mi voz: directa, técnica, con ejemplos concretos.
No agregues claims que no estén soportados por el briefing.

Ahí sí tienes un sistema.

Cuándo no vale la pena usarlo

No usaría NotebookLM para todo.

No lo usaría para guardar comandos simples:

npm run dev
npm run build
vercel deploy

Eso va en CLAUDE.md.

Tampoco lo usaría para decisiones estables del repo:

estructura de carpetas
nombres de servicios
convenciones de commits
estilo de código
reglas de deploy

Eso también vive mejor en el repo.

NotebookLM tiene sentido cuando hay volumen de fuentes o investigación. Si solo tienes tres notas pequeñas, probablemente un .md bien escrito basta.

También hay que tener cuidado con datos sensibles. Si vas a subir finanzas, clientes o documentos internos, piensa antes qué cuenta usas, qué permisos tiene el notebook y si puedes anonimizar datos. No todo contexto merece estar en cualquier herramienta.

La conclusión simple

NotebookLM no reemplaza la memoria de Claude Code.

La complementa desde antes.

NotebookLM entra cuando tienes caos de fuentes. Claude Code entra cuando quieres convertir ese contexto en trabajo real.

NotebookLM piensa con fuentes.
Claude Code ejecuta con contexto.
Los skills convierten ese contexto en sistema.

Por eso la combinación tiene sentido.

No necesitas más memoria. Necesitas mejores fuentes, mejor síntesis y mejores flujos para convertir conocimiento en trabajo.

Ahí está el verdadero valor de usar NotebookLM con Claude Code: no es recordar más, es pensar mejor antes de ejecutar.

Prueba el flujo con tres fuentes no sensibles: crea un briefing con citas, verifica dos afirmaciones en los originales y guarda el resultado como docs/research/tema-briefing.md. Luego pide a Claude Code una tarea concreta basada en ese archivo y comprueba que sus afirmaciones sigan apuntando a las fuentes.

¿Se puede conectar NotebookLM a Claude? Así se hace