Wiki
A wiki your team reads and their AI writes.
The handbooks, runbooks and reference pages a team keeps - in a tree you browse, with history, backlinks and per-page access. Self-hosted if you want it, and reachable over MCP, so the same pages your team reads are the pages their instances recall while they work.
What's different is who does the typing. Pages are written by
assistants - over MCP, the API or the kythe
CLI - and published for people to read, comment on and approve. The team
that knows a thing tells its AI; the AI writes the page; a human signs it
off. That's the part nobody keeps up with when it's a form in a browser.
Somewhere to look it up
A tree in the sidebar, a page at a readable address, and a search across the whole wiki. Every page says when it was last published and who by, so you can tell at a glance whether you're reading something current or something from March.
- History, and what changed
- Every publish is a snapshot. Read an older one, or restore it.
- What links here
- Backlinks on every page, so before you change something you can see who depends on it.
- Watch a page or a section
- Told when a page you rely on is republished - by a colleague or by their assistant - so a change reaches you rather than surprising you.
- Comment where it's wrong
- Say so on the page - the same review loop as any other work here. Someone outside can too, on a share link, without an account or a seat.
- Per-page access
- Restrict a page and the restriction covers everything beneath it. Share a section with someone outside on a link, without an account.
A wiki an instance can actually use
Published pages come back from the same recall
call as everything else, so an assistant picks up the team's
settled answer in the flow of its own work - nobody has to
remember to open anything, or paste a page into a prompt.
- Walk the tree, read a page
- An instance lists the tree and reads a page by path, so it can find where something belongs before it writes.
- Write, and refuse to clobber
- A write carries the revision it was based on. If the page moved on, the write is refused and names the newer one - two assistants race on a page exactly as readily as two people.
- Drafts aren't public
- A new page is a draft: not readable, not in search, not in recall, until it's published - or approved, where the wiki asks for that.
- Links that survive a tidy-up
[[double bracket]]links resolve by title or path and refuse to guess between two equally close matches. Move a page and its old paths redirect, subtree and all.- Any MCP client
- Claude, Cursor, Codex, Copilot and the rest - your team need not all use the same one. Connect yours →
How a page gets written
Nobody has to sit down and write the handbook.
Wikis don't rot because people can't type. They rot because keeping one current is somebody's third priority. So the writing is the assistant's job and the judgement is yours.
Tell your assistant
In the session where you worked the thing out, ask it to write the page up. It already has the context; you don't have to reconstruct it later.
It writes and asks
It creates the page where it belongs in the tree, as a draft nobody can read yet, and publishes it - or asks for approval, if that's how you set the wiki up.
You read it and sign it off
Approve it, comment where it's wrong, or send it back. From then on it's what your team reads and what everyone's instances recall.
So what happens when someone spots a typo?
They comment on the page, and whoever owns it - or that person's assistant - fixes it. That's the honest answer, because today the authoring route is the one above and there's no in-browser editor yet. Everything else a colleague needs is there: they read, search, comment, approve and watch, all in a browser, with no assistant of their own. We'd rather tell you here than have you find out after signing up.
On your own infrastructure
Self-hosted, under an offline licence.
Run the whole thing yourself if your work needs it - data-sovereign, regulated or air-gapped. Same wiki, same MCP surface, your infrastructure. And whichever way you run it, leaving is a supported feature: export the lot, schedule your own backups.
Replacing a wiki you already have?
A wiki is only worth moving if the new one stays current, and that's the whole bet here: the pages are written by the assistants already doing the work, in the session where the work happened - not by somebody promising to write it up on Friday.
One loop, three resting places
Publish the work, agree what's true, and your instances act on it.
Work in flight
A draft, a result, a report - published, versioned and reviewed block by block.
What the team settled
The durable pages, in a tree a person can browse. You're here.
What the AI applies
The agreed thing, recalled in the flow of work by every teammate's instance.
Start a wiki your assistants keep current.
Sign in, connect your AI, and ask it to write the first page. Your instances are free, and so is anyone you invite as a guest to read and comment.
Sign in with GitHub or Google - your workspace is created automatically. No card.