The fastest way to make an agent knowledge base unmanageable is to begin with “import everything.” A useful first knowledge base is smaller and more deliberate: the answers your agent is repeatedly asked for, cannot infer safely, and can trace to a person who owns the answer.

This is good news for a team moving from pilot to production. You do not need a perfect company ontology before the first agent can be useful. You need a high-trust starting set and a workflow for improving it. Twenty focused, approved concepts will often do more for a support or internal agent than twenty thousand unreviewed chunks.

The inclusion test

An answer is a strong candidate when it passes most of these tests:

• Specific: the answer depends on your company, not general world knowledge.
• Repeated: customers, employees, or agents ask for it often.
• Consequential: a wrong answer creates rework, risk, lost margin, or loss of trust.
• Ownable: a person or team can approve the current answer.
• Stable enough to review: it changes deliberately, not every second.
• Scoped: you can say which audiences or agents may retrieve it.

Six useful knowledge domains

1. Policies and eligibility rules

Refund windows, support entitlements, return exclusions, escalation rules, and approval thresholds are ideal candidates. They are company-specific, consequential, and usually have a clear operating owner.

2. Metrics and business definitions

“Active user,” “qualified lead,” “net revenue,” and “resolved ticket” sound universal but rarely are. Record the exact definition, exclusions, time window, owning team, and source event or table. Link the definition to related concepts instead of asking a model to infer them.

3. Product and packaging answers

Plan availability, limits, regional rollout, supported exports, and discount authority change often enough to become dangerous in old decks. Give each answer a stable source and review new revisions when the product changes.

4. Operating procedures

A good procedure states the trigger, first action, deadline, owner, escalation, and actions a person should not take. Lost devices, access requests, incidents, and finance approvals are more useful as focused concepts than as a single hundred-page handbook.

5. Systems and data ownership

Agents helping engineers or analysts need to know which service owns a state, which table is canonical, and which downstream copies lag. These concepts prevent an agent from treating the easiest-to-find table as the source of truth.

6. Approved language and boundaries

Customer-facing descriptions, security-review answers, and statements about what a product does not support can be just as important as feature lists. Classification keeps internal context and externally safe wording in separate retrieval lanes.

What to leave out at first

• Raw chat history with no owner or publication signal.
• Meeting notes that mix decisions, proposals, and abandoned ideas.
• Duplicate pages when nobody has resolved which one is current.
• Secrets, credentials, or sensitive data that should not be in an agent knowledge base.
• Real-time transactional values better fetched from an authenticated operational tool.
• Long documents whose sections belong to different owners or classifications.

Leaving something out is not deleting it. Your wiki or source system can remain the broad record. The approved agent layer is the smaller surface you are willing to make retrievable in a production answer.

A concept template

Keep each concept narrow enough that one owner can review it. The format can stay simple and portable:

---
title: Active user
type: metric
owner: product-analytics
classification: internal
status: approved
---

A user with at least one qualifying session in the trailing 28 days.

Exclude signups with no qualifying session. The source event is events/session.md.

The useful parts are not the YAML syntax. They are the decisions it records: a stable identity, an owner, an audience, an approval state, and a precise definition. A product can present those as a form while preserving a portable file underneath.

Your first-week plan

• Collect ten questions your first agent gets wrong or escalates.
• Group duplicates and assign one owner to each remaining concept.
• Write the current answer and the most important exclusion or boundary.
• Choose the classification each agent should be allowed to retrieve.
• Have a second person review the highest-consequence concepts.
• Connect MCP or REST and run the same ten questions again.
• Turn every new failure into a missing-concept or incorrect-concept decision.

Grow from questions, not from file count

The goal is not to maximize the number of documents. It is to increase the share of important questions an agent can answer from a source your team stands behind. Add concepts when evaluations expose a gap, when a policy changes, or when a domain owner sees repeated confusion.

That creates a knowledge base with a reason for every item, an owner for every change, and a review trail for every approved revision. It is smaller than “everything the company has ever written,” and much more useful to an agent that needs to answer correctly now.