The Knowledge Base Pattern: How We Made AI Systems Genre-Aware Without Changing Code

Every team building LLM-powered systems faces the same question: How do you make your AI behave differently for different domains?

The obvious answer (different prompts for different domains) works until it doesn't. We've found a better way: externalize domain knowledge entirely. Adding a new domain to your AI system means adding a markdown file. No code changes. No deployments. No prompt surgery.

This pattern works for content generation, document processing, customer support, code review, anywhere you need domain-specific behavior from a shared infrastructure. Here's how it works.

The Prompt-Embedded Knowledge Anti-Pattern

Most LLM systems encode domain knowledge directly in prompts. A fantasy story generator might have a prompt like:

Write a fantasy story with epic world-building, magic systems with
clear rules, a hero's journey arc, and prose that balances action
with atmospheric description. Include at least one mentor figure
and a moment of sacrifice...

This works for a single domain. But what happens when you need romance? Thriller? Young adult coming-of-age? You end up with:

• Enormous prompts that become brittle and hard to maintain
• Scattered knowledge across different files and functions
• Domain-coupled code where adding domains means editing prompts
• Untestable expertise because the knowledge is tangled with the logic

We've seen this pattern in production systems. A prompt file grows to 2,000 lines. Nobody wants to touch it. Changes break things in unexpected ways. The "AI expert" becomes the person who understands the prompt archaeology.

This is the trap. And most teams walk right into it.

Knowledge Base as Single Source of Truth

We took a different approach. All domain knowledge lives in markdown files we call Knowledge Bases (KBs). The system reads them. The LLM interprets them. The code never changes.

A Knowledge Base file contains everything the LLM needs to understand a domain. The structure depends on your use case, but the principle is the same: put all the domain knowledge in one place.

For a content generation system, a KB might include:

## Domain: [Domain Name]

### Context
- Who is the audience?
- What are their expectations?
- What conventions apply?

### Structure
- How should output be organized?
- What sections or components are required?
- What's the typical length/scope?

### Style
- What tone is appropriate?
- What terminology should be used?
- What should be avoided?

### Quality Criteria
- How do we evaluate good output?
- What are the must-haves vs nice-to-haves?
- What are common failure modes?

For a document processing system: the KB might specify field extraction rules, validation logic, and edge case handling for each document type.

For a customer support system: the KB might encode product knowledge, escalation policies, and tone guidelines for each customer segment.

The key insight: the KB is loaded once and flows through every step of the pipeline. The same content informs planning, execution, and evaluation. One source of truth.

"The KB Teaches, Prompts Ask"

This is the meta-principle that makes the pattern work: the KB contains all domain knowledge; prompts are generic wrappers that reference it.

Instead of embedding domain knowledge in the prompt itself, the prompt references the KB:

**Knowledge Base Guidelines:**
{kb_content}

**Your task:**
Generate output following the conventions from the
Knowledge Base above. Pay particular attention to
the structure and quality criteria specified.

The prompt knows how to invoke the task. The KB knows what good output looks like for this domain. They're separate concerns.

This separation means:

• Prompts stay small and generic. They don't balloon with domain knowledge.
• Domain experts can contribute. They edit markdown, not code.
• Changes are localized. Updating domain A doesn't touch domain B.
• Testing is cleaner. You can validate KB content independently.

What This Enables

The practical benefits show up immediately.

Adding domains without code changes. The first domain requires building the infrastructure. Every subsequent domain is just a new markdown file. You can go from one domain to dozens without touching the codebase.

kb/
├── domain_a.md
├── domain_b.md
├── domain_c.md
├── ...

Non-programmers can contribute. Domain experts edit markdown files. They test. They iterate. They improve the system's domain knowledge without touching code. The people who understand the domain best can directly influence how the AI behaves.

Portable knowledge. The same KB can drive different applications. Generation today, evaluation tomorrow, a different product next month. The knowledge is decoupled from any specific use case.

Version-controlled expertise. Git history shows how domain understanding evolves. You can trace improvements, rollback mistakes, and see exactly what changed when quality shifted.

The Architecture in Practice

Here's how the KB flows through a typical multi-step pipeline:

The system loads the KB once. Every subsequent step receives it as context. The pipeline itself is domain-agnostic. It just follows whatever conventions the KB specifies.

One codebase. Many domains. The behavior changes because the KB changes. Not the code.

When This Pattern Applies

The KB pattern isn't universal. It works well when:

• Multiple domains with shared structure: different genres, industries, or contexts that need similar processing but different knowledge
• Evolving expertise: domain knowledge that improves over time and benefits from version control
• Non-technical contributors: domain experts who should influence behavior without coding
• Testable knowledge: you want to validate domain rules independently

It's overkill when:

• Single domain: one context, no variation needed
• Trivial differences: domains differ by a few words, not deep knowledge
• Static knowledge: expertise that won't change

The generalization: any time you're tempted to create domain_a_prompt.txt, domain_b_prompt.txt, domain_c_prompt.txt, stop. You're about to embed knowledge in instructions. Separate them instead.

The Deeper Insight

LLMs are good at reasoning about knowledge. They're not good at storing it reliably.

When you embed domain knowledge in prompts, you're asking the LLM to both store and apply expertise. That's fragile. Prompts get long. Knowledge gets scattered. Changes ripple unpredictably.

When you externalize knowledge to a KB, you're asking the LLM to do what it's good at: read the knowledge, understand the context, and apply it to the task at hand. The knowledge is explicit, version-controlled, and separate from the instructions.

This pattern applies anywhere you need domain-specific AI behavior: content generation, document processing, code review, customer support, data extraction. The domain doesn't matter. The pattern does.

We've used this approach across multiple projects. Every time, the same principle applies: teach the knowledge separately, let the prompts ask the questions.