DESIGNING THE KNOWLEDGE BASE STRUCTURE

What should go into the KB?

Prioritize content with repeated-use value:

• Principles;
• Methodology;
• Domain Knowledge;
• Glossary;
• Reference;
• Standards;
• Examples;
• Case studies.

A simple question:

If the Agent does this job again tomorrow, will it still need to know this?

If so, that content may be suitable for the KB.

What should not go into the KB?

Avoid:

• irrelevant files;
• outdated data;
• multiple versions of the same document;
• raw chat;
• unverified notes;
• data that changes daily;
• duplicated content;
• documents whose validity is unclear.

Do not put a file into the KB just because:

“The AI might need it someday.”

One file or many files?

Split by function or topic.

For example:

knowledge/

├── principles/

├── methodology/

├── domain/

├── reference/

└── examples/

Or for a small Agent:

01_CORE_PRINCIPLES.md

02_METHODOLOGY.md

03_DOMAIN_KNOWLEDGE.md

04_GLOSSARY.md

05_EXAMPLES.md

There is no need to split excessively.

Only separate files when each file has a clear role.

File structure

A file should have a clear hierarchy.

For example:

# COMPANY VALUATION
## 1. Principles
## 2. Methods
### P/E
### P/B
### EV/EBITDA
## 3. Special cases
## 4. Common mistakes
## 5. Examples

Avoid a very long file made up only of paragraphs strung one after another.