Solanasis Docs

claude-cowork-rag-playbook-v2

16 min read

Claude Cowork + RAG Playbook

AI-to-AI Handoff Guide for Document-Heavy Workflows

Prepared for: another AI agent helping Dmitri / Solanasis
Date: March 14, 2026
Scope: Claude Cowork, Projects, Google Drive, GitHub integration, MCP, and practical RAG patterns for a document-heavy but not enormous-codebase environment.

Purpose

This document is the cleaned-up handoff from a deeper discussion about how Claude Cowork actually handles knowledge, where it starts to strain, and what the current gold-standard operating pattern looks like for teams that want Claude to work with a large and growing body of documents.

The goal is not to repeat marketing copy. The goal is to help another AI reason accurately about what Claude does natively, what it does not appear to do natively, what users are reporting in the field, and what setup is most sensible for Solanasis-style work.

Executive summary

Claude has multiple knowledge surfaces, and they should not be conflated.

  • Cowork is primarily a local agentic work surface with direct file access, folder instructions, plugins, and sub-agent orchestration.
  • Projects are Claude’s native long-lived knowledge base with built-in project RAG.
  • Google Drive is useful when documents are already living as Google Docs, but its stronger indexed cataloging path is Enterprise-only and narrower than many users assume.
  • MCP is the scaling layer when native retrieval is not enough, especially for hybrid search, external tools, and structured enterprise systems.

The strongest current pattern is not “put everything everywhere.” It is layered retrieval:

  1. Navigation / map layer first
  2. Lexical retrieval second
  3. Semantic retrieval third
  4. Reranking before final context injection

For Solanasis, the likely best pattern is:

  • put stable core knowledge in Projects,
  • use Cowork for active operational work,
  • keep a lightweight knowledge map,
  • and add MCP-backed hybrid retrieval when document sprawl becomes a real problem.

What is known from official Anthropic documentation

1) Cowork is not documented as a persistent local vector database

Anthropic documents Cowork as a workspace that runs locally, works with selected folders, uses folder instructions, and can be extended with plugins that bundle skills, connectors, and sub-agents.

Anthropic does not publicly document Cowork as a feature that automatically builds and exposes a persistent semantic index or vector database over arbitrary local folders.

Implication: treat Cowork as an agentic local operator, not as a guaranteed full-repository semantic retrieval engine.

2) Projects are the official native RAG surface

Anthropic explicitly documents RAG for Projects. When project knowledge approaches context limits on paid plans, Claude automatically enables RAG mode and expands project capacity by up to 10x while maintaining response quality.

Projects therefore appear to be the main native answer to “how does Claude work with a lot of stable reference content?”

Implication: stable, repeatedly referenced material belongs in Projects more naturally than in a raw Cowork folder.

3) Project knowledge is cached

Anthropic’s usage guidance says the more you reuse the same project knowledge, the more you benefit from caching.

Implication: for recurring work, Projects are materially better than re-uploading or re-pasting the same documents repeatedly.

4) Google Drive is useful, but the strong indexed path is narrower than many people assume

Anthropic documents two different Google Drive behaviors:

  • You can add Drive files into a private project’s Files area, and Google Docs added this way sync to the latest version.
  • Google Drive Cataloging is an Enterprise-only feature that indexes Drive content with RAG and, per Anthropic’s docs, currently supports Google Docs only for cataloging, with text extraction and a size cap.

If cataloging is turned off, Claude uses Google APIs to search Drive directly.

Implication: syncing arbitrary local files into Drive does not automatically mean Claude now has a rich indexed RAG layer over everything in that sync folder.

5) GitHub integration is a cleaner native path for code than Google Drive

Anthropic documents GitHub integration as a way to add repositories, files, and folders into Claude so it has relevant coding context, and the docs explicitly advise users to start small.

Implication: if code context needs to be persistent inside Claude’s native knowledge surfaces, GitHub integration is more coherent than trying to use Google Drive as a pseudo-codebase store.

6) Anthropic explicitly recommends code intelligence for code navigation

Anthropic’s Claude Code docs say that code intelligence plugins give Claude precise symbol navigation instead of text-based search, reducing unnecessary file reads.

Implication: for code, symbol-aware navigation should come before broader semantic retrieval.

7) Anthropic’s own retrieval guidance favors hybrid retrieval plus reranking

Anthropic’s public retrieval guidance around Contextual Retrieval argues that embeddings alone are not enough, and that a stronger stack combines:

  • semantic retrieval,
  • lexical retrieval / BM25,
  • and reranking.

Implication: the mature pattern is not “just use vectors.” It is hybrid retrieval.

