KAG: how knowledge graphs can support corporate AI and AI Office

“Which projects depend on the supplier whose shipment is delayed, and who needs to make a decision?” Finding one document containing the word “delivery” will not answer that question. The system needs to connect a counterparty, contract, order, project, deadline and assigned task. Those details may be scattered across files and operational systems.

This is where KAG — Knowledge Augmented Generation — becomes useful. It combines retrieved material with explicitly described relationships between facts. For AI Office, this is a relevant direction: a corporate assistant should use operational context and show the evidence behind its answers. Here is what KAG means, where it can help, and which foundations our prototype already provides.

“RAG uses text; KAG uses graphs” is a convenient but incomplete explanation. The KAG paper combines knowledge graphs with vector retrieval and links graph elements to source text chunks. Documents retain context that cannot be reduced to a few relationships without losing meaning. KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation ↗

In a familiar RAG workflow, the system retrieves relevant material and supplies it to a model to prepare an answer. The original RAG research combined a generator with external retrievable memory. Modern implementations can use several retrieval methods; RAG is not limited to a single basic similarity query. Retrieval-Augmented Generation · Lewis et al. ↗

KAG develops this idea for tasks requiring domain structure and a sequence of checks. It is also the name of a specific OpenSPG framework. Applying similar architectural principles therefore differs from actually deploying OpenSPG/KAG.

A graph helps find a route between facts. Source documents help verify whether that route is justified.

Imagine a map whose nodes represent counterparties, contracts, products, projects and tasks. Its connections have defined meanings: “signed,” “belongs to,” “supplies,” “pays for” or “assigned to.” Objects and relationships carry properties such as identifiers, dates, amounts, statuses and sources.

For example, a company signs a contract containing a delivery stage. The stage belongs to a project, an invoice relates to the stage, a payment is linked to the invoice, and a task requests a performance check. This provides a retrieval route even when the documents use different wording.

Drawing circles and arrows is not enough. Each relationship needs a precise meaning. “An email mentions a contract” is weaker evidence than “this payment is confirmed as covering this invoice.” A model's suggestion must not silently become an established fact.

Stable identifiers matter too. Two counterparties with similar names may be different legal entities. Matching should use verified identifiers and explicit rules, with ambiguous cases referred for human review.

Semantic search is useful for questions such as “where is the purchasing approval procedure?” A question about several projects depending on one supplier requires a chain of facts. One passage may name the supplier, another a deadline, and a third the project without naming the counterparty at all.

RAG can be improved through better document chunking, combined retrieval methods, reranking and repeated searches. A graph becomes especially interesting when the same relationships are needed regularly and can be maintained in a verifiable form.

A retrieval mistake does not automatically justify building a corporate graph. If one current instruction already contains the answer, fixing indexing or access may be sufficient. Additional structure should solve an observed problem.

The official OpenSPG/KAG project describes domain schemas, mutual indexing between graphs and text chunks, and hybrid problem solving guided by logical forms. A route can combine precise retrieval, text search, relationships and calculations. OpenSPG · KAG official repository and architecture ↗

There are two practical stages. First, the system prepares available knowledge: identifying objects, reconciling names and properties, and recording sources. It then breaks a question into verifiable steps and gathers the material needed to answer it.

For a question about tasks associated with a supplier's deliveries, one possible route is to identify the counterparty, retrieve related deliveries, check current states, open connected projects and tasks, and present the result with evidence.

This plan must not let a model execute arbitrary commands. The software defines permitted operations, access checks and calculations. The model helps interpret the question and explain findings; persuasive wording does not grant access to a tool.

GraphRAG can describe approaches that add a graph to retrieval and generation, as well as Microsoft's specific project. Microsoft GraphRAG documentation describes extracting a graph from text, building communities and preparing community summaries for later queries. Microsoft · GraphRAG documentation ↗

OpenSPG/KAG places its own emphasis on professional knowledge schemas and hybrid solving with logical operations. These are not mandatory successive upgrade stages or interchangeable product names. Selection depends on tasks, data and maintenance costs.

For AI Office, the useful question is which relationships improve an answer and how to verify them. Some relationships already fit a conventional database well. Representing knowledge as a graph does not always require a separate graph database; a new store should be justified by queries and workload.

As of 9 September 2026, our software prototype includes document retrieval with current permission checks, source versions and fragment references. It preserves originals of text-based PDF and DOCX files and anchors to pages, paragraphs or table rows. These features support returning from an answer to the material behind it.

