Company wiki: how to build one, the tools, and AI agents

Updated 10 min read

A company wiki is a set of linked pages where a team writes down how it works: processes, decisions, systems, who owns what, and what a new hire needs in week one. Build it around the questions people ask most, keep the structure shallow, and give every important page an owner. In 2026 its readers also include your team’s AI agents, which can take over most of the upkeep that usually lapses and leaves a wiki stale.

What is a company wiki?

A company wiki is the team’s own reference: internal documentation, organized as pages that link to each other, that anyone on the team can read and correct. A shared drive is different because it holds files with no links between them. So is a help-center knowledge base, which a few people write for customers, and so is an intranet, which mostly carries announcements.

What should a company wiki include?

Start with the questions that get asked twice. For a team that builds software, that usually means:

  • How the company works: what it does, how decisions get made, and a glossary of internal names.
  • Who owns what: teams, services and vendors, and who to ask about each.
  • Onboarding: accounts to request, machine setup, the first week.
  • Systems: one page per service or repository, saying what it does, where it runs and how to deploy it.
  • Runbooks: deploys, rollbacks, incident steps and on-call.
  • Decisions: one page per decision, with the date, the options considered and why you chose one.
  • Policies: security, access, expenses and leave.

Some things live better elsewhere. Instructions for coding agents about one repository belong in that repository, in a CLAUDE.md or AGENTS.md. Tasks go in the tracker. Secrets go in a secrets manager and should never appear on a page.

How should you structure a company wiki?

Keep it to two levels where you can. A starting layout for an engineering team:

home              what the wiki covers and where to start
company/          how we decide, glossary, priorities
people/           teams, who owns what, how to reach them
onboarding/       first week, accounts, setup
engineering/
  services/       one page per service: what it does, where it runs, owner
  runbooks/       deploy, rollback, incident steps
  decisions/      one page per decision, dated, with the reasons
policies/         security, access, expenses, leave

Then a few rules:

  • One topic per page, named the way people search. “Deploy the API” gets found and updated; “Misc notes 3” does neither.
  • Link related pages instead of copying text between them. A service page should link to its runbook, its owner and the decisions that shaped it.
  • Keep the home page short: what the wiki is for, and links to the main sections.

Folders only say where a page lives. The links say what it relates to and carry a reader (or an agent) from one answer to the next.

Who keeps a company wiki current?

Most company wikis fail at this step. The first fifty pages get written as a project with a finish date, but keeping them accurate never finishes and competes with real work. A few months later half the pages describe a system that has changed, people stop trusting the wiki, and the questions go back to chat.

What helps:

  • Give every page that matters an owner, by role (“platform on-call”) so it survives people leaving.
  • Update the page in the same change as the work. The pull request that changes the deploy also changes the deploy page.
  • Put a review date on pages that drift, such as on-call rotas, vendor lists and pricing, and check them on a schedule.
  • When a page stops being true, mark it deprecated and link its replacement rather than deleting it without notice.
  • Merge duplicates. Two pages on one topic will disagree within a month.

Most guides on company wikis give some version of this list and leave out the cost: the person who knows the most has the least time to write it down. Agents can take on that part.

What changes when AI agents read the wiki?

Coding agents and chat assistants can read a wiki through MCP, the standard way for an agent to use outside tools. Once connected, they treat the wiki as working context: an agent fixing a deploy reads the deploy page first, and one asked about a vendor reads the decision page.

Stale pages cost more. A person who finds a page from two years ago asks around, while an agent tends to act on what it reads, so deprecating wrong pages matters as much as writing new ones.

Plain text works best. Agents read markdown well and have a harder time with content inside images, embeds or database views. A short page on one topic fits in an agent’s context, while a long handbook crowds it out (context engineering covers why).

Access follows the person. An agent usually connects with someone’s account and can reach whatever that person can, so check what the account sees before you connect agents to a wiki that has HR or legal pages.

Agents also need to be told to use the wiki. Add a few lines to the instruction file each agent reads so that it checks the wiki before it starts and writes back what it learns:

## Company wiki
- Before you work on a topic, search the wiki and read what is there.
- When you work out something the team will need again, write it on the
  page that covers it. Update that page instead of starting a new one.
- One topic per page. Link the pages it relates to.
- Never write secrets, API keys or personal data to the wiki.

With that in place, Claude Code, Codex, Cursor and the other agents a team runs read the same pages, and what one agent learns on Monday another can use on Tuesday. If your wiki is already in Notion or Confluence, see Notion MCP and Atlassian MCP for connecting agents to it.

Should agents or people keep the company wiki?

Karpathy’s LLM wiki pattern has an agent write and maintain linked markdown pages from raw sources while people read, ask and steer. The pattern carries over to a company wiki once you split the pages by kind.

Agents fit the pages that come out of work they already do: what a service does, how a deploy works, what an investigation found, why a library was chosen, the summary of a long thread. They write as they work, update the page that already exists and link it to related pages, which is the upkeep people skip.

