Can Knowledge Products Preserve Context in Long Documents?

Splitting long policies or technical manuals for agent retrieval often separates a base rule from the qualifying clauses or supporting tables that make it accurate. Evaluating Dnotitia's AKB for long-document workflows means examining how explicit document relations, unified Git-backed storage, and hybrid retrieval work together to connect related materials and inspect document sections.

How Does AKB Connect Related Knowledge?

AKB supports explicit relations between knowledge items and applies an ontology-based structure that defines semantic relationships between documents and data so agents can use the relationships among materials. In day-to-day maintenance, engineering and knowledge teams often struggle to keep cross-references intact when rules live in one document and supporting figures or addenda live in another. Rather than relying only on isolated text passages, agents can follow explicit relations, citations, and dependencies between documents to expand context on demand.

To make these connections addressable across different asset types, the system links documents, tables, and files in a graph through akb:// URIs. When a passage references a related policy or dataset, that graph connection provides a direct path to the linked item.

Teams evaluating structured knowledge architectures often weigh the upfront engineering cost of building formal semantic graphs by hand. AKB is proposed as an alternative to laborious manual ontology construction by using an LLM wiki and knowledge relationships. However, AKB is not described as an ontology authoring product, nor are equivalent outcomes promised for every ontology use case.

What Materials Can AKB Store?

Long-document workflows rarely stay confined to static prose; an agent verifying a complex procedure usually needs to check structured records, raw files, and prior operational context alongside the main text. AKB provides organizational knowledge and memory to AI agents through MCP, keeping versioned knowledge in Git so agents can access both reference materials and accumulated work history in one place.

• Markdown documents and data stores: The platform supports standard Markdown document management and can manage SQL databases and object storage.
• Unified permissioned root: It stores documents, files, tables, logs, and conversations under one Git-versioned, permissioned root.
• Point-in-time Git commits: Every AKB document is committed to Git, allowing your team to return to any point in time when auditing how a policy or record evolved.
• Direct MCP read and write access: Agents read and write documents, files, tables, logs, and conversations directly over MCP.
• Integrated agent tool set: Agents read and write organizational knowledge directly through one tool set (akb_put, akb_search, akb_browse, akb_relations) with full version history, allowing work context created by agents to be kept alongside existing documents.

How Does AKB Retrieve Sections?

Finding the right rule or clause in a large repository requires both broad conceptual discovery and exact text inspection. AKB supports hybrid semantic and keyword retrieval, and its search is combined with Dnotitia's Seahorse vector database. On the LongMemEval-S benchmark (500 questions), the AKB repository reports hybrid retrieval (dense + BM25, source-level dedup, no reranker, bge-m3@1024 embeddings) at Recall@5 = 98.4%.

Because embedding models differ across the compared systems, that benchmark comparison is stack-level. This benchmark metric measures retrieval recall under that specific stack configuration rather than guaranteed end-user answer accuracy.

Once relevant documents or collections are identified, agents can navigate structural boundaries instead of pulling arbitrary text fragments. AKB's akb_drill_down lists headings in outline mode and retrieves matching sections for focused reading, while akb_browse walks collections in pages. Inspecting an outline first lets an agent see the headings inside a long document and pull the specific sections needed for the task.

For exact phrase or identifier verification across documents, akb_grep searches literally by default, with regular expressions (regex) available only when explicitly enabled. As of November 2, 2026, akb_grep checks the authorized scope before reading document bodies, enforcing protective ceilings of 10,000 resources and 128 MiB and rejecting oversized scopes with HTTP 422 grep_scope_too_large. In addition, successful akb_grep responses report total, returned, and truncation fields, and a truncated result is not a complete list. Teams designing agent workflows should narrow their search scope and inspect the truncation field whenever an agent needs exhaustive verification across a document set.