| name | wiki |
| version | 3.1.0 |
| description | Institutional knowledge wiki — cross-agent source of truth for people, projects, events, decisions, and patterns. Use `wiki query` BEFORE grep/workspace-memory when the question is about who / what happened / what we decided / how we do something. |
| argument-hint | query <question> | status | ingest | absorb | share <article> <agent> |
| tags | ["wiki","knowledge","institutional","cross-agent","retrieval"] |
| triggers | [{"pattern":"who is|who owns|what happened|what did we decide|history of|institutional|runbook|past incident|previous deploy","description":"Questions about persistent cross-agent knowledge"}] |
AgentX Institutional Wiki
You have access to a curated wiki that is shared across all agents in the team. It is the canonical source of truth for institutional knowledge. Your own workspace memory and per-project session history are LOCAL to you; the wiki is SHARED.
When to use the wiki (imperative):
- "Who is X / who owns Y" → query the wiki
- "What happened on DATE" / "past incident about Z" → query the wiki
- "What did we decide about X" → query the wiki
- "How do we do X" (team procedure, not code-level) → query the wiki
- "History of the MTGL deploys" / any "history of" question → query the wiki
When NOT to use the wiki:
- Live data (current GitLab MR status, current issue count) → use
gitlab skill
- Code-level questions ("how does this function work") → read workspace files
- Real-time system status → use
mesh-awareness or curl the daemon
- Anything you already know from the current conversation
The primary command
agentx wiki query "your question"
If agentx is not on PATH, the exact invocation is provided in the [Institutional Wiki] block in your context — copy it verbatim. It's a node /path/to/cli.js wiki query ... call.
The command does three things:
- Reads
_index.md (the catalog organized by article type: person, project, place, concept, event, decision, pattern).
- An LLM selector picks the candidate articles most relevant to the question.
- Walks
related wikilinks 2–3 hops from the candidates, then synthesizes an answer from the walked subgraph — with citations by article title.
You get back: a synthesized answer + a list of cited articles. Every factual claim is grounded in a wiki article.
Other commands
| Command | When |
|---|
agentx wiki status | How many articles exist per agent; am I running low on institutional knowledge? |
agentx wiki ingest | Export recent conversations as raw wiki entries (cheap, just writes markdown) |
agentx wiki share <article> <agent> | Share a private article you own with another agent |
agentx wiki migrate --dry-run | Backfill type + related on legacy articles (operator-run, one-shot) |
agentx wiki prune --dry-run | Collapse legacy mode dirs into graph/ (operator-run, one-shot) |
agentx wiki absorb [--max N] | Compile unabsorbed entries into typed articles (Farzapedia-faithful; nightly cron) |
Article types (the organizational spine)
- person — an individual human (team member, stakeholder, contact)
- project — a named initiative, repo, product, or service (also used for named agents)
- place — a physical or logical location (office, server, environment)
- concept — a recurring idea, philosophy, methodology
- event — a specific dated thing that happened (incident, deploy, launch)
- decision — a specific choice made and why (architecture, policy)
- pattern — a reusable workflow, template, or recipe
When you read a wiki answer, note the [type] tag on each citation — it tells you what kind of knowledge it is.
Retrieval quality notes
The wiki uses an agentic walk of the article graph, not BM25 keyword search. This means:
- It handles questions like "what did we decide about the staging deploy" correctly — those need synthesis across multiple articles.
- It costs ~25 seconds per query (two LLM calls + file reads). Call it when you need it, not speculatively.
- If the wiki has no relevant article, the answer says so plainly. Don't invent.
- If a wiki answer contradicts something you believe, the wiki is usually right — it's the cross-agent authoritative source.
When you should WRITE a wiki article
Only when the operator explicitly asks you to, OR when a task produces a durable, citable artifact (a runbook, an architectural decision, a person profile).
Frontmatter (the exact shape — do not invent fields)
---
title: "Article Title"
type: person | project | place | concept | event | decision | pattern
related: ["Other Article", "Another Article"]
tags: ["2-4-specific-tags"]
owner: <your-agent-id>
access: public | shared | private
shared_with: ["other-agent"]
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
sources: ["entry-id-1"]
---
Writing standards
- Wikipedia-style: flat, factual, encyclopedic. Not a diary entry.
- Synthesize — don't quote more than ~2 short lines.
- Organize by theme, not chronology.
- Use
[[wikilinks]] inside the body for every referenced entity; list the same targets in related frontmatter.
- 20–100 lines. Articles over 100 lines should split.
Access levels
| Content | Access |
|---|
| Project status, team decisions, procedures | public |
| Personal agent learnings, one-off patterns | private |
| Cross-team sensitive knowledge | shared with specific agents |
| Credentials, tokens, keys | private and encrypted — usually don't write at all |
Gap flagging
If you query the wiki and no article covers the topic, add a one-line note to your final response:
Gap: <subject> — no wiki article covers this; <why it matters>
The operator decides whether to ask you to write one, or wait for the procedure-delta flow to land.
