Wiki Knowledge That Stays Found
Search wikis across title, description, and full body content with tag filters and admin-only status visibility. Inspect version history with author attribution, dates, and change types. Four writes — create draft, edit, change status, soft-delete — every one behind explicit confirmation, and each held to the same permissions the web app enforces.
Why Wikis Become Write-Only Archives
Wikis Agent attacks the four specific failures that turn an active wiki into an unread archive — without forcing teams to re-author what they've already written.
Title-Only Search Misses The Content Inside The Wiki
A wiki titled "Engineering Onboarding Guide" contains the exact answer to a security question in section 4. Search-by-title doesn't surface it. Full-body search is the difference between a wiki that gets read and a wiki that gets re-written.
Version History Is Invisible Without Opening Every Wiki
"When did the on-call escalation matrix last change?" requires opening the wiki, finding the version control panel, scrolling. The agent surfaces version history with author, date, and change type in one prompt — no manual archaeology.
Threaded Discussion Lives Separately From The Wiki Itself
Wiki comments capture institutional context — "we tried this in 2024 and it failed because…" — that never makes it into the body. Without a way to surface threaded comments alongside the wiki, that context disappears with the conversation.
Admins Don't See What's Old, Stale, Or Unread
"Which wikis are nobody reading?" "Which were last updated 18 months ago?" Without get_wiki_stats rolling that up automatically, the wiki garden becomes a wiki jungle within two product cycles.
Conflicting Wikis Coexist Because Nobody Notices The Duplicates
"PTO Policy" exists in the HR space. "Time Off Guidelines" exists in the People Ops space. They contradict each other on the carryover rule. Employees follow whichever they find first. Without surfacing near-duplicate titles or overlapping content, the wiki becomes a maze of subtly wrong answers.
Draft Wikis Get Started And Then Abandoned For Months
A subject expert opens a draft, writes three paragraphs, gets pulled into something else, and never comes back. The draft sits in the system for a year. Without a "stale drafts by author" view, the wiki team keeps starting fresh instead of nudging the existing drafts across the finish line.
Wikis Agent At A Glance
Wikis AI
Full-body search · version + comments · confirmation-gated writes.
Inside Wikis Agent — The Actual Capabilities
Every block below maps to a real tool the agent uses against your Wikis data. Seven read tools cover search, content, metadata, listing, version history, comments, and statistics. Four write tools — create_wiki, update_wiki, update_wiki_status, delete_wiki — each require explicit confirmation, and each enforce the same permissions as the web app: anyone who can author a wiki in the browser can create or edit one here, while status changes and deletion stay admin-only.
Full-Body Search With Tag Filters And Admin Status Scope
Employees ask in plain English; the agent searches title, description, and full body content. Tag filters narrow the scope; admins can additionally filter by status (draft / published / archived). Once a result is selected, the agent returns the full body and rich metadata in structured form.
- search_wikis — natural-language search across title + description + body, with optional tag and (admin-only) status filters.
- get_wiki_content — full body content of a specific wiki by id or title match.
- {"get_wiki_details — metadata" => "author, dates, version count, view count, tags, permissions, status."}
- list_wikis — published wikis sorted by recent / popular / title, optionally tag-filtered.
Version History And Threaded Comments — Audit-Grade
"When did this wiki last change, and who reviewed it?" gets a structured answer — version numbers, change types, authors, and dates in chronological order. Threaded comments surface institutional context that lives outside the wiki body. Both are read-only and pull from the wiki's actual audit log, not the model's recollection.
- get_wiki_versions — version history with version number, change type, author, date, defaulting to 10 versions.
- get_wiki_comments — threaded comments including replies, defaulting to 20 top-level comments.
- get_wiki_stats — total count, status breakdown, most-viewed wikis, recently-updated wikis (admin dashboard).
- Read-only on history — the agent surfaces the audit trail but never rewrites it.
Four Writes — Create, Edit, Status, Delete — All Confirmed
create_wiki writes a draft (title, optional body, optional tags) — never auto- publishes. update_wiki edits title and body under the same per-page permission rules the browser enforces. update_wiki_status flips between draft / published / archived, and delete_wiki is a soft-delete restored from Trash — both admin-only. Every one of the four requires explicit confirmation.
- create_wiki — creates a DRAFT wiki with title + optional body + optional tags. Drafts never auto-publish.
- update_wiki — edits title and body, honouring the page's own edit permission (creator-only, admin-and-creator, or any user) and refusing locked pages — the same rules as the web editor. Published edits record a version.
- update_wiki_status — moves between draft, published, archived. Admin-only, and each transition is confirmation-gated.
- delete_wiki — admin-only soft-delete; the page lands in Trash and an admin can restore it, which the confirmation prompt surfaces.
- Permission parity with the web app — checks happen before the LLM ever sees a tool as available, so the agent can never do something the same person couldn't do in the browser.
Outcomes Teams Can Measure
The agent's job is to make wiki bodies findable, surface change history without manual navigation, and keep every write behind a confirmation. Measure against your pre-agent baseline.
- Body-search hit rate — share of wiki queries that returned a relevant result via body content vs title-only match.
- Wiki re-author rate — drop in new wikis created on topics that already had wiki coverage; if the agent surfaces existing wikis well, duplicates fall.
- Version-history adoption — share of "when did X change?" questions answered through get_wiki_versions vs manual page navigation.
- Stale-wiki burndown — wikis last-updated >12 months ago either refreshed or archived per quarter.
- Write override rate — share of confirmation prompts cancelled vs confirmed; high cancellation indicates the agent is being too aggressive on proposals.
Four Writes, Always With A Human In The Loop
Wikis Agent's confirmation list is 4 entries — create_wiki, update_wiki, update_wiki_status, delete_wiki. Every one requires explicit confirmation. Authoring mirrors the web app, so anyone who can write a wiki in the browser can do it here; status changes and deletion stay admin-only.
- 4 confirmation-gated writes — create_wiki, update_wiki, update_wiki_status, delete_wiki. Status change and delete are additionally admin-only.
- create_wiki produces drafts — never published silently; status transitions are a separate explicit call.
- update_wiki respects the page's own rules — locked pages are refused, and creator-only pages stay creator-only, exactly as in the browser.
- delete is soft — the page moves to Trash and an admin can restore it, and the confirmation prompt makes that visible.
- Status filter is admin-only — non-admins searching wikis can only see published; admins can scope search to draft or archived.
WHAT TEAMS TRY INSTEAD
The four alternatives — and none of them search your full wiki body, honor your draft/archive states, or gate writes behind confirmation
Wiki knowledge usually decays the day after launch. Search returns titles only, drafts leak into published results, and "is this still current" requires a manual sweep. None of the alternatives keep version history, threaded comments, and admin status visibility in one auditable model.
ChatGPT, Claude, or Copilot ("write a wiki about our deploy process")
Generic AI guessing from no source
- Wikis Agent searches the actual wiki body — not just titles, not the open web
- Version history with author attribution surfaces what changed and when — generic AI has no history
- create_wiki produces a draft an admin reviews and publishes; generic AI's output is just text
Confluence AI, Notion AI, Guru AI
Vendor wiki AI — separate seat, separate audit, draft/published bleed
- Reads wiki bodies alongside the rest of the platform (HRIS, training, policies) — vendor AI sees only its wiki silo
- Status filter is admin-only — non-admins never see drafts; vendor tools too often leak unpublished content
- One audit trail; vendor wiki AI forces parallel SSO and ACL sync that drifts the day someone changes team
Glean / generic enterprise search bolted on top
A search vendor crawling the wiki — no write back, no governance
- Knows the wiki app's draft/archive/published states natively — Glean indexes whatever it crawled, regardless of status
- Threaded comments and version history are part of the result, not a separate tool to open
- Four write actions in the same agent — Glean is read-only and never closes the "create / edit / publish / archive" loop
"We're not allowed to use AI on internal wikis"
The status quo — search returns 200 results, nobody reads them
- Full-body semantic search means the right page surfaces from a question, not a keyword guess
- Soft-delete with admin-only confirmation — wikis stay restorable when "delete this" turns out to be wrong
- Status transitions (draft → published → archived) flow through the agent with explicit admin confirmation
PLATFORM ADVANTAGE
Wikis Agent inherits everything the platform already runs
A standalone wiki tool has to plumb each of these. Wikis Agent gets them for free.
Full-body search, not just titles
Search hits the wiki body, description, and tags — not just titles. Knowledge buried in a long page still surfaces.
Status-aware visibility
Non-admins see only published wikis. Admin search can scope to draft or archived — clean separation, no accidental leaks.
Version history with author attribution
Inspect who changed what and when — the version log is a first-class agent tool, not a separate admin console.
Threaded comments visible
The conversation around a wiki page is part of the answer — the agent surfaces threaded comments alongside the canonical text.
Soft-delete with admin restore
delete_wiki is soft and restorable by admin — the confirmation prompt makes that explicit so deletions aren't a one-way door.
RubyLLM model tiering
Full-body search runs on small tier; summarization on standard; drafting on standard. Cost per query stays bounded at large wiki volumes.
INDUSTRY FIT
Industries where wiki knowledge moves the most weight
Wikis Agent shines where institutional knowledge changes weekly and search is the difference between finding and rebuilding.
Technology
Runbooks, ADRs, and on-call playbooks searchable across body content — fewer "rebuild from scratch" incident retrospectives.
Healthcare
Clinical reference and operational wikis surface the current version with attribution — auditors see who reviewed what when.
Financial Services
Internal procedure wikis with strict draft/published states; FINRA examiners see exactly what was authoritative on any given date.
Manufacturing
Engineering and quality knowledge bases searchable by line, station, and material — supervisors find the right page on a kiosk in seconds.
Professional Services
Methodologies, playbooks, and project archives surface across body content — consultants don't reinvent the wheel each engagement.
Public Sector
Policy and procedure wikis with admin-only status filters; within the FedRAMP-eligible boundary, no public-internet AI tool indexing.
WHY MANGOAPPS WINS
An embedded wikis agent beats a Confluence AI, a Glean bolt-on, or a custom search build on every axis
The argument knowledge owners, IT, and compliance all share — and the one a horizontal AI or a search-only vendor structurally cannot answer.
Cheaper than the alternatives
No Confluence AI / Notion AI / Guru per-seat fee, no Glean enterprise contract, no custom search build, no extra KM headcount sweeping for stale pages.
More secure
Four confirmation-gated writes, with status change and delete admin-only; status filter admin-only; every action logged through AiApiLog. Stays inside the tenant.
Easier to deploy
Already deployed if Wikis is enabled. Turn the agent on and full-body search / version history / threaded comments work the same day.
Easier to use
"Find the deploy runbook" / "who last edited the comp guidance" / "archive the old expense policy" — one prompt each.
Easier to manage
Per-business status workflows, admin-only filters, and retention rules sit in the same admin console as every other app's settings.
Easier to extend
New status transitions, new comment thread types, new version-history signals ship as tools — the agent picks them up the same release.
AI is actually better
A vendor or generic AI can search titles. Only Wikis Agent can also search the full body, scope by admin-only status, surface version history and threaded comments, and gate writes through confirmation.
At our head office within HR, marketing, and finance, we use ChatGPT quite a bit, and MangoApps AI Helper is a useful tool for us. As I go around to the stores, I’ve been showing them how the AI Intranet Helper can find things and answer plain language questions about our resources, and they’re quite excited about that.
Alison van Zijl
Head of Human Resources
Full House
Customer Success
MangoApps Customers
Organizations that trust MangoApps to run every workflow across their workforce.
Customer Case Studies
Customer Case Studies
Customer Case Studies
Customer Case Studies
Video Case Studies
Webinars
Frequently Asked Questions About Wikis Agent
11 tools — 7 reads and 4 writes. Reads include search_wikis (title + description + body), get_wiki_content, get_wiki_details, list_wikis, get_wiki_versions, get_wiki_comments, get_wiki_stats. Writes (all confirmation-gated) are create_wiki, update_wiki, update_wiki_status, delete_wiki.
All 4 writes require explicit user confirmation. create_wiki creates drafts only, and update_wiki honours the page's own edit permission and refuses locked pages — the same rules as the web editor, so the agent can never do something the person couldn't do in the browser. update_wiki_status and delete_wiki are additionally admin-only, and delete is a soft-delete an admin can restore from Trash. Permission checks run before the model ever sees a tool as available.
Yes. search_wikis searches title, description, AND body content. Optional tag and status filters narrow the scope (status filter is admin-only — non-admins can only see published wikis).
get_wiki_versions returns version numbers, change types, authors, and dates from the wiki's audit log. The default limit is 10 versions; the tool is read-only. Pair with get_wiki_comments to surface institutional context that lives in threaded discussion.
Body-search hit rate (vs title-only match), wiki re-author rate (duplicates created on already-covered topics should fall), version-history adoption, stale-wiki burndown per quarter, and admin-write override rate (cancelled vs confirmed). Compare against your pre-agent baseline.
Let's Talk
Since 2008, we've been building the employee platform for the frontline, earning the trust of 2 million+ users and an NPS of 78.
Why Choose Us?
- AI-Ready Platform: One intelligent place for every employee and workflow.
- Top Security: HITRUST, ISO & SOC 2 certified.
- Exceptional UX: Delightful on mobile and desktop.
- Proven Results: 98% customer retention rate.
Trusted by Legendary Companies:
Prefer to explore first? Ask AI about Wikis AI Agent →