Knowledge Management · PiniShv

NotebookLM Is Not a Chatbot. It's a Research Workbench.

Tue, 17 Mar 2026 10:00:00 +0200

I used to research topics the way most people do. Open twenty tabs. Skim articles. Copy-paste quotes into a doc. Ask ChatGPT with manually pasted context. Bookmark things I’d never come back to. Lose half of it in a Slack thread.

Then Google launched NotebookLM publicly in late 2023, and I started using it almost immediately. Something changed. Not because the AI was smarter. Because the workflow was different.

Instead of starting with a blank chat box and hoping the model knows what I need, I start with the material. PDFs, articles, YouTube videos, docs. I load them into a notebook, close the boundary, and say: help me think through this.

I’ve always been fast. I’ve always used every tool available to squeeze more out of my research and my work. But NotebookLM hit different. It was like strapping a missile to a process I already thought was optimized. The first time I shared an Audio Overview with a colleague, they didn’t believe it was AI-generated. The first time I turned a pile of research into a briefing for leadership, it took hours instead of days. The first time I used it to evaluate a new technology for my team, I realized that even my “fast” had been leaving speed on the table.

NotebookLM isn’t a chatbot. It’s a research workbench. And I think it’s one of Google’s best products.

Why constraints make AI better
#

Here’s the counterintuitive thing. Most AI products are racing to give you more. More context window. More tools. More access to the open web. More everything.

NotebookLM went the other direction. You give it a bounded set of sources. It works only within that boundary. If the answer isn’t in your material, it may simply not answer.

That sounds like a limitation. It’s actually what makes it useful.

When an AI has access to everything, it can hallucinate confidently from anywhere. When it’s constrained to your sources, the answers get grounded. The citations become verifiable. You can click through to the exact passage and check what it said. The AI stops trying to be smart about everything and starts being useful about the specific thing you’re working on.

I’ve been writing about this principle in the context of engineering teams. AI agents that work with curated knowledge produce better code than agents with unlimited context windows. NotebookLM proves the same thing from a completely different angle: bounded context beats unlimited context. Every time.

How I actually use it
#

My workflow now has three modes.

Research for writing. Before I write an article, I build a notebook. I dump every relevant source I can find: documentation, blog posts, Hacker News discussions, official announcements, technical deep dives. Then I interrogate the notebook. What are the key architectural decisions? What are people actually saying about this? What are the tradeoffs nobody mentions in the marketing? The notebook gives me grounded answers with citations I can verify. It compresses what used to take days of reading into hours of focused work.

Technology evaluation for work. When I need to evaluate a tool or approach for my team, I load the docs, the GitHub discussions, the community feedback, and any relevant technical papers into a notebook. Instead of forming an opinion from skimming, I can systematically ask questions across all the material at once. What are the real scaling concerns? What do production users actually complain about? Where does the marketing diverge from reality?

Learning new domains. When I need to get up to speed on something I don’t know well, NotebookLM is the fastest path I’ve found. Load the best sources, ask questions, get answers grounded in the material. It’s like having a study partner who actually read everything.

The outputs are where it gets interesting. I don’t just use the chat. I generate Audio Overviews and share them with colleagues who don’t have time to read a 40-page doc. I create briefings for leadership. I turn research into slide decks for presentations. Different people consume information differently, and NotebookLM lets me transform the same source material into whatever format lands best.

What it can do (beyond chat)
#

The feature surface is much broader than most people realize.

Audio Overviews. The signature feature. It generates podcast-style audio from your sources in formats like Deep Dive, Brief, Critique, and Debate. There’s an interactive mode where you can interrupt the hosts with your voice. When it works, it turns a stack of PDFs into something you can listen to on a walk. I share these constantly and the reaction is always the same: people can’t believe it’s generated from documents.

Video Overviews. Standard and Cinematic versions. The March 2026 update added Cinematic Video Overviews using the latest Google models. They take time to generate but the ability to turn research into a visual briefing is unique.

Study and synthesis outputs. Notes, reports, mind maps, data tables, flashcards, quizzes, slide decks, infographics. Reports export to Google Docs, data tables to Sheets, decks download as PDF or PowerPoint.

Discover Sources and Deep Research. NotebookLM is no longer only “bring your own documents.” Discover Sources lets you describe a topic and pull relevant web sources in. Deep Research can browse hundreds of websites and produce a source-grounded report that drops into the notebook.

Mobile app with offline listening. Background and offline Audio Overviews on your phone. This is what pushed it from “browser tool” to something I use throughout the day.

Where it frustrates me
#

