Categorizing Knowledge
Good categorization makes your knowledge findable and helps you track coverage during the context engineering process.Document Categories
Every knowledge document should have a category:| Category | Description | Examples |
|---|---|---|
| Support Article | Customer-facing help content | FAQ pages, help center articles |
| SOP | Internal procedures | Process docs, how-to guides |
| Policy | Official rules and guidelines | Return policy, refund rules |
| Template | Pre-written content | Email templates, chat macros |
| Other | Anything else | Reference docs, notes |
Using Tags
Tags add another layer of organization:By Topic
orders,shipping,billing,account
By Product
product-a,product-b,premium-tier
By Status
needs-review,outdated,verified
By Source
from-training,from-wiki,tribal-knowledge
Visibility Settings
Control who can see each document:- Internal: For agents and internal processes only
- Public: Can be shared with customers
Organizing for the Process
Think about how you’ll use these documents later:Map to Your Hierarchy
As you categorize, consider:- Which workstream does this relate to?
- Which contact drivers might use this?
- Which scenarios will reference this?
Track Coverage
Use tags to track:mapped- Linked to at least one scenariounmapped- Not yet linked anywhereneeds-guide- Referenced but no step guide written
Best Practices
Consistent Naming
Use a naming convention:Avoid Over-Categorizing
Keep it simple:- 5 categories is enough
- 10-15 tags per project
- More granularity isn’t always better
Document Your System
Create a quick reference for your team:Next Steps
With knowledge collected and categorized:- Define Your Hierarchy - Create structure
- Map Knowledge to Scenarios - Connect the dots