What is a Company Wiki for AI Agents

A company wiki for AI agents is the official playbook the AI must follow: owned, versioned, and scoped — not a pile of old Drive files that search might find.

Human wikis (Confluence, Notion, SharePoint) were built for people: pages, comments, “someone should update this.” Agent wikis have a harder job. Models will obey the loudest chunk in the prompt unless you separate kinds of text on purpose.

If the discount floor lives in a slide, a Slack rumour, and last year’s deck, an assistant asked to draft an exception will pick whichever document sounds closest to the question. That is not policy. That is folklore with a search box.

The distinction is easy to miss because both surfaces look like “knowledge.” One is a library. The other is a constitution. An agent that can retrieve every file still does not know which file is currently in force unless the runtime loads asserted policy on purpose.

Words you’ll hear

Keep three kinds of text apart:

• Asserted. What the company currently wants. Owned. Dated. Scoped. This is the wiki. At work, this is the pricing floor, the refund rule, the journal-posting checklist, the approved customer language. If legal updated it on Tuesday, the agent must cite Tuesday’s version on Wednesday — not the semantically similar PDF from 2023.
• Retrieved. What exists in systems. Possibly stale or contradictory. That is enterprise RAG: look up authorised files, then answer. Lookup is not the same as “this is policy.” At work, retrieval is last quarter’s board pack, a ticket thread, a contract PDF. Those documents may be true as records. They are not automatically the rule you want the agent to follow next.
• Decided. What we already approved in a run, stored on the lifecycle graph. A signed exception should not silently overwrite the playbook for everyone else. At work, this is “this renewal was allowed 18% because of a named exception.” That fact belongs on the decision chain. It does not become the new global discount floor unless a human promotes it into the wiki.

Other terms you will hear in vendor decks and internal Slack, and how they actually show up:

• Vault. A scoped partition of knowledge (finance vs people ops) with role-based access. At work, finance’s close checklist should not ride along in a recruiting workstream “just in case the model finds it useful.”
• Citation. The answer names the page and version — pricing v4.2 — not “the wiki.” At work, an auditor or a new manager should be able to open the same page the agent used, not reconstruct a vibe.
• Conflict rule. If Drive contradicts the wiki, the wiki wins unless a human promotes a change. At work, this is the only way a retrieval-heavy assistant stops treating the loudest PDF as law.
• Authority marker. Labels such as policy, draft, archive, and local exception. Drafts must not load as binding context.
• Owner. A named role, not “the AI team.” The discount floor is owned by revenue operations or finance, not by whoever last edited a Notion page.
• Review cadence. A date when the page is re-checked. Silence becomes folklore.
• Scope. Which jobs may load this page. People-ops rules are not in the go-to-market context by default.

Most “knowledge bases,” custom GPTs, and giant system prompts fail here because they are either too global (one constitution for every department) or too private (each user pastes rules into a personal assistant). Neither is owned. Neither is maintained.

Why you should care

When official policy is unusable, employees ask consumer models to invent policy. See What is shadow AI. The unofficial tool will synthesise a refund rule or a customer commitment from whatever was pasted. The company still owns the result.

It affects you if:

• Numbers in playbooks disagree with numbers in CRM, and nobody can say which is official.
• People leave. Tacit knowledge — the hallway version of the rule — leaves with them. See What is institutional memory in enterprise AI.
• Legal or finance must cite a version, not a vibe.
• Agents can propose writes. A model that can change CRM without a binding playbook is improvising in production. See What is write-back governance.

What changes by role

Finance. The wiki is where recognition rules, posting checklists, and materiality thresholds live as asserted text. Retrieval of last year’s close pack is not a substitute. If an agent drafts a journal from a Slack thread that contradicts the close checklist, finance needs the conflict rule to fire before a named signer is asked to approve. Token spend also changes: re-deriving the same policy from a pile of PDFs every run is how token economics inflate without improving the artefact.

Legal. Approved language, retention classes, and “do not say” lists belong in asserted pages with owners. A retrieved contract is evidence of what was signed with that counterparty. It is not the company’s current standard terms. Legal also cares that citations name a version. “According to our documents” is not a defence if those documents include drafts.

Operations. Runbooks, escalation thresholds, and supplier exception rules need to be loadable as the current procedure, not as the closest matching incident write-up. Ops already knows that a stale SOP is worse than no SOP, because people follow it. Agents do the same, faster.

Go-to-market. Discount floors, win/loss taxonomies, and approved competitive language are the pages that stop an assistant inventing a concession. GTM also feels the scope problem first: a “help me close this” chat that can see every playbook in the company will mix people-ops rules, finance forecasts, and last year’s campaign into one fluent paragraph.