I wouldn’t trust this article if I only said nice things. Here’s what actually bothers me.

You can’t tune the outputs. This is my biggest frustration. When an Audio Overview or a summary isn’t quite right, you can’t easily adjust it. The voices are limited. The styles are limited. You can regenerate, but you can’t say “keep everything except change this part” or “use a different tone for this section.” For a product that’s all about transformation, the lack of fine-grained control over the transformations feels like a gap.

Notebooks are isolated. Each notebook is its own world. You can’t cross-reference between notebooks or build connections across research projects. If you’re working on related topics, you end up duplicating sources or maintaining parallel notebooks that don’t talk to each other.

Sources are static copies. When you import a file, NotebookLM takes a snapshot. If the original changes, you need to re-import manually. For fast-moving research where docs update weekly, this creates drift between your notebook and reality.

The audio quality critique is fair. Some people say the hosts sound superficial or padded with filler. I don’t always agree, but the criticism isn’t baseless. The output quality varies by source material, and there are patterns that start to feel repetitive once you’ve generated enough overviews.

It’s Google’s infrastructure, not yours. Your data lives on Google’s servers. When you submit feedback, Google may collect your prompts, sources, and outputs for up to three years. Workspace users get stronger protections, but this is still a vendor-hosted system. If that’s a dealbreaker, self-hosted alternatives like Open WebUI or AnythingLLM exist for a reason.

How it compares to what’s out there
#

NotebookLM’s real competitors aren’t ChatGPT and Claude. Those are general-purpose assistants that happen to accept files. The real comparison is against research-specific tools.

Perplexity is search-first. Great for finding information. NotebookLM is notebook-first. Better when you already have the information and need to understand it.

Elicit specializes in systematic screening and data extraction from scientific papers. Sharper for academic literature review. NotebookLM is broader in source types and output formats.

Scite does contextual citation intelligence. It tells you whether a paper was supported, contradicted, or merely mentioned. A fundamentally different kind of analysis that NotebookLM doesn’t attempt.

Notion AI and Obsidian are note-taking tools with AI added. They make your existing notes smarter. NotebookLM starts from the sources, not from your notes. Different starting points, different outcomes.

Open Notebook and NotebookLlaMa are the open-source alternatives for anyone who needs privacy or provider control. They win on flexibility. NotebookLM wins on polish and integrated UX.

Where does ChatGPT fit? It’s not really a competitor. It’s the broader AI layer. Gemini Deep Research can even use NotebookLM notebooks as sources. That tells you where Google sees the relationship: Gemini is the general assistant, NotebookLM is the close-reading workbench inside the wider stack.

The bigger lesson
#

Here’s what I keep coming back to.

The AI industry is obsessed with making models bigger, context windows longer, and tools more general. Every product wants to do everything for everyone. More tokens. More tools. More capabilities.

NotebookLM went the other way. One notebook. Your sources. Help you think.

And it works better than the general-purpose tools for the specific job it does. Not because the underlying model is better. Because the constraints are better. When the AI can’t wander off into the internet, it stays focused. When every answer has to cite a source, the hallucinations drop. When the unit of work is a bounded notebook, the outputs feel coherent instead of scattered.

There’s a lesson in that for anyone building AI tools, or for anyone deciding how to use AI in their work. Sometimes the most powerful thing you can do with AI isn’t giving it access to everything. It’s giving it the right boundaries.

The teams I work with are learning the same thing. AI agents with curated knowledge bases outperform agents with unlimited context windows. NotebookLM proves the principle from the consumer side: give AI the right constraints, and it will give you better answers than any amount of raw capability.

Stop asking AI to know everything. Start asking it to know the right things.

Using NotebookLM for research or work? I’d love to hear what your workflow looks like. Find me on X or Telegram.

Your AI Agents Are Flying Blind. Here's How to Fix That.

Sun, 15 Mar 2026 10:00:00 +0200

Your AI agent just rewrote the authentication flow. The code is clean. Tests pass. The PR looks great.

One problem: it broke the SSO integration with three enterprise customers because it didn’t know the auth service has a contract with the identity provider that requires a specific token format. That contract lives in a Slack thread from 2023 and one engineer’s head.

The agent didn’t make a mistake. It made a perfectly reasonable decision with the information it had. The information it had was almost nothing.

This is happening across your codebase right now. Not just with authentication. With everything. Business rules, API contracts, deployment constraints, database conventions, service boundaries. Your agents write code that compiles, passes tests, and violates assumptions that live nowhere except in people’s heads and scattered documents nobody maintains.

