AGP · Open knowledge engine
Agent context from governed enterprise knowledge.
AGP (Agentic Graph Processor) wrangles unstructured documents and structured metadata into a governed enterprise knowledge graph—retrievable, traceable, and measurable. Open source, air gapped or cloud, developed in the open within Data Trust Engineering.
Enterprise knowledge does not live in one place or one format. It is spread across presentations where the content is in the diagrams, spreadsheets where the meaning is in the column relationships, data models, catalogs, process maps, and conversations that were never written down. Retrieval systems that treat all of it as flat text return plausible answers to the questions that do not matter, and miss the ones that do.
AGP treats that estate as a graph problem. Documents and systems of record are wrangled into one governed knowledge graph under a shared ontology, then served through a retrieval stack where every stage is tunable, every answer is traceable to the path that produced it, and quality is a measured number rather than an impression.
Where It Fits
Context infrastructure for agents and data products, built on messy enterprise knowledge. Not an operating system for the enterprise, and not a chat interface over a document store.
Where it is strong
This is where enterprise tech debt actually lives. Legacy and modern formats, embedded tables and diagrams, duplicates, no consistent metadata.
Built to ground agents in verifiable enterprise knowledge, not to bolt a chatbot onto a data platform.
Control is an explicit toggle, not a governance program.
The same stack runs either way. That portability is the point.
Value on one focused domain in weeks, rather than a platform sized program before anything works.
Every retrieval stage labeled and timed. Every answer scored.
Iterative review, and a sandbox for experimenting before promoting into a governed subject area.
Where it is not the right tool
- Not an enterprise wide operational decision platform at massive scale
- Ontology tooling is practical and iterative rather than as deep as a governed platform with a decade of investment behind it
- Small ecosystem
- Governance is fit for purpose, not a formal operating model
Best fit. Teams working against years of accumulated document sprawl who need reliable agent context or a data product foundation, and who want measured results on one subject area before committing to a platform.
How It Works
Five stages. Model the semantics, wrangle the sources, build and enrich the graph, retrieve from it, expose it.
Capabilities
Ingest
1. Robust Ingestion and Document Wrangling
Rips source documents rather than flattening them to text. Multi format readers for presentations, documents, PDFs, spreadsheets, diagrams and audio. Table aware parsing that preserves column relationships, merged cells and implicit row context that naive parsers destroy. Structural diagram parsing where shape labels become nodes and connectors become relationships, no inference required. Boilerplate stripped before embedding, so retrieval slots are not spent on page numbers and copyright notices. Transcription for the decisions that were only ever spoken.
2. Corpus Hygiene
Content hashing, deduplication and near duplicate detection at ingestion. Version and lineage tracking across multiple copies of the same document. Provenance stamped on every node at creation, so every fact traces back to the file, page or slide it came from.
3. Structured Metadata Integration
Declarative mappings onboard structured sources without writing a connector per system. CSV, Excel, JSON and XML. Proven against logical and physical data models, lakehouse catalogs, application portfolios, business process models, capability hierarchies and organizational structures. Systems of record and document corpora land in the same graph, under the same ontology. That single property is what separates a knowledge graph from a document index.
Graph
4. Ontology and Metamodel Design
Model the enterprise's own semantics rather than accepting a fixed schema. Define the node types, relationship types and properties that form the ontology spine, and extend the model for each subject area without forking the engine. Extraction runs constrained against that governed ontology, so the model drives the pipeline instead of being reverse engineered from whatever a language model happened to produce.
5. Iterative Knowledge Graph Construction
Subject area first, enterprise graph second. Each domain is built and benchmarked before the next is added, so quality compounds rather than averaging out. A shared ontology spine gives every subject area the same vocabulary of node and relationship types, which is what makes those graphs connectable later. Constrained extraction against a governed ontology, or schema free extraction where no ontology exists yet. Triple extraction, validation, coreference resolution, entity resolution and normalization.
6. AI Powered Gap Closing and Ontology Mapping
Enterprise knowledge is full of relationships that are true but were never written down. This finds them. Extracted entities are mapped onto governed ontology types, and candidate relationships are proposed across domains where the evidence supports them but no document states them outright. Every proposal is scored and scoped, dry run by default, and passes a deterministic safety gate before anything is written to the graph. Stewards promote what is right rather than accepting what was guessed.
7. Computed Graph Intelligence
Graph algorithms run across the knowledge graph before any query is served. Community detection clusters related concepts into topic groups. PageRank scores entity importance by how many other important entities reference it. Betweenness centrality surfaces the connector concepts that sit between domains, which are usually the architecturally significant ones. Those scores feed retrieval ranking, so the graph is a computed intelligence layer rather than a store.
Retrieve
8. Tunable Retrieval
Every stage is configurable and inspectable. Hybrid vector and keyword retrieval fused by reciprocal rank fusion, because semantic similarity finds concepts while exact match finds the system name or acronym that similarity quietly misses. Cross encoder reranking. Diversity filtering. Entity seeded expansion. Graph bridge traversal that surfaces cross document evidence along with the exact path that connected it. Document anchoring and topic cluster matching. Query decomposition for compound questions. Deterministic and hybrid modes as an explicit toggle.
9. Impact Analysis and Traceability
What depends on this system. What breaks downstream if this integration fails. Which domains share this data entity. These answers are never in one document, which is why flat retrieval returns the most similar chunk and misses the network entirely. Traversal assembles them, and every answer returns with the graph path that produced it.
10. Measurement
Evaluation is built in rather than bolted on. Every answer is scored asynchronously for faithfulness, answer relevancy, contextual precision and contextual recall. Benchmark suites run per subject area, so retrieval quality is a number before it is a claim.
Surfaces
11. Interfaces and Integration
Four surfaces over one graph. A command line covering every pipeline stage, so ingestion, extraction, graph build, embedding and evaluation are scriptable, schedulable and reproducible rather than click driven. A programmable API for embedding retrieval into other systems. An MCP server exposing the graph and the retrieval stack directly to agent tooling, so AGP becomes the context layer other agents call rather than a destination application. And an interactive interface for question answering and inspection, with every retrieval stage labeled and timed.
Measured, Not Asserted
Retrieval quality is easy to claim and hard to prove. Every answer is scored on four dimensions, and benchmark suites run per subject area against questions built specifically around cross document relationships.
- Faithfulness. Is the answer grounded in what was retrieved
- Answer relevancy. Does it address what was actually asked
- Contextual precision. Was the retrieved context on target
- Contextual recall. Was anything important left behind
One benchmark question moved from zero to near perfect once keyword retrieval surfaced a system integration document that vector search could not see. The answer had been in the corpus the whole time. Flat retrieval never found it. That is the case measurement exists to catch.
What This Is Not
Not an agent in the marketing sense. The retrieval path is fixed and auditable. The model synthesizes from what was retrieved. It does not plan, re-query autonomously, or choose its own next action, with the single exception of the gap closing loop, which has a deterministic safety gate before any write.
Better tooling does not fix an unstructured corpus. Any retrieval system pointed at years of accumulated document sprawl without scoping, graph structure or measurement will produce inconsistent results and quiet hallucinations. The architecture is the fix, not the model.
Air Gapped or Cloud
The same stack runs either way, and that portability is the design point. Document processing, entity extraction, graph reasoning and inference can all run inside the firewall on owned hardware, with no data leaving the building and no third party model inference. That removes the data residency and compliance objections that stall most regulated enterprise AI programs. Where cloud is preferred, it is available, without the architecture having been built around a vendor.
Specifications. A native property graph database with graph data science for the knowledge graph. Local open weight models for extraction, synthesis and embedding, served through Ollama. Runs on consumer GPUs. Fully self hostable, containerized, no managed service dependency.
Open source. The AGP engine is developed in the open as part of Data Trust Engineering. Independent project, 100% open source stack, no employer affiliation.
The problems here are not new. Governed semantics, relationships as first class objects, impact analysis across systems, business language mapped to physical data. Those were the design goals of the enterprise metadata platform documented in the engineering record. What changed is the substrate.
