You Probably Don't Need a RAG Pipeline (I Didn't)

Read this blog post and tell me: based on what you know about me and my work, what's useful or relevant here? What should I pay attention to?

https://tangents.bri-guy.com/blog/you-probably-dont-need-rag/

About a year ago, I started building a RAG pipeline for the Stitch design system.

I had the architecture sketched out: AWS Bedrock for the LLM, OpenSearch for vector storage, a Lambda function to chunk and embed our documentation. I was going to build a knowledge base that AI coding assistants could query — a clean interface for agents to understand our components without hallucinating props that don’t exist or inventing patterns that don’t match our conventions.

I was caught up in the hype. Everyone was talking about RAG pipelines, MCP servers, embedding strategies, retrieval accuracy. The assumption was that AI needed special infrastructure to understand your domain knowledge. You couldn’t just point it at files and expect it to work.

Except… you can. And I realized I’d been solving a problem that good information architecture had already solved.

Here’s what I eventually noticed: the work I do as a design system engineer — organizing components, writing consistent documentation, keeping things where people expect to find them — that is the structure an AI agent needs. I wasn’t building a RAG pipeline for AI. I was duplicating work I’d already done.

Let me show you what I mean from the perspective of someone using our design system to build an app.

When a developer installs Stitch, they get a package with a clear entry point. The main index.ts file exports every public component in organized groups:

// Theme utilities for custom theming
export { ThemeProvider, type StitchTheme } from './components/Theme';

// Export all components
export { Button } from './components/Button';
export { Dialog, DialogTrigger } from './components/Dialog';
export { TextField } from './components/TextField';

// Export layout components
export { Columns, Column } from './components/layout/Columns';
export { Stack } from './components/layout/Stack';

This isn’t just a build artifact. It’s a table of contents. An AI agent helping a developer can read this single file and understand what’s available, how things are organized, and the exact import paths. No vector search required.

The one thing I did add was an index file — a short markdown document that explains the key things someone needs to know when using Stitch:

## Core Concepts

- Components don't accept `className` or `style` props
- Styling is controlled through component props and variants
- Components have no outer margin — use layout components for spacing
- `Stack`, `InlineStack`, and `Columns` handle spacing between components

That’s it. A few key rules that prevent 90% of the mistakes people make. An AI assistant that reads this file before helping a developer won’t suggest <Button className="my-style"> because it knows that won’t work. It’ll suggest the right approach: using the component’s built-in props, or wrapping things in layout components.

We also made one small decision that turned out to matter a lot: we bundle our documentation alongside our source code in the published npm package. Our build configuration copies all the stories, MDX documentation, and source files into the dist folder:

dist/
├── stitch.js
├── stitch-documentation/
│   ├── Button.stories.tsx.docs
│   ├── Button.mdx.docs
│   └── ...
└── stitch-source/
    ├── Button.tsx.source
    └── ...

When you npm install @myLibrary, you get the documentation locally. An AI agent assisting a developer doesn’t need to fetch anything. No network requests. No MCP server. No API keys. The knowledge is right there in node_modules, versioned to match the components you’re actually using.

This matters more than it might seem, and not just because of version sync. When an agent has local access to documentation, it explores. It reads one file, notices a reference, opens another, cross-checks something, comes back. There’s no friction. The agent knows what’s available because it can see the filesystem.

When documentation lives on a website somewhere, the agent’s behavior changes. It makes one fetch, forms an opinion based on what comes back, and moves on. Going back to check something has friction. The agent doesn’t know what else is available to ask for. Remote docs invite single-shot retrieval. Local docs invite exploration.

I work on a design system, but I don’t think this lesson is specific to design systems.

The principle I landed on is simple: good information architecture is the best AI strategy.

Think about what makes knowledge easy for a human to navigate: consistent organization, clear entry points, things located where you’d expect them, an index that tells you what’s available. Those are the same things that make knowledge easy for an AI to navigate. We didn’t need special AI infrastructure. We needed the same good practices that help humans find things.

This probably applies beyond code. If you’re in product and you’re thinking about building a RAG pipeline to help agents understand your domain — do you actually need one? Or do you need to organize your documentation better first? If you’re in customer success and you want AI to help answer questions — is the bottleneck retrieval infrastructure, or is it that your knowledge base is a mess of outdated articles with no clear structure?

Sometimes the answer really is RAG. If your knowledge base is dynamic — documents changing independently of deployments, needing to stay synchronized in real-time — then yeah, you need infrastructure for that. If agents don’t have local filesystem access (cloud-based assistants that can only make API calls), you need a server. If you have terabytes of unstructured content that benefits from semantic search, vector databases earn their keep.

But a lot of knowledge isn’t like that. It’s structured by nature. It’s versioned. It can be organized. And if you organize it well, AI agents can navigate it the same way humans can — by reading an index, following consistent patterns, and finding things where they’re supposed to be.

So here’s what I actually built instead of a RAG pipeline:

1. An index file. A markdown document that explains what’s available and where to find it. Points to the right resources for common tasks. Takes fifteen minutes to write, saves hours of agent confusion.

2. Consistent structure. Every component follows the same pattern. Once an agent has seen one, it knows how to find information about any of them. Predictability is a feature.

3. Co-located documentation. The documentation lives with the code, ships with the code, versions with the code. No sync problems. No stale docs.

4. Clear rules for consumers. A short document explaining the key constraints and patterns. “Components don’t accept className props.” “Use layout components for spacing.” The things an AI needs to know to give good advice.

That’s it. No vector database. No retrieval pipeline. No MCP server. Just well-organized files and an index.

I’m not anti-AI-tooling. I spent a year excited about building that RAG pipeline. But I’ve learned to ask a different question first: is the problem that AI can’t access my knowledge, or is the problem that my knowledge isn’t organized well enough for anyone to access — human or AI?

Usually, it’s the second one. And the fix is simpler than it looks.

There’s a sequel to this story. Once you’ve done the information architecture work, you might still want to expose it through an MCP server — for agents that can’t access local files, or to unify multiple knowledge sources into one interface. I’m actually exploring that now.

But here’s the thing: if your docs are well-organized, building that MCP is trivial. You’re just reading files. The hard work was the organization, not the server.