How to Keep a Company Wiki and AI Agents Aligned on Current Policy

When an engineer checks the company wiki for a deployment rule or an internal policy and gets a contradicting answer from an AI assistant a moment later, the gap usually comes down to where agent-generated context lives and how updates propagate. If your team updates policy documents in one place while agents rely on disconnected notes, stale indices, or isolated session histories, the two layers quickly drift apart. AKB (Agent Knowledge Base) addresses this structural split by giving AI agents a store for organizational knowledge that agents can read and write, and provides organizational knowledge and memory through the Model Context Protocol (MCP), keeping existing documents and agent-created work context under one Git-versioned, permissioned root. This guide examines how to structure shared agent knowledge, how multi-format retrieval and access boundaries work in practice, and how changes are tracked over time.

How Can You Store Agent Context Alongside Existing Documents?

Keeping an agent layer aligned with human documentation starts with removing the storage divide between static reference files and daily operational work. When an agent investigates an incident, drafts a configuration change, or summarizes a policy update, leaving that output trapped inside a private chat log means the next agent—or team member—reads only the older baseline document. AKB turns scattered enterprise knowledge and agent-generated work context into AI-ready knowledge bases where agents read and write organizational knowledge directly alongside the documents your team already maintains.

Instead of scattering materials across separate tools, documents, files, tables, logs, and conversations live together under a single Git-versioned, permissioned root. Agents interact with this shared store over MCP using a unified tool set—akb_put, akb_search, akb_browse, and akb_relations—while preserving full version history across their reads and writes.

To capture the work that happens during active development, you can also integrate agent plugins directly into your coding workflow. AKB includes the akb-wiki and akb-sessions agent plugins. During a work session, the akb-sessions plugin captures a coding session as structured notes.

What Retrieval and Knowledge Capabilities Do Agents Use?

Policy and operational rules rarely live purely in prose paragraphs; a single compliance check or architectural decision often spans a Markdown guide, a parameter table, and a raw configuration file. AKB stores versioned knowledge in Git and manages standard Markdown documents alongside SQL databases and object storage. Because documents, tables, and files all share the akb:// address scheme, an agent can reference any of these materials through a consistent URI format.

When an agent queries the knowledge base, the same search covers prose, structured tables, and raw files at once. Beyond searching isolated files, the repository applies an ontology-based structure that defines semantic relationships between documents and data, which allows agents to utilize explicit relations among materials when tracing how a policy connects to an underlying table or record.

Different questions during a workflow require different retrieval mechanics:

• Hybrid semantic and keyword search: On the LongMemEval-S benchmark across 500 questions, AKB's hybrid retrieval—combining dense and BM25 search with source-level deduplication, no reranker, and bge-m3@1024 embeddings—achieves a Recall@5 of 98.4%.
• Literal and pattern matching: When an agent needs to find an exact policy identifier, parameter name, or code string, akb_grep searches literally by default and makes regular expression matching available only when explicitly enabled.
• Structured navigation and section reading: akb_browse walks collections in pages, while akb_drill_down lists document headings in outline mode and retrieves matching sections for focused reading.

How Do Agents Access Knowledge Within Permission Boundaries?

Connecting an agent layer to internal policy and operational data requires both standard client connectivity and clear access enforcement. AKB provides organizational knowledge and memory to AI agents through MCP. MCP clients can connect via the akb-mcp stdio proxy, and custom agents can connect over direct HTTP.

Once connected, access to the underlying materials is governed at the root and vault levels. When agents query structured data through akb_sql, AKB enforces PostgreSQL Access Control Lists (ACL) using user and vault roles, rejecting unauthorized vault references right at the vault access boundary. This boundary enforcement controls which vaults an identity can query, though it does not establish per-row permission rules inside a table.

For teams building automated workflows that react when shared knowledge is updated, the platform also supports authenticated event delivery. If you configure redis_url, AKB sends events to a Redis Stream for operator-managed consumers. You can also subscribe to an authenticated, per-vault server-sent events (SSE) endpoint that verifies reader access before streaming notifications.

How Are Updates, Search Indices, and Histories Maintained?

When an AKB document changes, the search index updates with it, avoiding an index that serves an old answer. At the repository layer, every document is committed to Git, allowing you and your agents to return to any point in time across the version history.

When downstream systems monitor the knowledge base for changes, transactional consistency keeps notifications aligned with actual commits. Supported resource changes and their outbox events commit together, which prevents rolled-back operations from producing committed events that would falsely alert a consumer.

However, engineering teams designing governance workflows should separate change notifications from formal compliance histories:

• Scope of resource events: Resource events indicate that a change occurred, but they are not a complete audit record. They do not contain full document bodies, row-by-row differences, or guaranteed exact counts, and event streams do not serve as permanent histories.
• Dedicated audit separation: AKB audit logging is separate from resource change notifications.