Other structured relationships exist within specific workflows. A prepared commercial proposal links to a catalogue version and its source rows. A calculation retains its formula and inputs. Tasks link to the workflow that created them, and consequential actions use the defined approval process. These are foundations for verifiable corporate context.

The current prototype does not implement a full KAG framework, a unified knowledge graph or automatic multi-step solving through OpenSPG. It uses Qdrant for retrieval and SQLite for structured operational data. Relationships between database records alone do not make it a complete KAG implementation.

This distinction matters. Individual workflows already use sources, relationships and reproducible calculations. Combining them into a general knowledge layer is a possible development that needs design and testing. The current prototype also has no live email, CRM or accounting connectors; its financial demonstration uses synthetic records.

One direction is contracts and commercial proposals. A graph could connect a request, selected items, the applicable catalogue, an approved proposal version and later changes to terms. “Why is this the price?” would lead to a specific basis, while catalogue updates would leave historical proposals intact.

Another is procurement. Suppliers, products, offers and confirmed past delivery events could be connected. Comparisons would still need to account for units, configurations, delivery terms and dates. The graph gathers facts; explicit rules calculate comparable amounts.

A third direction is task oversight. A project could lead to an obligation, its dependent task and the responsible person. This would help explain blockers: which information is missing and which decision is required. A recorded dependency does not establish an employee's motivation.

A fourth direction is management reporting. A summary could lead to the calculation's composition and supporting documents. Contracts, performance, forecasts and received funds must remain distinct objects and states. Connected data does not replace an approved calculation method.

Consider a fictional future AI Office workflow. An agreed source records that a shipment has moved to a later date. It is linked to two projects. One has a confirmed reserve; the other has an alternative that still needs approval.

The system retrieves the related projects, checks available reserve information and finds the task covering the alternative. It gives the manager a specific agenda: one project needs a decision, while current evidence indicates that the other has coverage. Supporting documents, verification dates and unknown conditions appear alongside the explanation.

If a shipment-to-project link was merely inferred from an email, it remains unconfirmed. If stock information is stale, the system cannot promise that there is no risk. If some sources are missing, the answer stays within what was actually checked.

The benefit is less manual context gathering. A graph does not predict the future or guarantee a correct decision. It helps expose dependencies and the basis for the next action.

Building a graph is not a one-time folder import. Contracts acquire amendments, staff change, products are combined or split, and incorrect links need correction. A fact needs a source, version, effective time and confirmation status.

Distinguish “not found” from “does not exist.” A missing payment edge does not prove non-payment if the payment never reached the import. A company without a claims history cannot infer that a supplier has a perfect record.

Conflicts need resolution rules. A newer email does not necessarily override a signed term. Matching names do not necessarily identify the same object. Model-extracted relationships need checks proportionate to the consequences of a mistake.

Permissions apply to derived information as well as originals. A restricted contract must not be disclosed through an unrestricted graph summary. Revoking access requires attention to indexes, caches and prepared answers. A knowledge graph does not implement that protection by itself.

Start with questions that current retrieval handles poorly specifically because they require relationships: multiple contracts, event sequences or project dependencies. Prepare cases with known answers, including similar names, old versions, missing information and restricted documents.

Compare existing retrieval, retrieval combined with ordinary structured queries, and a graph-based approach on the same tasks. Measure answer correctness, relationship accuracy, supporting evidence, justified clarification, human verification time and knowledge maintenance cost.

Do not turn another team's research results into a commercial promise. Performance on a public question set does not determine performance on your contracts and reference data. One successful demonstration chain also does not establish reliability across the full workload.

A practical pilot stays within one domain, such as links between catalogue items, proposals and tasks. Results can then guide the choice between OpenSPG/KAG, another graph solution or extensions to the existing database and retrieval layer.

A knowledge graph can be designed within a local environment, but locality needs verification across extraction, embeddings, storage, models and supporting services. An external model remains a separately permitted route. The name KAG says nothing about where data travels.

For AI Office, the value is developing corporate memory in which a document connects to a decision, a decision to a task, and an indicator to its sources. Existing versions, references and calculations provide a foundation without presenting proposed capabilities as a finished product.

If answering a manager's question currently requires assembling a chain across several systems and conversations, it is a useful candidate for a focused pilot. Start with one question and a verifiable set of relationships. KAG then becomes a way to improve a specific workflow.