I’ve written about why context is the fundamental problem in AI. I’ve written about putting AI agents on the org chart and managing them like team members. But none of that matters if the agents start every session blind.

If you’re running agents in production, this is the problem you need to solve next.

Two teams, same agents, wildly different results
#

Let me describe what I’m seeing.

Team A has agents embedded in their development workflow. An agent picks up a ticket to add a new validation rule to the user registration flow. Before writing a line of code, it queries a knowledge base and gets back: the existing validation rules, the reason the email format check is stricter than RFC 5322 (because of a legacy migration), the API contract with the notification service, and the team’s convention for error handling. The agent writes code that fits. The PR gets approved on the first review.

Team B has the exact same agents, same models, same IDE. Their agent picks up a similar ticket. It reads the code in the repo, sees patterns, generates a solution. The solution uses a different error handling pattern than the rest of the codebase. It changes the validation response format, which breaks the mobile client. It adds a database column without following the team’s migration conventions. The PR gets three rounds of review comments and a refactor.

Same AI. Same capability. Completely different outcomes.

The difference isn’t the model. It’s that Team A solved the knowledge problem and Team B didn’t.

Where knowledge actually lives (and why that’s broken)
#

In most engineering organizations, critical knowledge is scattered across:

People’s heads. The worst possible storage medium.
Slack threads. Searchable in theory, buried in practice.
Confluence pages. Written once, updated never.
Code comments. Spotty at best, misleading at worst.
Tribal knowledge. “Ask Daniel, he built that service.”

None of this is accessible to AI agents. None of it is structured for retrieval. None of it stays current.

And here’s the compounding problem: as AI agents do more work, the knowledge gap matters more, not less. When humans wrote all the code, at least the person writing it carried the context. When agents write the code, the context has to come from somewhere else. Or it doesn’t come at all.

Think about it this way: a senior developer who’s been on your team for three years carries hundreds of micro-decisions in their head. Why the payment service retries exactly three times. Why the user permissions check happens at the API gateway, not the service layer. Why that database query uses a specific index hint. Now imagine replacing that developer with an agent that knows none of this. That’s what you’re doing every time an agent starts a session.

The wrong way to fix this
#

The instinct is to throw more code at the agent. Bigger context windows. More files in the prompt. RAG over the entire codebase.

I’ve seen teams try this. Here’s what happens:

They dump the entire repo into the context. The agent drowns in irrelevant code and can’t find the signal, and every token costs money, so you’re paying premium rates to confuse your own agents. They build RAG over Confluence. The retrieval returns pages from 2021 that contradict how things actually work. They write massive README files. Nobody maintains them. Within three months they’re more misleading than helpful.

And the costs compound. More tokens in the context means higher API bills on every single request. Bad context leads to wrong code, which leads to longer review cycles, which leads to rework, which means more agent sessions with the same bad context. It’s compound interest working against you. Every layer of waste multiplies the next.

The problem isn’t volume of information. It’s the right information, maintained, structured, and delivered at the moment the agent needs it. Get this wrong and you’re not just getting bad code. You’re paying more for it with every iteration.

What actually works: a developer knowledge hub
#

After months of thinking about this problem and looking at how every available solution falls short, I believe the answer is a system with three components that work together.

Layer 1

Source of Truth

📁

Knowledge Repo (Git)
Developers author markdown: product rules, system docs, architecture specs, skills

▼ CI/CD syncs on every merge ▼

Layer 2

Index & Push

🔍

Vector Store + Embeddings
Chunk, embed, index → semantic search

📄

AGENTS.md + Skills per repo
Generated context + reusable workflows

▼ Serves queries at dev time ▼

Layer 3

Universal Bridge

🔌

MCP Server
One server → every IDE & agent can query knowledge

▼

Consumers

All tools

💻

Cursor Claude Code Copilot Codex Kiro + any future MCP-compatible tool

Git for authoring
#

Not Confluence. Not Notion. Not some SaaS product with its own editing UI.

A Git repository. Markdown files. Pull requests for review. CI/CD for automation. The same workflow developers already use for code.

Why Git? Because the adoption problem kills every knowledge initiative that requires developers to learn a different tool. PRs already have review workflows. Blame shows who wrote what. History shows when things changed. CODEOWNERS controls who can approve what. Your developers already know all of this. Zero adoption friction.

The repo holds four types of knowledge:

Product knowledge. Business rules, domain logic, edge cases, validation requirements. Why the user registration flow requires that specific email format. Why the discount calculation has a different rounding rule for enterprise customers. This changes every sprint.