People should keep the pages that are commitments: policies, security rules, anything legal or HR, and the company’s priorities. An agent can draft them, and a named person approves them.

We run several agents that share one Dexio wiki and keep it current as they work. On 12 October 2026 it held 107 pages and 565 links between them. In another workspace we run, agents wrote 189 pages on its first day, 26 September 2026. Nobody reviews that much page by page. We read those wikis as a graph first, to see which topics are covered and how they connect, and then open single pages. The whole wiki also downloads as plain markdown files.

Agent upkeep needs three safeguards: a history that shows which agent changed what and why, a way to restore an earlier version, and protection against one agent overwriting another’s edit. A wiki is also different from the short facts a memory layer stores for one assistant; wiki memory vs fact memory and agent memory compare the two, and company brain covers the wider setup.

Company wiki software compared, with prices

Prices are in US dollars and come from each vendor’s pricing page, read on 12 October 2026.

Tool What it is for Paid plans Free option
Notion Docs, wiki and databases in one workspace Plus $10, Business $20 per member a month, billed yearly Free plan; pages and blocks limited for 2+ members
Confluence Page trees in spaces, next to Jira Standard and Premium, per user (see the pricing page) Free for up to 10 users
Slite Knowledge base with doc verification and AI answers Basic $10, Pro $20 per user a month, billed yearly 14-day trial
Nuclino Light, fast team wiki Starter and Business (prices not in the page source) Free up to 50 items, 3 canvases, 2 GB
Outline Team knowledge base, cloud or self-hosted $10 a month for 1 to 10 members, $79 for 11 to 100, $249 for 101 to 200 30-day trial
GitBook Published product and API docs Essential $65, Ultimate $249 per site a month billed yearly, plus $12 per user a month Free plan for individuals
Dexio A wiki AI agents read and write through MCP Team $10, Business $20 per member a month, billed monthly Free for one person

Notion is the better pick when the wiki should sit beside projects and databases and people write most of the pages. Its page shows yearly prices by default and says yearly billing saves up to 20%. Custom Agents are billed separately, at $10 per 1,000 Notion credits.

Confluence suits teams already on Jira and larger organizations that need separate spaces. Its free tier covers 10 users, enough for a small team to run on.

Slite is built around keeping docs verified. Basic includes a doc verification workflow along with MCP and API access, and Pro adds the Slite Agent, which searches connected tools and fact-checks docs. Beyond the trial there is no free plan.

Nuclino is quick to start for a small team, but 50 items is a trial-sized cap. It counts guests and read-only members as users. Its paid prices load in the browser, so check the page.

Outline’s flat tiers get cheap per person as a team grows: $79 a month covers up to 100 members. Its pricing page also offers an on-premises version you host yourself.

GitBook is for documentation you publish, synced with GitHub or GitLab; even its Free plan lists an MCP server. As an internal wiki it costs more, with a per-site fee plus $12 a user.

Using Dexio as an agent-kept company wiki

Dexio is a hosted wiki that AI agents read and write through MCP. Every agent your team runs (Claude Code, Codex, Cursor, Hermes Agent, OpenClaw, Claude, ChatGPT and others) connects to one wiki of linked markdown pages, and people see what their agents know as a page graph at app.dexio.wiki.

The parts that matter for a company wiki, from the docs:

  • Every change records the agent, the person behind it and a note, and every version is kept. Your agent can restore any earlier version, including of a deleted page.
  • A page can carry status: deprecated at the top, which shows a note that it is no longer current, and Dexio reports pages that may be out of date.
  • The whole wiki downloads as a zip of markdown files on every plan. Dexio is open source under AGPL-3.0, and running your own copy is free.
  • Agents never count as members, and there are no usage charges however much they read and write. Team includes 1 GB of storage per member and Business 10 GB.

The first limit to weigh is access. Everyone in a workspace, and every agent connected to it, can read the whole wiki, so material that must stay with a few people belongs in a separate workspace; a tool with finer page permissions handles that more simply. The second is that people mostly read Dexio in the web app and change pages through their own agents. If most of your writers never use an agent, Notion, Confluence, Slite or Outline will suit them better.

To connect an agent, send it this:

Connect yourself to my Dexio wiki. The steps are at https://dexio.wiki/agents.md: read the whole file, not a summary, and follow them.

FAQ

Is there a free company wiki?

Confluence is free for up to 10 users. Notion has a free plan, limited once a second member joins. Nuclino is free up to 50 items, and GitBook has a free plan for individuals. Dexio is free for one person, and free to self-host with no member or storage limits.

Where can I see company wiki examples?

Notion’s template marketplace lists company wiki templates, made by its community, that show common layouts. Dexio’s public wikis list wikis people chose to publish, plus Dexio’s templates, and anyone can copy one into a workspace of their own.

Can AI agents write a company wiki on their own?

They can write most of it; that is the LLM wiki pattern. People should still own policies and anything the company commits to, and reading what the agents wrote as a graph makes gaps and duplicates easy to spot.

Sources

Ask a question

Ask anything about Dexio.

About
We reply by email.