What your wiki needs before an AI assistant can onboard a new hire

A new salesperson asks the wiki whether she can give 25% off an annual plan. The answer says no, names the person who approves it, and links to the page it came from. Nobody was interrupted.

I'm the CEO of Evergreen, and we build Folio, an open-source wiki where every page is a file in Git. This is how its onboarding setup works, shown on a made-up Sales space: Acme, a new hire called Jamie, a manager called Marcus.

The answer is not the interesting part. What the wiki needs underneath it is.

1. Pages are files
   A document is *.md, a table is *.table.md, a form is *.form.md, all inside a Git repository. PostgreSQL keeps the index and the access rules, not the content. The assistant, an IDE and a human in the browser work with the same files, and every change is a commit with an author.

2. Ask mode answers from pages, and the sources are a rule
   Folio AI is a panel with two modes. Ask is read-only, and that is enforced on the server. Agent can also write.

Ask mode. The Sources: line is a link to the page, and one click opens it.

That last line is not magic. Without a rule the assistant only has to name the space and the page. The Sources: line with links is a page in the space's .agent folder. This is the starter we ship, how-to-answer.md:

How to answer
You help a new teammate in their first weeks. Answer from the pages of this space, not from general knowledge.

• Search the space before you answer. Read the page, do not guess from its title.
• Keep the answer short: two to five sentences, or a short list when the answer is a sequence of steps.
• Always end with a line Sources: followed by links to the pages you used, in the form [Page title](/s/<space>/p/<id>).
• Say plainly when the pages do not contain the answer. Do not make up prices, dates, names or rules. Then suggest who to ask, using the page "Escalation". .agent is a folder of ordinary pages that only space administrators can see or edit. Everything in it goes into the context of every run in that space, in Ask and Agent mode, up to about 60,000 characters. For a non-admin those pages simply do not exist: the answer is "page not found". The panel shows ".agent rules (1)" above the input.

A rule is a line of text, and Git remembers it
The manager adds one line to the page:

Before the Sources line, add a line "Next step:" with one concrete action.
Then he asks the same discount question in a new conversation.

The rule applies from the next conversation: an old one keeps its earlier turns in the Cursor SDK. And rules are pages, so they have page history: who added "Next step", when, and a restore button, like any other page.

A form is a table with a front door

At the end of the week the newcomer answers five questions. That is a form page, paired one to one with a table: a form field is a table column.

This is what Folio writes to disk. It is the demo's "Feature requests" table (columns and rows trimmed), serialized by the repository's own codec:

---
folio: table
version: 1
id: 01J00000000000000000000T01
columns:
  - id: title
    name: What do you want?
    type: text
  - id: rating
    name: How much do you need it (1 to 5)
    type: number
  - id: contact
    name: You may contact me
    type: checkbox
views: []
options:
  rowIds: none
---
# Feature requests

<!-- folio:table:begin -->

| What do you want? | How much do you need it (1 to 5) | You may contact me |
| --- | --- | --- |
| Dark theme for the table grid | 3 | [x] |
| PDF export of whiteboards | 4 | [ ] |

<!-- folio:table:end -->
And the form that fronts it:

---
folio: form
version: 1
id: 01J00000000000000000000F01
table: handbook/feature-requests.table.md
title: Request a feature
public: false
submitButton: Send request
fields:
  - columnId: title
    label: What do you want?
    required: true
    kind: text
  - columnId: rating
    label: How much do you need it (1 to 5)
    required: true
    kind: number
---

The table is plain GitHub-renderable Markdown, so a new answer is a diff. The server adds Submitted at and Submitter itself. Anyone with the viewer role or higher can submit while signed in; anonymous answers need the public flag and a share link, both. The answers table can be restricted to the manager: the newcomer's submission still lands, and he cannot read the table.

Views are the manager's inbox

A view is a filter with and/or rules and a sort, stored in the table's front matter. "Needs a follow-up" in the video is an or: the discount ceiling answered is not 10, or the readiness score is 2 or lower. Four rows go in, one stays: the person who wrote 15.

The assistant reports what it could not answer

This is the part I would build first. There are three signals, and none asks anyone to fill in a report: a 👍 or 👎 on each saved answer, a survey ("Did the assistant solve your question?") after every third answer, and a built-in tool the assistant calls itself.

The assistant calls it once per question, and the server enforces that: check and insert run under a per-run advisory lock, questions are compared after normalization, a duplicate inside one run is dropped (it only fills an empty missing), and a run keeps at most three reports. The missing field is rendered as Markdown, and the tool description requires links to the pages the assistant actually opened in this run:

missing: {
  type: 'string',
  description:
    'What is missing or unclear in the documentation, in one or two short sentences. It is rendered as Markdown for the documentation owners: ' +
    'link each Folio page you actually opened in this run that is related to the gap, as [<title>](/s/<space>/p/<id>) ' +
    '... Never invent a link and never link a page you did not read in this run.',
},

"Questions without an answer". The person's own words come first, the assistant's restated question under them, and then what was missing. This frame is from the recording made before the links fix.

An instance administrator sees every conversation. A space administrator sees the same page limited to the spaces they administer. A personal access token is refused there. Opening a conversation is written to the audit log, and the conversation shows a "Who opened this conversation" block with the name and the time.

The space admin writes the missing section, Jamie asks again in a new conversation, and the answer names the finance lead and links to "Refund policy".

That description is the second version. The first one only said what to put in missing, and in the 19 runs we recorded for video the model wrote plain text and linked a page once. So the recording above has no links in the column. We fixed it in the tool description, not in the UI, and a live check afterwards gave links in all 5 of 5 unanswered questions, each to a page the assistant had read in that run.

The same pages for outside agents

/mcp gives any MCP client 23 tools with a personal token or OAuth, including search and fetch for ChatGPT deep research. The client works with your rights and nothing more:

claude mcp add folio --transport http https://<host>/mcp \
  --header "Authorization: Bearer folio_pat_…"

Two things do not carry over: outside agents do not see .agent, and only the built-in assistant records unanswered questions. For outside agents the package has agent-playbook.md, the same rules as an ordinary page.

What it does not do

Folio AI needs a Cursor subscription, and the pages it works with go to Cursor. There is no other provider yet.

Want to take a look?

Folio is open source (MIT): https://github.com/evergreen-it-dev/folio. The demo is at https://demo.foliowiki.online (pick Sam on the sign-in screen; data resets daily), and there is a short tour at https://foliowiki.online.

I'd be glad if it helps you. And I'm glad to talk about AI SDLC and how you can do the same in your own company.