You sit down on a Sunday afternoon to finally clean up the company wiki. You open the tool you bought eighteen months ago. The home page is the same as it was at launch — three sections, eleven pages, half of them out of date. The "Engineering" page links to a process that nobody follows anymore. The "Onboarding" page references a benefits provider you switched off last year. The "Vendors" page is empty except for a placeholder that says "WIP — to be filled in."
This is the wiki tax. The dedicated tool was supposed to make documentation easier. In practice it added a second job on top of the first one: now you have to remember to open the wiki, navigate to the right section, edit in a structured editor, and hope the formatting survives the next migration. The friction of opening the wiki at all is usually enough to push the update to "later," which means never.
The shape that works better is simpler. The wiki is not a separate tool. The wiki is just the notes you and your team are already writing — meeting notes, project plans, the running list of decisions, the post-incident reflections — gathered in one searchable workspace where an AI assistant can read across all of them.
This post is about how to do that without anyone having to feel like they're "writing wiki content." Adjacent shapes — the SOP layer, the handbook, the institutional knowledge that walks out the door when people leave — are covered in Standard Operating Procedures, Without the Wiki Maintenance Tax, Building an Employee Handbook From the Notes You Already Have, and How to Document Institutional Knowledge Before People Walk Out the Door.
Why dedicated wiki tools die
The honest reason wiki tools die is that updating them is invisible work. Nobody notices when a page is current. Everybody notices when it's wrong. So the page gets written once, used a few times, and then quietly drifts behind reality.
A dedicated wiki tool makes that worse in three ways:
- Context-switching cost. The wiki is "over there" — a different app from where the work happened. To document a new process, you'd have to leave the project doc you were just in and go write a parallel summary in the wiki.
- Format mismatch. Wikis tend to want structured pages with headers and templates. Real working knowledge often comes out as a paragraph in a meeting note, a comment on a PR, a Slack thread. Translating that into wiki shape feels like extra work because it is.
- Discovery problem. Even when content is current, finding it requires knowing the right page existed. New team members don't know what they don't know.
The fix isn't a better wiki tool. The fix is treating the notes the team already writes as the wiki, and using an AI assistant to do the cross-referencing that humans were never going to do consistently.
Markdown notes that double as wiki pages
In Docapybara, every note is a plain markdown page. The same page that holds your meeting notes from last Thursday holds your project plan, your draft pitch, and — yes — your "how onboarding works" doc. There's no separate "wiki" mode. The notes app is the wiki.
That sounds boring. The boring part is the point. When the format of a working note and the format of a wiki page are identical, the activation energy to "make this a wiki page" goes to zero. You write a note. You give it a clear title. It's a wiki page. If someone asks how a process works, you point them at it.
Page nesting goes as deep as you want. A common shape for a small company:
Company → How We Work (the foundational documents — values, decisions, conventions)Company → Roles (one page per role, kept current as the team grows)Company → Vendors (one page per vendor with account info, contact, contract notes)Company → Operations (the running operational SOPs)Projects (a section with one nested folder per active project)Meetings (one page per meeting, organized by week or by team)
Plain markdown means every page is searchable, copyable, and exportable. When a process changes, the diff in version history reads like English — "you added a sentence about the new payment provider, removed the old phone number."
The AI assistant reads across the whole vault
Here's where the wiki stops being a passive document store and becomes something more useful. Capy, the assistant inside Docapybara, has 27 tools and the habit of reading across your entire vault when you ask a question. The kinds of questions that become answerable in seconds:
- "What's our process for onboarding a new contractor?" The agent finds the relevant page (or pages, if the process is split across a few notes) and tells you. If there's no clear page, it tells you that and offers to draft one based on what it can find in scattered meeting notes and project docs.
- "Which of our written conventions contradict each other?" The agent reads across the vault and surfaces the inconsistencies. This is the part that pays for the rest of the setup.
- "What did we decide about the renewal terms with vendor X?" It finds the meeting note or the decision log, locates the relevant decision, and quotes it back with the date.
This is the cross-referencing humans were never going to do consistently. A wiki tool with a search box gives you keyword matches. An assistant that reads across the vault gives you actual answers grounded in your own notes — the agent-acts-on-docs idea is laid out in Claude Code for Documents.
Letting casual notes become structured pages
The hardest part of wiki maintenance is usually the first version. Writing a process doc cold from a blank page is a chore — which is why most never get written.
The shape that works: write the casual version first, ask the assistant to structure it later.
When a new process emerges in a Tuesday meeting, you write the meeting note the way you'd write any other meeting note — paragraphs, bullets, the texture of the conversation. A week later, when you need to actually document the process, you ask the assistant: "Based on the meeting note from last Tuesday and the follow-up Slack thread I dropped on this page, draft a process doc for how we handle X."
What comes back is a first draft you can edit, instead of writing from a blank page. Most of the editing is removing the meeting-context noise and adding the things-you-meant-to-say-but-didn't. The assistant does the work of stitching scattered notes into a structured page; you do the smaller, valuable work of correcting and confirming.
Live databases inside the wiki pages
This is the part that usually surprises teams used to traditional wiki tools. Docapybara lets you embed a live database directly inside any markdown page using a :::database::: directive. It's not a separate tab you open or a linked-out database. The database lives in the same doc as your prose.
For wiki maintenance, that means your operational pages can be both written documentation and live trackers:
- The Vendors page has the written narrative of how each vendor relationship works, plus an inline database with columns for vendor, contract end date, owner, status, last-reviewed
- The Onboarding page has the written process, plus a database tracking who's currently being onboarded and where they are in the steps
- The Project Status page has the written context, plus a database with columns for project, owner, status, last-updated, blockers
Six column types are available, which covers most operational tracking shapes. When the assistant updates a row — "mark the vendor X contract as renewed for another year, due Sept 2027" — the change is live across the page.
PDFs of legacy docs come along
Most companies have a folder of legacy documentation in PDF form — the original employee handbook, scanned vendor contracts, an old SOP doc someone wrote five years ago, a process flowchart from a consultant. They're useful as reference and frustrating as living documents.
Drop those PDFs into Docapybara and the conversion pipeline turns each one into searchable markdown. The agent can now read them, search them, and incorporate them into answers the same way it reads your hand-written pages. When someone asks "what's the original PTO policy from before we updated it last year?", the agent finds it. The original PDF is one click away.
The next step is usually to ask the assistant to draft a markdown rewrite of the PDF, edit it in place, and retire the PDF to an archive folder. The institutional knowledge stays accessible; the format stops being a bottleneck.
A maintenance routine that actually gets done
The whole point of all of this is that maintenance becomes cheap enough that it actually happens. The routine that works for most teams we've talked to:
- Weekly (10 minutes): someone walks the operational status page. Are any tracker rows red? If a process changed this week, mark the relevant page as needing review.
- Monthly (20 minutes): ask the assistant "have any meeting notes from the last 30 days contradicted anything in our written processes?" It scans the recent notes and surfaces the mismatches. Fix the obvious ones in place.
- Quarterly (45 minutes): walk the Needs Review pile. For each one, either confirm it's still right (update the last-reviewed date in the database) or rewrite the relevant section. Ask the assistant to draft the rewrite based on what's true now.
That's it. No wiki tool to maintain on top of the actual notes. No structured editor to fight. The agent does the heavy lifting of cross-referencing; humans do the small, valuable work of deciding what's actually true.
The wikis that survive aren't the ones in the prettiest tool. They're the ones in the tool with the least friction between "I noticed something changed" and "the doc reflects it." A markdown notes app with a built-in assistant gets that friction close to zero. The contrast with a single-file tool is described in Docapybara vs Notion.
Try Docapybara free
The simplest test: open Docapybara, paste in your existing onboarding doc, and ask the assistant for a one-paragraph summary plus a list of any obvious gaps. Five minutes of setup, and you'll know whether having the wiki and the working notes in one place changes the maintenance math.
Try Docapybara free — bring your messiest folder of legacy SOPs and the wiki pages you've been meaning to update for a year. See how the workspace handles them.