What is not clearly documented, and should be treated as unknown or inferred

1) Whether Cowork builds hidden embeddings for local folders

Anthropic has not clearly documented the exact retrieval internals for Cowork local folders.

It may do some internal indexing or smart exploration under the hood, but there is no public documentation establishing a persistent local vector database, user-visible indexing controls, or full-folder semantic retrieval guarantees.

Working assumption: Cowork likely relies heavily on selective file exploration, search, and task orchestration, rather than acting as a fully managed local semantic knowledge engine.

2) The exact retrieval stack behind Projects and Drive Cataloging

Anthropic documents the behavior of these systems, but not the precise implementation details. We should not overclaim whether they are vector-only, BM25-only, hybrid, reranked, or some proprietary combination.

Working assumption: treat these surfaces as managed retrieval systems, not as interchangeable with a custom self-hosted RAG stack.

What users are reporting in the field

The following section reflects user-reported observations, primarily from Reddit and current GitHub issues. These are useful signals, but they are not equal to official product guarantees.

1) Dumping too much undifferentiated content into Claude degrades usefulness

A recurring user theme is that broad, unstructured context dumps create retrieval ambiguity, context pollution, and weaker answers.

Power users often respond by creating a map first:

  • repo maps,
  • architecture summaries,
  • file manifests,
  • ADR indexes,
  • SOP indexes,
  • or “card catalog” style summaries.

This matches the more general retrieval principle that navigation beats hoarding.

Users repeatedly recommend Sourcegraph MCP or similar indexed code-search layers when repositories get large enough that plain exploration becomes wasteful.

This is especially useful for exact matches, symbol references, config keys, identifiers, stack traces, and cross-references.

3) Serena and other symbol-aware tooling are useful, but experiences are mixed

Users often praise Serena-style symbolic retrieval for reducing token waste and helping Claude read less code. Other users report that it can feel underwhelming or flaky in some setups.

The important lesson is not “Serena is always best.” The lesson is that symbol-aware navigation is a real category that matters.

4) Users are building custom MCP retrieval servers to avoid context bloat

A visible pattern is people creating their own MCP servers for:

  • vector search,
  • content retrieval,
  • codebase search,
  • persistent memories,
  • and hybrid document lookup.

This is a strong signal that Cowork + native Claude features are powerful, but not always sufficient for large or messy corpora.

5) Users are reporting some friction around indexing and Cowork performance

There are current reports of:

  • project knowledge files getting stuck on indexing,
  • Cowork creating a large VM bundle and slowing Claude Desktop,
  • CPU or idle resource overhead from Cowork services,
  • and occasional workspace startup issues.

These reports should not be read as universal failure, but they are enough to justify an operational posture of keep the setup lean, segmented, and observable.

The core mental model

Use this model when reasoning about Claude:

Cowork = the operator

Cowork is best treated as the agentic work surface that can inspect local files, coordinate subtasks, apply skills, use plugins, and execute work over an active workspace.

Projects = the library

Projects are the durable knowledge base where stable reference materials live and where Claude’s native project RAG is officially documented.

Drive / GitHub = managed feeders into the library

These integrations help get external content into Claude’s orbit, but each has specific tradeoffs and limitations.

MCP = the scaling layer

MCP is where you add custom retrieval, tool access, structured search, hybrid retrieval, and deeper enterprise data access when Claude’s native surfaces are not enough.

Gold-standard architecture in 2026

This is the current best-practice pattern implied by the docs plus current user behavior.

Layer 1: Navigation / map layer

Create small, durable, human-readable orientation artifacts.

Examples:

  • knowledge-map.md
  • sop-index.md
  • architecture-map.md
  • glossary.md
  • client-doc-manifest.csv
  • doc-index.json

Each entry should ideally capture:

  • title,
  • file path or canonical location,
  • document type,
  • owner,
  • last updated date,
  • top headings or sections,
  • 1-3 sentence summary,
  • and tags.

This layer should answer: where should we look first?

This is one of the highest-leverage practices because it reduces aimless exploration and helps both humans and AI stay oriented.

Layer 2: Lexical retrieval

Use exact search for things that benefit from literal matching.

Good candidates:

  • client names,
  • file names,
  • specific acronyms,
  • policy names,
  • error messages,
  • identifiers,
  • and configuration keys.

Tools can include:

  • ripgrep,
  • BM25-style search,
  • Sourcegraph / Zoekt,
  • file manifests,
  • database lookup,
  • or any fast indexed lexical retrieval mechanism.

This layer is indispensable because exact terms still matter.

