AI-Ready Company Wiki: Architecture and Build Guide

An AI-ready company wiki is a governed source of organizational knowledge that people can edit and AI agents can retrieve with the same permissions, provenance and freshness signals. It is not a chatbot attached to a folder. The useful system separates canonical knowledge, derived indexes, access control, agent delivery and human review.

This guide owns the implementation question: how to design and buy that system. Our Open Knowledge Format guide explains the interchange format, the OpenKB review evaluates one knowledge compiler, and the RAG production checklist covers retrieval quality. Here, we connect those layers into one company-wide operating model.

What makes a company wiki AI-ready?

A wiki becomes AI-ready when the same answer is findable, authorized, attributable, current and testable for both a person and an agent. Adding semantic search improves discovery, but it does not supply ownership, resolve contradictions or preserve document permissions by itself.

Which architecture works for humans and AI agents?

The durable pattern is a six-layer knowledge system. Each layer has one job, so you can replace a search engine or model without moving the source of truth.

1. Source systems. Existing wiki pages, policies, tickets, repositories, databases and approved conversations remain evidence, not an undifferentiated dump.
2. Canonical knowledge. Durable concepts, such as a pricing rule, incident playbook or customer definition, have stable IDs, owners, sources and lifecycle metadata.
3. Governance control plane. Classification, access policy, review dates, approvals, retention and audit records travel with the concept.
4. Derived indexes. Keyword, vector and graph indexes are rebuildable projections. They are never the only copy of the knowledge.
5. Delivery layer. A permission-aware API or MCP server supplies the smallest relevant context and points back to the canonical source.
6. Experiences. Employees browse and edit a wiki; assistants answer questions; agents load context for bounded tasks.

Google Cloud's Open Knowledge Format v0.2 specification is useful at the canonical layer because it keeps concepts in human-readable Markdown while adding optional provenance, verification, lifecycle and freshness fields. It does not define retrieval, permissions or runtime delivery, which is why the other layers still exist.

Should you replace your existing wiki?

Usually not at the start. Treat the current wiki as an authoring surface or evidence source, then build a governed knowledge layer around one valuable workflow. Replacing every page before proving retrieval quality creates a migration project without proving business value.

There are three viable source-of-truth models:

A good pilot can begin with 30 to 50 high-value concepts. Do not ingest the whole company drive. Start with the questions that delay onboarding, support, sales or incident response, and the evidence that answers them.

How should agents retrieve company knowledge?

No single retrieval method wins every question. Use the cheapest method that preserves the needed meaning and evidence.

Evaluation has to include messy user language. Google Cloud's research note on agent discovery evaluation frames retrieval as a needle-in-a-haystack problem and asks how vague a question can become before discovery fails. For a company wiki, test abbreviations, outdated names, incomplete questions and conflicting sources, not only polished prompts written by the implementation team.

How do permissions and agent writes stay safe?

The permission check belongs in the retrieval path. Copying restricted documents into one shared vector index and filtering after generation is too late. Every search and read must derive the caller's identity, intersect it with source-level permissions and return only authorized concepts.

The OWASP guidance on vector and embedding weaknesses identifies cross-context leakage, poisoned knowledge and weak access control as concrete RAG risks. Its mitigations include permission-aware stores, trusted-source validation, classification and retrieval logging.

If the wiki is exposed over MCP, keep authentication and authorization at that boundary. The current MCP security guidance requires inbound requests to be verified and rejects token passthrough because it can bypass controls and break accountability. A search result ID or state handle is not proof that a caller may read the underlying page.

For writes, begin asymmetrically:

• People publish; agents propose. Agents create drafts or patches with source links and a stated reason for the change.
• Reviewers accept a diff. High-impact concepts, such as pricing, legal policy and production runbooks, require named owners.
• Indexes rebuild after approval. Rejected or unreviewed agent output never becomes trusted retrieval context.
• Every answer stays traceable. Log the query, retrieved concept IDs, policy decision, answer and feedback without logging secrets.

Cloudflare's recent enterprise AI agent workspace reference architecture uses the same separation: shared organizational context is published centrally in a versioned, read-only library, while model access, tools, credentials and execution remain governed outside the workspace.

What should every knowledge concept contain?

A concept should answer one durable question and expose enough metadata to decide whether it is safe to use before an agent reads the full body.

---
type: Policy
title: Production incident escalation
owner: team:platform
status: stable
classification: internal
generated: { by: human:platform-lead, at: 2026-08-13T09:00:00Z }
verified: { by: human:security-owner, at: 2026-08-13T11:00:00Z }
stale_after: 2026-11-13
sources:
  - id: incident-policy
    resource: https://intranet.example/policies/incidents
---

# Decision

Page the incident commander for a confirmed severity-one event.

# Exceptions

Customer-managed deployments follow the contract-specific runbook.

# Procedure

1. Open the incident channel.
2. Record the evidence and start time.
3. Page the accountable owner.

The frontmatter is not a substitute for clear prose. It lets a person, deterministic filter or agent reject a stale, deprecated or unauthorized concept before spending time and model context on it.

What does a 30-day pilot look like?

1. Days 1 to 3, choose the workflow. Pick one costly path, such as onboarding a developer, answering support escalations or diagnosing an incident. Define the owner and success metric.
2. Days 4 to 7, create the question set. Collect 25 real questions, expected answers, approved sources, authorized roles and refusal cases.
3. Days 8 to 14, curate the knowledge slice. Normalize 30 to 50 concepts, assign owners, remove duplicates and record contradictions instead of silently merging them.
4. Days 15 to 20, build retrieval and access. Compare keyword and hybrid retrieval, enforce source permissions before retrieval, and return source links with every answer.
5. Days 21 to 25, add both interfaces. Let people browse and correct the material; let one approved agent search and read it through a narrow API or MCP surface.
6. Days 26 to 30, run the blind evaluation. Measure source-backed correctness, retrieval recall, refusal quality, median answer time, reviewer effort and permission failures against the current workflow.

Scale only if the pilot improves a business outcome without weakening access control or creating an unowned content queue. Our internal AI assistant cost model for DACH explains why content preparation, permissions, evaluation and maintenance often matter more than the model bill.

Should you build, buy or extend?

A vendor demo should not decide this. Require an export, permission test and blind evaluation against your own questions. If the system cannot show why an answer was retrieved, who may see it and when its source was last verified, it is not ready to become company memory.

AI-ready company wiki acceptance checklist

1. One named owner for every high-impact concept.
2. Stable IDs and visible links back to approved sources.
3. Explicit status, verification and review date.
4. Source permissions enforced before retrieval.
5. Separate canonical content from rebuildable search indexes.
6. Answers cite the concepts actually retrieved.
7. Agents propose changes through reviewable drafts or diffs.
8. Contradictions and stale knowledge are surfaced, not blended.
9. A fixed evaluation set covers vague queries, refusals and access boundaries.
10. Content export, audit logs and model portability are tested before rollout.