Security. Vaults and least-privilege loading are access control. Indexing every SharePoint site into a single “brain” is a new store of sensitive data. Security’s question is not “does the model know enough?” It is “which pages is this job allowed to load, and can we prove it?” GDPR-style purpose limitation still applies when the reader is an AI. See What is AI governance.

What people get wrong

The common failure is treating search as policy. Teams export Confluence into a vector index, label it “the brain,” and congratulate themselves for grounding. Search will surface the outdated note because it is semantically close to the question. Grounding on the wrong document is still grounding. It is just grounding on folklore.

The second failure is the personal constitution: each power user pastes rules into a custom GPT. Those rules are not org-owned, not scoped per job, and not cited as a version in an audit. When two users paste different discount floors, the company has two unofficial policies.

The third failure is the mega-prompt. One global instruction block tries to encode every department. It is never current. It cannot be scoped. It cannot be reviewed by the owner of a single domain. It also burns tokens on every call.

What good looks like versus what fails

A good agent wiki has authority markers (policy vs draft vs archive), scope (people-ops rules are not in the go-to-market context by default), versions, named owners, a review cadence, and tables for numbers. Numbers belong in tables because prose rounds them. Agents will quote the table if you give them one.

A good wiki is also written for two audiences: the human who must own the page, and the agent that must cite it. Humans need headings and owners. Agents need unambiguous numbers and conflict rules.

A bad agent wiki is an export of Confluence into a search index. The intranet wiki remains useful for humans. It is still not binding on agents unless the runtime loads a controlled subset. Connection is not the same as “everything in Confluence is policy.”

Adjacent ideas: retrieval without assertion is enterprise RAG. Decisions without a playbook are a lifecycle graph with nothing to cite. A job that loads the wrong vault is a workstream with the wrong attachments.

How this shows up in Nimbus

The Company Wiki is the asserted policy layer every agent team must treat as binding. Workstreams subscribe to wiki sections so scope is enforced at runtime. Pages connect to runs and approvals on the Lifecycle Graph.

The wiki is not a second search engine. Connectors remain the path to live systems, and they default to read-only. Retrieval of Drive or CRM is still retrieval. The wiki is what those reads are interpreted against. When a write is proposed, the named signer should see the playbook version the draft claims to follow.

Perception can ask what the current playbook says, and which run last cited it.

See Wiki. For the job that loads a subset of pages, see Workstreams. For the chain that records which version was used, see Lifecycle Graph.

Questions people actually ask

Isn’t this just Confluence?

Confluence is a human wiki. An agent wiki is a binding subset: owned, versioned, scoped, and loaded on purpose. You can connect Confluence into that layer. Connection is not the same as “everything in Confluence is policy.”

Can’t we just search Drive?

Search is retrieval. Retrieval finds what exists. It does not decide what the company currently wants. If Drive contains three discount floors, search will return the closest one, not the official one.

What if the wiki is wrong?

Then a human updates it, with a version and an owner. Do not let a one-off exception silently become the new global rule. Promote the change; do not hope the next retrieval will “learn.”

How is this different from a custom GPT’s instructions?

Instructions in a personal GPT are not org-owned, not scoped per job, and not cited as a version in an audit. Two users can ship two unofficial policies without anyone noticing until a customer is told the wrong thing.

Do we need a wiki if we already have RAG?

Yes, if agents will act. RAG reduces invention on existing files. It does not mark which file is in force. Without assertion, retrieval-augmented generation is retrieval-augmented folklore. See What is enterprise RAG.

Who should own wiki pages?

The same function that owns the analogue rule. Pricing belongs to revenue operations or finance. Employment language belongs to people ops and legal. “The AI team” is a coordinator, not a policy owner.

How often should pages be reviewed?

On a cadence that matches how often the rule changes, plus a hard date so silence is visible. A discount floor that never expires is how last year’s promotion becomes this year’s default.

What should we put in tables versus prose?

Numbers, thresholds, codes, and “never / always” lists belong in tables. Narrative belongs in prose. Agents quote tables more reliably than they extract a number buried in a paragraph.

Can one wiki serve the whole company?

One product, many vaults. A single unscoped corpus recreates the god workspace. Finance close pages and recruiting pages should not share a default context.

How do exceptions work without rewriting the playbook?

Record the exception on the decision chain — who signed, which page version, which record — and leave the playbook intact unless a human promotes a change. See What is a lifecycle graph.

Will a better model make the wiki unnecessary?

No. Stronger models are better at sounding like policy. That makes an unowned corpus more dangerous, not less. Model routing can send interpretation to a stronger model; it cannot invent an owner. See What is model routing.

How does this relate to access control?

Loading a page is still processing. A recruiting workstream should not load compensation policy “because it might help.” Vaults and workstream subscriptions keep that promise in software rather than in a PDF.

Related reading

What is enterprise RAG, What is institutional memory in enterprise AI, and What is AI governance.

Sources

• ICO, AI and data protection
• GDPR