Layer 3: Semantic retrieval

Use embeddings when the user or the AI does not know the exact phrase, but does know the concept.

Good candidates:

  • “the SOP about client handoff quality,”
  • “the document that explains how we frame resilience without sounding alarmist,”
  • “the note about donor privacy concerns,”
  • “the doc discussing operational chaos even if it doesn’t say operational chaos.”

This layer is especially useful for document-heavy environments where the same idea appears under different wording.

Layer 4: Reranking

After initial retrieval, rerank the candidate results before injecting them into model context.

This keeps context sharp, reduces irrelevant chunks, and lowers the chance of mixing weakly related material into the answer.

If there is one place many weaker setups fall apart, it is here: they retrieve loosely and never properly narrow.

Layer 5: Final context injection

Only feed the best few documents or chunks into the model.

Do not flood the working context with everything that scored above some weak threshold. The goal is not maximum volume. The goal is highest-quality grounding.

What to do for Solanasis specifically

Working assumptions

  • The codebase is not trivial, but also not an enormous monolith.
  • The document corpus is more likely to become the real sprawl problem.
  • The business wants Claude to have broad access to useful information, but not at the cost of turning retrieval into mush.
  • The environment favors lean, practical, AI-native operations.

1) Use Projects for stable, frequently reused documents

Examples:

  • service descriptions,
  • proposals,
  • SOW templates,
  • SOPs,
  • delivery checklists,
  • assessment frameworks,
  • brand/positioning docs,
  • recurring research summaries,
  • legal/policy references,
  • partner-facing collateral.

Why: this is where Anthropic has explicitly documented native project RAG and caching.

2) Use Cowork for active operational workspaces

Examples:

  • the current proposal folder,
  • this month’s client assessment folder,
  • the active implementation repo,
  • a temporary research synthesis workspace,
  • an operations cleanup sprint.

Why: Cowork is strongest when it is acting on a current working set, not pretending to be the sole repository of long-lived knowledge.

3) Maintain a knowledge map outside the model

This is a non-negotiable best practice once documents start accumulating.

At minimum, keep:

  • a master document index,
  • a service-delivery SOP index,
  • a template index,
  • a client deliverable catalog,
  • and an architecture / systems map.

This index can be markdown, CSV, JSON, or some combination, as long as it is clean and regularly updated.

4) Prefer canonical sources over duplicated copies

Pick one authoritative home for each important document whenever possible.

Examples:

  • live Google Doc,
  • project file,
  • GitHub markdown,
  • or controlled local source.

Do not create five near-duplicate copies unless there is a strong reason. Retrieval gets worse when the same concept exists in slightly different versions all over the place.

5) Use Drive selectively, not as a universal answer

Google Drive is helpful when:

  • documents are already living as Google Docs,
  • you want latest-version sync,
  • you are already collaborating there,
  • or you may later use Enterprise cataloging.

Google Drive is not a magic answer for arbitrary synced folders, PDFs, markdown dumps, or source code.

Before adding a full vector layer for code, first ensure you have:

  • code intelligence / symbol navigation,
  • good lexical search,
  • and a small architecture map.

Only add semantic code retrieval when the actual task pattern proves it is needed.

7) Add MCP-backed hybrid retrieval when the document estate outgrows native convenience

This is the point where a custom retrieval layer begins to make sense.

Good triggers:

  • too many documents across too many domains,
  • repeated retrieval misses,
  • duplicated or drifting versions,
  • need for metadata filters,
  • need for source citations,
  • need to search both docs and structured systems,
  • or desire for deterministic, explainable retrieval behavior.

At that point, a hybrid stack behind MCP becomes the right move.

Recommended phased implementation

Phase 1: Native-first and clean

Use Claude’s native surfaces well before overbuilding.

  • Put stable reference docs in Projects.
  • Keep Cowork focused on active work folders.
  • Use GitHub integration for the codebase where appropriate.
  • Use Google Drive only where it is already the natural source.
  • Build the navigation layer immediately.

This phase gives strong gains with relatively low complexity.

Phase 2: Add retrieval discipline

When the corpus grows:

  • improve filenames and folder structure,
  • segment Projects by domain,
  • reduce duplicate copies,
  • maintain metadata,
  • and keep indexes current.

This phase is mostly information architecture, not fancy AI.

Phase 3: Add MCP-backed hybrid retrieval

When native retrieval becomes too fuzzy or too limited:

  • introduce indexed lexical search,
  • add semantic retrieval for conceptual lookup,
  • add reranking,
  • expose it via MCP,
  • and optionally add citation / provenance logic.

