Examples show the same architecture at different scales. A personal wiki optimizes for low friction and privacy. A team wiki optimizes for permission boundaries, review gates, and reliable operations.
Personal LLM Wiki
A one-user research and decision system using local files, markdown, and a compact agent schema.
Team LLM Wiki
A reviewed team knowledge base with source intake, access rules, ownership, linting, and releases.
Good versus bad page examples
| Weak page | Better LLM Wiki page | Why it works |
|---|---|---|
| Deployments Deployments usually happen on Fridays. Ask Sam if anything breaks. |
Deployment Process Owner: Platform Team. Status: authoritative. Last reviewed: 2026-04-28. Deployment window: Tuesday-Thursday, 10:00-15:00 Central Time. Approval: release owner and on-call engineer. Rollback: operations/ROLLBACK.md. Agent use: may summarize, check missing items, and draft notes; must not approve, initiate, or execute a deployment. |
It names owner, status, freshness, precise rule, related page, and agent boundary. |
| Customers Enterprise customers like reporting. |
Customer Segments Owner: Product Team. Status: working-draft. Source: Q1 research summary and CRM export dated 2026-04-15. Current claim: regulated enterprise buyers prioritize audit exports and approval workflows. Open question: whether self-serve teams need the same export depth. |
It separates evidence, claim, status, and open question instead of turning a vague note into truth. |
| Architecture The worker handles billing stuff. |
Billing Worker Owner: Platform Team. Status: authoritative. Scope: invoice calculation, retry scheduling, and event publication. Non-goal: payment capture. Dependencies: ledger service, queue, notification service. Related: architecture/DATA_FLOWS.md and decisions/DECISION_LOG.md. |
It gives agents exact boundaries and prevents incorrect implementation assumptions. |