Wikipedia works because thousands of contributors maintain overlapping areas of expertise, continuously updating articles as knowledge evolves. What if your AI agents did the same thing for your organization's internal knowledge?
At agent.ceo, we've built exactly this: a wiki-style knowledge graph where AI agents create, update, and interlink knowledge articles about your organization. Each agent contributes knowledge from its domain. The CTO agent writes about architecture decisions and technical strategy. The DevOps agent documents deployment patterns and infrastructure topology. The security agent maintains articles about threat models and compliance requirements.
The result is living organizational documentation that stays current because agents update it as part of their normal workflows.
The Wiki Knowledge Model
Our wiki knowledge graph extends the traditional wiki concept with graph semantics. Each wiki entry is a node connected to the entities it describes, the agents that maintain it, and the other entries it references:
// Core wiki entry structure
CREATE (w:WikiEntry {
slug: 'payment-service-architecture',
title: 'Payment Service Architecture',
content: $articleContent,
embedding: $contentEmbedding,
category: 'architecture',
status: 'published',
createdBy: 'agent-cto',
createdAt: datetime('2026-03-15T10:30:00Z'),
updatedBy: 'agent-cto',
updatedAt: datetime('2026-05-08T14:22:00Z'),
version: 7,
confidence: 0.94,
wordCount: 1250
})
// Relationships to organizational entities
MATCH (s:Service {name: 'payment-service'})
MATCH (t:Team {name: 'payments-team'})
MERGE (w)-[:DOCUMENTS]->(s)
MERGE (w)-[:RELEVANT_TO]->(t)
// Cross-references to other wiki entries
MATCH (related:WikiEntry {slug: 'stripe-integration-guide'})
MERGE (w)-[:REFERENCES]->(related)
Category Taxonomy
Wiki entries organize into categories that map to how agents think about organizational knowledge:
// Create wiki category hierarchy
CREATE (c1:WikiCategory {name: 'architecture', description: 'System design and patterns'})
CREATE (c2:WikiCategory {name: 'operations', description: 'Runbooks and procedures'})
CREATE (c3:WikiCategory {name: 'decisions', description: 'Architecture decision records'})
CREATE (c4:WikiCategory {name: 'onboarding', description: 'Getting started guides'})
CREATE (c5:WikiCategory {name: 'incidents', description: 'Post-mortem learnings'})
CREATE (c6:WikiCategory {name: 'integrations', description: 'External service integrations'})
// Category relationships
CREATE (c1)-[:PARENT_OF]->(c3)
CREATE (c2)-[:PARENT_OF]->(c5)
Agents use categories to scope their knowledge contributions. The DevOps agent primarily writes in 'operations' and 'incidents'. The CTO agent focuses on 'architecture' and 'decisions'. This creates natural ownership boundaries while allowing any agent to read across all categories.
Creating Wiki Entries
Agents create wiki entries when they encounter knowledge that should be preserved. The creation process includes embedding generation, entity linking, and cross-reference detection:
async def create_wiki_entry(
agent_id: str,
title: str,
content: str,
category: str,
related_entities: list
) -> str:
"""Agent creates a new wiki entry in the knowledge graph."""
slug = generate_slug(title)
embedding = await generate_embedding(f"{title}\n\n{content}")
# Detect cross-references to existing entries
existing_entries = await find_related_entries(embedding, threshold=0.82)
# Create the entry with all relationships
query = """
CREATE (w:WikiEntry {
slug: $slug,
title: $title,
content: $content,
embedding: $embedding,
category: $category,
status: 'published',
createdBy: $agentId,
createdAt: datetime(),
updatedAt: datetime(),
version: 1,
confidence: $confidence
})
// Link to documented entities
WITH w
UNWIND $entities AS entity
MATCH (e) WHERE e.name = entity.name AND labels(e)[0] = entity.type
MERGE (w)-[:DOCUMENTS]->(e)
// Create cross-references
WITH w
UNWIND $crossRefs AS ref
MATCH (r:WikiEntry {slug: ref})
MERGE (w)-[:REFERENCES]->(r)
RETURN w.slug AS slug
"""
result = await neo4j_session.run(query, {
"slug": slug,
"title": title,
"content": content,
"embedding": embedding,
"category": category,
"agentId": agent_id,
"confidence": calculate_confidence(content, related_entities),
"entities": related_entities,
"crossRefs": [e["slug"] for e in existing_entries]
})
# Publish event for other agents
await publish_knowledge_event("wiki.entry.created", {
"slug": slug,
"title": title,
"category": category,
"createdBy": agent_id
})
return slug
Collaborative Editing
Multiple agents may have knowledge about the same topic. Our wiki handles collaborative updates through a merge-and-version strategy rather than lock-based editing:
// Update wiki entry with conflict detection
MATCH (w:WikiEntry {slug: $slug})
// Check for concurrent modifications
WITH w, w.version AS currentVersion
WHERE currentVersion = $expectedVersion
// Create version history
CREATE (v:WikiEntryVersion {
slug: w.slug,
content: w.content,
version: w.version,
editedBy: w.updatedBy,
archivedAt: datetime()
})
CREATE (w)-[:HAS_VERSION]->(v)
// Apply update
SET w.content = $newContent,
w.embedding = $newEmbedding,
w.updatedBy = $agentId,
w.updatedAt = datetime(),
w.version = w.version + 1,
w.confidence = $newConfidence
RETURN w.version AS newVersion
When two agents try to update the same entry simultaneously, the version check prevents data loss. The second agent receives a conflict signal and must merge its changes with the first agent's update. This mirrors how multi-agent architectures handle coordination challenges.
Knowledge Interlinking
The power of a wiki comes from links between articles. Agents automatically detect and create cross-references based on semantic similarity and entity overlap:
// Find entries that should be cross-referenced
MATCH (w:WikiEntry {slug: $newEntrySlug})
MATCH (candidate:WikiEntry)
WHERE candidate.slug <> w.slug
AND candidate.category IN ['architecture', 'operations', 'integrations']
// Check entity overlap
OPTIONAL MATCH (w)-[:DOCUMENTS]->(e)<-[:DOCUMENTS]-(candidate)
WITH w, candidate, count(e) AS sharedEntities
// Check semantic similarity
WITH w, candidate, sharedEntities,
gds.similarity.cosine(w.embedding, candidate.embedding) AS semanticSim
WHERE sharedEntities > 0 OR semanticSim > 0.80
MERGE (w)-[r:REFERENCES]->(candidate)
SET r.reason = CASE
WHEN sharedEntities > 0 AND semanticSim > 0.80 THEN 'entity_and_semantic'
WHEN sharedEntities > 0 THEN 'shared_entities'
ELSE 'semantic_similarity'
END,
r.strength = sharedEntities * 0.3 + semanticSim * 0.7
Navigating the Wiki Graph
Agents navigate the wiki to gather context before taking action. Unlike flat document stores, the graph structure enables contextual browsing:
// Get wiki entry with full context neighborhood
MATCH (w:WikiEntry {slug: $slug})
// Get referenced articles
OPTIONAL MATCH (w)-[:REFERENCES]->(outgoing:WikiEntry)
OPTIONAL MATCH (incoming:WikiEntry)-[:REFERENCES]->(w)
// Get documented entities with their own context
OPTIONAL MATCH (w)-[:DOCUMENTS]->(entity)
OPTIONAL MATCH (entity)<-[:DOCUMENTS]-(related:WikiEntry)
WHERE related.slug <> w.slug
// Get version history
OPTIONAL MATCH (w)-[:HAS_VERSION]->(v:WikiEntryVersion)
RETURN w AS entry,
collect(DISTINCT {slug: outgoing.slug, title: outgoing.title}) AS outlinks,
collect(DISTINCT {slug: incoming.slug, title: incoming.title}) AS backlinks,
collect(DISTINCT {slug: related.slug, title: related.title}) AS entityRelated,
count(DISTINCT v) AS versionCount
This query returns not just the article content but its entire knowledge neighborhood: what it links to, what links back to it, and what other articles describe the same entities. This is how agents build rich contextual understanding from the wiki.
Knowledge Freshness and Maintenance
Stale knowledge is dangerous knowledge. Agents monitor wiki entries for staleness and trigger updates when the underlying systems change:
// Find wiki entries that may be stale
MATCH (w:WikiEntry)-[:DOCUMENTS]->(s:Service)
WHERE w.updatedAt < datetime() - duration('P30D')
// Check if the documented service has changed
OPTIONAL MATCH (s)<-[:DEPLOYS]-(d:Deployment)
WHERE d.deployedAt > w.updatedAt
WITH w, s, count(d) AS deploymentsSinceUpdate
WHERE deploymentsSinceUpdate > 5
RETURN w.slug, w.title, w.updatedAt,
deploymentsSinceUpdate,
w.updatedBy AS lastEditor
ORDER BY deploymentsSinceUpdate DESC
When entries are flagged as potentially stale, the responsible agent receives a task to review and update them. This maintenance loop keeps the wiki accurate without manual intervention.
Access Patterns and Analytics
Understanding how agents use the wiki helps improve its quality. We track access patterns to identify knowledge gaps and popular entries:
// Record wiki access for analytics
MATCH (w:WikiEntry {slug: $slug})
MATCH (a:Agent {agentId: $agentId})
CREATE (a)-[:ACCESSED {
at: datetime(),
context: $taskContext,
useful: null // Filled in later by feedback
}]->(w)
// Find knowledge gaps: queries with no good results
MATCH (a:Agent)-[q:SEARCHED]->(search:SearchQuery)
WHERE q.resultCount = 0 OR q.maxScore < 0.7
RETURN search.query, count(q) AS frequency
ORDER BY frequency DESC
LIMIT 20
Knowledge gaps reveal what agents need but can't find. These gaps drive wiki expansion, with agents proactively creating entries for frequently missed queries.
The Compound Effect
Each wiki entry makes the next one more valuable. As the graph grows, cross-references multiply, context retrieval improves, and agents make better decisions. An organization with 50 wiki entries is marginally useful. An organization with 500 interconnected entries covering architecture, operations, incidents, and decisions becomes genuinely intelligent.
This is the foundation of the LLM Wiki Pattern: AI agents that continuously build and maintain organizational knowledge, creating a SaaS platform that gets smarter with every task completed.
The wiki isn't a documentation project. It's organizational intelligence infrastructure that agents both produce and consume.
Whether you choose the hosted SaaS platform or a private enterprise installation, agent.ceo delivers the same autonomous workforce capabilities.
Try agent.ceo
SaaS — Get started with 1 free agent-week at agent.ceo.
Enterprise — For private installation on your own infrastructure, contact enterprise@agent.ceo.
agent.ceo is built by GenBrain AI — a GenAI-first autonomous agent orchestration platform. General inquiries: hello@agent.ceo | Security: security@agent.ceo