This phase is where the system becomes a real knowledge engine rather than just a chat interface with files.

Anti-patterns to avoid

1) “Put everything in one mega-project”

This seems convenient at first, but it tends to create retrieval ambiguity and weaker answers.

Better: segment the corpus by coherent function or domain.

2) “Use Google Drive sync as our RAG strategy”

This is a category error.

Drive may be part of the source-of-truth strategy, but it is not automatically a robust retrieval architecture for all file types.

3) “Vectors solve everything”

They do not.

Exact-match retrieval, symbolic navigation, metadata filtering, and reranking all matter. A vector database alone is usually not the gold standard.

4) “More context is always better”

It is not.

Too much weakly related context creates confusion, contradiction, and hallucination pressure.

5) “Claude remembers our whole organization now”

No.

Claude can retrieve from supported knowledge surfaces and tools, but durable organizational memory still depends on how the corpus is structured, where it lives, and what retrieval path is actually being used.

Practical decision rules

Use these rules when another AI needs to decide how to route a task.

Route to Projects when:

  • the knowledge is stable,
  • it is reused often,
  • it benefits from caching,
  • and it should be available as durable background context.

Route to Cowork when:

  • there is an active folder or active workspace,
  • files need to be read, created, or transformed,
  • the task is agentic and multi-step,
  • and the context is operational rather than archival.

Route to GitHub integration when:

  • the goal is code comprehension,
  • the code context should persist natively in Claude,
  • and the repository or selected folders can be scoped cleanly.

Route to Google Drive when:

  • the canonical source is already a Google Doc,
  • live syncing matters,
  • and the team already uses Drive heavily.

Route to MCP-backed retrieval when:

  • the corpus is large or heterogeneous,
  • the retrieval quality is slipping,
  • source discipline is insufficient,
  • or the task needs stronger search, filters, or provenance.

Suggested artifact set for another AI to maintain

The following artifacts would make the whole environment more legible to future AI agents.

Core maps

  • knowledge-map.md
  • service-offerings-map.md
  • delivery-sop-index.md
  • template-catalog.md
  • systems-architecture-map.md
  • client-doc-manifest.csv

Retrieval support artifacts

  • glossary.md
  • doc-tags.json
  • file-ownership.csv
  • source-of-truth-register.md
  • duplicate-watchlist.md

Code support artifacts

  • repo-map.md
  • module-index.md
  • adr-index.md
  • integration-points.md

The principle is simple: help the AI know where to look before asking it to infer too much from a raw filesystem.

Confidence labels for this handoff

High confidence

  • Projects are the official native Claude RAG surface.
  • Cowork is not publicly documented as a persistent local vector database for arbitrary folders.
  • Google Drive cataloging is Enterprise-only and narrower than a general Drive sync strategy.
  • Code intelligence / symbol-aware navigation is officially recommended for efficient code exploration.
  • Anthropic’s retrieval guidance supports hybrid retrieval plus reranking.

Medium confidence

  • Cowork likely relies more on smart local exploration than on full-persistent semantic local indexing.
  • A segmented Project strategy will usually outperform a giant undifferentiated Project.
  • For Solanasis, documents are likely to justify MCP-backed retrieval sooner than the codebase does.

Lower-confidence / user-reported only

  • The severity and frequency of indexing bugs, VM bundle bloat, or specific performance issues across all environments.
  • The exact usefulness of specific community tools such as Serena or Sourcegraph MCP for every repo and machine setup.

Bottom line

The mature way to think about Claude in 2026 is not “Claude knows everything if we just feed it enough files.”

The mature way is:

  • Projects hold durable knowledge,
  • Cowork handles the active working surface,
  • Drive and GitHub feed managed sources into Claude,
  • and MCP becomes the scaling layer when retrieval quality needs to become more deliberate.

For Solanasis, the most sensible path is to keep the native stack clean first, then add a hybrid retrieval layer only where the actual pain proves it is justified.

That keeps the system lean, resilient, and far more trustworthy than a giant, noisy context dump.

Source notes

The conclusions above are grounded primarily in:

  • Anthropic / Claude help center and docs pages on Cowork, Projects, RAG for Projects, Google Workspace connectors, GitHub integration, Claude Code costs / code intelligence, MCP, and usage guidance.
  • Anthropic’s writeup on Contextual Retrieval.
  • Current user reports from Reddit and current GitHub issues related to Project indexing, Cowork performance, Sourcegraph MCP, Serena, and custom retrieval MCP patterns.

This document intentionally separates officially documented facts from inferences and from user-reported signals.

Graph View

Backlinks