A field guide for companies whose knowledge lives in people's heads, chat threads, shared drives and a help centre nobody has touched since launch. A modern Knowledge Center is not a new wiki. It is one governed home for what the company knows — owned, structured, current and permission-aware — written once and served to four audiences: staff, customers, AI agents, and the search and answer engines that now stand between a business and its buyers. Field Guide 017 covers the retrieval pipeline that feeds agents; this guide covers the system that pipeline depends on. It follows the Guild's twelve-chapter format.
The problem
Every growing company accumulates knowledge faster than it organises it. The symptoms are familiar: two teams give the same customer different answers; new staff learn by interrupting colleagues; the help centre contradicts the sales deck; the policy that matters is a PDF attached to an old email; and when someone leaves, what they knew leaves with them.
AI makes it urgent. An agent pointed at this pile repeats its contradictions at scale, politely and quickly. And answer engines summarise whatever they can find about a company, current or not.
Concept overview
A Knowledge Center has six properties:
- Owned — every item has a person responsible for its accuracy.
- Structured — one item per answer, of a known type, with metadata.
- Current — every item has a review date, and superseded items are retired.
- Permissioned — each item says who may see it, and every channel enforces that.
- Findable — organised by what people are trying to do, with search that is watched.
- Measured — failed searches, feedback and agent abstentions show what is missing.
| Audience | Needs | Served through |
|---|---|---|
| Staff | Policies, procedures, how-tos | An internal portal and search, inside the tools they use |
| Customers | Clear answers to their questions | A help centre and a support agent |
| AI agents | Approved collections with metadata | Permission-aware retrieval with citations |
| Search and answer engines | Clear, citable public answers | Public pages with a consistent structure |
The principle is write once, publish by audience. An answer is not rewritten for every channel; it is one owned item with audience and access flags, published wherever those flags allow.
Hermes note — The aim is not more content. It is fewer, clearer answers that people and agents can trust, check and cite.
When to build one
Build one when the same questions keep arriving, onboarding depends on who has time to explain, agents are planned or already answering, the help centre has drifted from reality, or you need to show which version of a policy was in force on a given day.
Wait when the team is small enough that everyone knows where everything is, or when nobody will own the content. In the second case, settle ownership first; a platform will only make the disorder searchable.
Architecture
| Layer | What it does | The question it answers |
|---|---|---|
| Capture | Knowledge enters from work: resolved tickets, decisions, project close-outs, policy changes | Where is new knowledge created today? |
| Author and review | Templates, owners and review before publishing | Who says this is right? |
| Store | One item per answer, with metadata and history | Where is the current version? |
| Publish | Portal, help centre, public site and agent collections, by audience and access | Who may see this, and where? |
| Measure and improve | Searches, failed searches, feedback, abstentions, review dates | What is missing, wrong or stale? |
In the Citadel, agents meet this system at the knowledge layer — approved context and sources — and the trust controls ask the same of it as this guide does: source ownership, freshness, permissions, citations and retention.
Core components
Content types
Pages that try to teach, instruct and explain at once help nobody. The Diátaxis documentation framework separates tutorials, how-to guides, reference and explanation because each serves a different need. Add the types a business needs on top, and give each a template.
| Type | Answers | Example | Suggested review |
|---|---|---|---|
| Policy | What are the rules? | Refund policy | On every change; at least yearly |
| Procedure | How do I do this task? | Issuing a credit note | When the system changes; at least every six months |
| Reference | What are the facts? | Product specifications | Owned by the system it describes |
| Explanation | Why is it like this? | Why supplier changes need two approvals | Yearly |
| Onboarding | How do I learn this? | First week in support | When its procedures change |
| Answer | One question, one answer | "Can I change my delivery date?" | With the policy it depends on |
| Decision record | What did we decide, and why? | Choosing the CRM | Never edited; superseded |
Ownership and lifecycle
Every item has an owner — a role, with a named person behind it — and a review-by date. Items move from draft to review to published, then to review due, and are either updated or retired. Retire actively: archive with a pointer to the replacement, so links and agents follow. Organisations that want to formalise all this as a management system can look to ISO 30401, the international standard for knowledge management systems.
Metadata
Owner, audience, access level, effective date, review-by date, topic, product or service, status, source system, and what it supersedes. Metadata is what lets one item serve four audiences, lets an agent filter by permission, and lets an answer cite the version that was in force.
Structure and navigation
Organise by what people are trying to do, not by the org chart. Keep the topic set small, phrase titles as questions or tasks, and give every item a stable address.
Search
Search is the front door. Log every search; the ones that return nothing, or that people refine three times, are the to-do list. An assistant answering from the Knowledge Center cites the item it used, or says it found none.
Capture from work
The cheapest moment to write an answer is just after someone has given it. Knowledge-Centered Service (KCS), a method built for support organisations, puts this into the workflow: capture in the moment, structure with templates, reuse by searching first, and improve an item whenever it is used. Agents can draft items from resolved tickets; owners approve them.
Implementation
- Inventory what exists: sources, duplicates, owners, last-updated dates. Expect to retire more than you migrate.
- Collect the top questions per audience from search logs, tickets and onboarding.
- Define types, templates and metadata before choosing a platform.
- Name an owner per topic.
- Write the answers to the top questions first, and retire the duplicates as you go.
- Choose the platform last. It needs permissions, metadata, version history, an API for agents and a public layer.
- Launch to one audience, often staff or support, measure, then widen.
- Connect agents to approved collections only, through permission-aware retrieval.
- Run the review cycle from the first day.
Failure modes
| Failure | What you see | What fixes it |
|---|---|---|
| The great migration | Everything moved, nothing improved | Migrate only what answers real questions |
| Ownerless pages | Quality decays quietly | An owner and a review-by date on every item |
| Duplicate truths | Two pages, two answers | One item per answer; supersede, never copy |
| Org-chart navigation | People cannot find what they need | Organise by task and question |
| Permission drift | Internal detail in a public answer | Access in metadata, enforced at publishing and retrieval |
| Launch and leave | Failed searches pile up unread | A monthly review of failed searches and feedback |
| Agent-only knowledge | Agents answer from material staff cannot see or check | One source for people and agents |
Evaluation
Start with three numbers: the share of top questions with an owned, current answer; the number of items past their review date; and the failed searches reviewed each month. Then add accuracy (owners audit a sample), use (which items support staff reuse), agent signals (abstentions by topic, citations of retired items) and, for public content, whether search and answer engines show the current page.
When agents answer from the Knowledge Center, evaluate their retrieval separately, with the Knowledge retrieval evaluation framework.
Security and governance
- Access lives in metadata, not in folder structure, and every channel enforces it.
- Public publishing needs an approval step.
- Personal data stays in systems of record, not in articles.
- Every edit is versioned and attributable.
- Retirement propagates: when an item is retired, agent indexes and caches follow.
- Content is not a command. Text planted in an item can try to instruct an agent that reads it; agents treat retrieved text as data, and evaluations test it.
Cost considerations
The platform is usually the smaller cost. The larger is people's time: writing, reviewing and retiring. Reduce it with fewer and better items, templates, capture inside the support workflow, agents drafting from resolved tickets for owners to approve, and retiring what nobody reads. The cost of not doing it is paid anyway — in repeated questions, slower onboarding and agents that answer from the wrong version.
Example
Illustrative example, not a client engagement.
A property-management company handles tenant enquiries by phone and email. Its procedures are spread over shared drives and inboxes, and it plans a tenant-facing assistant. The inventory finds three versions of the maintenance-request procedure, each slightly different.
The team gathers the most frequent tenant questions and the procedures staff use daily. Operations owns maintenance; finance owns rent and deposits. Each tenant question becomes one answer item with an audience flag: tenant answers publish to the help centre and the assistant, while the staff detail behind them stays internal. The assistant cites the item it used or routes the question to the owner. In the first month, failed searches show that tenants keep asking about pets, and no policy exists. Writing one is the Knowledge Center's first improvement.
Checklist
- Every item has an owner, a type, an audience, an access level and a review-by date.
- One item per answer; duplicates are retired with a pointer to the current version.
- Templates exist for each content type.
- Navigation follows tasks and questions, not the org chart.
- Access is enforced in every channel, including agent retrieval.
- Public publishing has an approval step.
- Failed searches and feedback are reviewed every month by the owners.
- Knowledge is captured in the support workflow, not in a separate project.
- Agents use approved collections only, and cite the items they use.
- Retired items leave agent indexes and caches.
- Coverage, freshness and failed searches are reported.