System knowledge. Build commands, repo structure, coding conventions, database patterns, module boundaries. Why you always run migrations before the test suite. Why the cache invalidation uses event sourcing instead of TTL. This changes when code changes.

Architecture knowledge. API contracts, data flows, service boundaries, system invariants. Why the payment service is the only service allowed to write to the transactions table. Why the notification queue has exactly-once delivery semantics. This changes rarely but matters enormously.

Operational skills. Code review checklists, debugging guides, feature scaffolding patterns, cross-repo change workflows. How to add a new API endpoint. How to set up a feature flag. How to run a database migration across services. How the CI/CD pipeline works, which checks run on PR, which run on merge, what gates production. How linting and formatting are enforced and what to do when a check fails. How to roll back a deployment. How to triage a failing build. These are reusable agent workflows that encode how your team actually works. Not just the code, but the entire delivery process around it.

One thing you’ll notice is missing from this list: the code itself. That’s intentional. AI IDEs and coding agents like Cursor, Copilot, and Claude Code already do a solid job indexing your codebase. They understand file structure, imports, function signatures. You don’t need to duplicate that work. What they can’t index is everything around the code. The why, the rules, the decisions. That’s what the knowledge hub is for. That said, the system is designed to be agile. If you want to add code indexing, documentation from other sources, or any other category of data, the architecture supports it. Same Git authoring, same search layer, same MCP delivery.

Semantic search for retrieval
#

Raw markdown is great for humans. Useless for agents that need to find the right three paragraphs out of thousands for a specific task.

This layer chunks the markdown by section, embeds it into vectors, and indexes it for semantic retrieval. When an agent asks “what are the validation rules for the registration flow?” it gets the relevant sections, with citations back to the source documents.

AWS Bedrock Knowledge Bases does this out of the box. So does Pinecone, Weaviate, or any vector store with a decent chunking strategy. The specific tool doesn’t matter. What matters is that knowledge becomes semantically searchable, not just keyword-matchable.

CI/CD syncs markdown to the search index on every merge. Knowledge stays current automatically. No manual re-indexing. No stale embeddings.

MCP for delivery
#

Here’s where it comes together.

Your developers use Cursor, Claude Code, Copilot, Codex, Kiro. Probably several of them. Each one is an island. Each one starts every session without context.

Model Context Protocol (MCP) is the open standard that connects all of them. I wrote a deep dive on MCP earlier. If you haven’t read it, start there.

One MCP server wraps your knowledge base and exposes it to every IDE and agent through a standard interface. Build one server. Every tool connects natively. New tools that support MCP work automatically. Zero per-tool maintenance.

The server exposes three tools: search_knowledge for semantic search across all knowledge, get_document to fetch a specific doc by path, and list_knowledge_bases to discover available sources. Simple interface, massive impact.

Without MCP: You build a separate integration for each IDE. Maintain six connectors. Each tool gets knowledge differently. Every new tool means new work.

With MCP: You build one server. Everything connects. When the next AI coding tool launches next month, it just works.

The loop that makes it compound
#

Here’s where this gets really powerful. The system doesn’t just serve knowledge. It grows.

🔍

Read

Agent queries KB
via MCP

→

💻

Work

Develops with
full context

→

📝

Write Back

Opens PR to
knowledge repo

→

✅

Merge

Dev reviews
CI re-indexes

↩

🔄

Updated

Next session
starts smarter

Fully automated. No manual curation. Knowledge grows as the team develops.

The workflow in detail:

Agent reads. Before starting work, queries the knowledge base via MCP. Gets business rules, conventions, architecture constraints relevant to the task.
Agent works. Develops with full context. The code actually follows the patterns and rules.
Agent writes back. A built-in skill instructs the agent to capture what it learned during development and open a PR to the knowledge repo.
Developer reviews. Standard PR review. Approves or refines the knowledge doc.
CI syncs. Merged knowledge is automatically indexed. Next agent session starts smarter.

Knowledge capture becomes part of development, not a separate chore. The developer just reviews. No separate authoring step.

There’s a sixth step that takes this even further. When new knowledge merges, a CI step can run an LLM over the diff and ask: “What else in the entire knowledge base might be affected by this change?” Remember, this is a centralized system across all your repos. A change to how one service handles authentication could affect product knowledge for three other services, architecture docs for the API gateway, and operational skills for the deployment pipeline. The system uses embeddings to find related documents across every domain, checks for contradictions or staleness, and opens follow-up issues flagging what might need updating. Ripple effect detection across your entire engineering knowledge. You update the validation rules for user registration, and the system flags that the API contract doc, the mobile client integration guide, and the error handling conventions might all need a second look. It’s cheap to run and catches the kind of cross-cutting knowledge drift that humans miss because nobody has visibility into every document across every team.

Every feature built makes the next feature easier. Every agent session makes the next session smarter. The knowledge compounds.

The AGENTS.md safety net
#

Not every agent session has MCP access. Sometimes developers work offline. Sometimes a new tool doesn’t support MCP yet. Sometimes the knowledge server is down.

For these cases, CI generates a lightweight AGENTS.md in each repo. It’s a table of contents for the agent: what this repo does, how to build and test it, architecture boundaries, conventions and constraints, and where to find the full knowledge base.

Think of it as the offline fallback. Agents get essential context even without network access. Push model (always in-repo) complementing the pull model (on-demand via MCP).

Why nothing on the market solves this
#

I looked at many solutions out there. Each solves a piece, and the approach I’m describing borrows the best parts from all of them.

Meta-repos (centralized Git docs). Git-native authoring, but no semantic search. Agents can’t find what they need.

Wiki + RAG (Confluence/Notion with retrieval). Searchable, but not Git-native. Developers won’t update it. Knowledge rots within months.

Code wikis (auto-generated from code). Clever, but usually tied to one AI tool. Not universal.

Cloud RAG services (Bedrock KB, Vertex). Managed search, but no authoring story. Where does the content come from?

Agent memory (Copilot memory, Letta). Per-tool, per-session. Not centralized. Not shared across the team.

You need all five capabilities in one system. That’s what this approach delivers.

How to start (without boiling the ocean)
#

Day 1: Create the knowledge repo. Sit with your two or three most senior engineers, the ones who carry the most context in their heads. Ask them: “What do you find yourself explaining over and over?” That’s your first knowledge document.

Day 2-3: Set up semantic search. Connect your markdown to a vector store. Get retrieval working. This is not a multi-week project. The tooling exists. Use it.

Day 4-5: Deploy the MCP server. Configure it in your team’s primary IDE. Have a developer pair with an agent on a real task and compare the output to what they’d get without the knowledge base. That’s your first signal.

Week 2: Add the write-back loop. Build the skill that instructs agents to capture knowledge after completing work. Train your developers on how to review knowledge PRs, not just code PRs. This is where it starts compounding.

The technology side of this is days of work. The harder part is getting your team to treat knowledge as a first-class deliverable, not an afterthought. That’s a leadership problem, not a tooling problem. But once developers see their agents producing better code because someone took 20 minutes to document business rules, the culture shift happens on its own.

We’re in the AI era. If the infrastructure takes you months, you’re overengineering it. Get something working in days, iterate from there. The humans will make it great.

The key insight: start with the knowledge that hurts most when it’s missing. That’s usually the domain logic, the business rules that experienced developers carry in their heads and that agents get wrong in ways that look correct until they hit production.

The uncomfortable question
#

If your AI agents are generating code without context, how much of that code is actually correct?

Not “does it compile” correct. Not “does it pass the tests you wrote” correct. Actually correct. Follows the business rules, respects the architecture, uses the conventions, handles the edge cases that burned you last quarter.

If you can’t answer that confidently, your agents aren’t helping as much as you think. They’re generating plausible-looking code that somebody has to review against all the unwritten knowledge that exists only in people’s heads. And you’re paying for every token of that wrong output, then paying again for the review, again for the rework, and again when the agent generates the same mistake tomorrow because nothing changed.

That’s not an AI problem. That’s a knowledge management problem. And it’s solvable.

The organizations that figure this out first will have AI agents that don’t just write code. They write the right code. Every time. From session one.

That’s the difference between AI as a novelty and AI as a genuine multiplier. And it’s what separates teams that are actually shipping with agents from teams that are just generating code and hoping for the best.

Building knowledge systems for AI agents? Thinking about MCP? I’d love to hear how you’re approaching it. Find me on X or Telegram.

Knowledge Management · PiniShv

NotebookLM Is Not a Chatbot. It's a Research Workbench.

Why constraints make AI better #

How I actually use it #

What it can do (beyond chat) #

Where it frustrates me #

How it compares to what’s out there #

The bigger lesson #

Your AI Agents Are Flying Blind. Here's How to Fix That.

Two teams, same agents, wildly different results #

Where knowledge actually lives (and why that’s broken) #

The wrong way to fix this #

What actually works: a developer knowledge hub #

Git for authoring #

Semantic search for retrieval #

MCP for delivery #

The loop that makes it compound #

The AGENTS.md safety net #

Why nothing on the market solves this #

How to start (without boiling the ocean) #

The uncomfortable question #