Agent-ready enterprise RAG

Enterprise data was built for people and apps, not for AI agents.

enterpriseRAG is the RAG platform that closes the gap. It makes your knowledge reachable to agents, keeps permissions enforced as they consume and generate, gives people and agents a shared workspace, and engineers context from real human intent.

Agent-ready · Permission-safe · Collaborative · Context-engineered
Enterprise data
People and apps ready

Current state

SQL DBs, NoSQL DBs, Timeseries
Images, Charts, Diagrams
Reports, Publications, Specs
enterpriseRAG
Indexed
entR MMData

LLM/Agent ready

Chunked, Vectorized, Summarized
Entities, Relations, Keywords
Similarities, Graph, Histograms
Serve
entR Projects

Enterprise grade

Permissioned
Collaborative
Versioned
Why enterpriseRAG

Enterprise data was built for people and apps, not for AI agents — and that leaves four gaps.

Enterprise knowledge was structured for human readers and the applications that serve them. Point an autonomous agent at that same estate and four structural gaps open at once.

01

Unreachable

Most enterprise knowledge sits in systems agents can't access.

02

Unprotected

Existing permissions don't carry over to agents, creating compliance exposure.

03

Incomplete

Human intent, institutional memory, and employee expertise never reach the models.

04

Uncoordinated

No way for teams and agents to work as one accountable unit.

These are gaps in how data is prepared, governed, and shared, not gaps in the model. Better retrieval alone doesn't close them.

What is enterpriseRAG

A RAG platform that closes all four gaps.

enterpriseRAG sits between your enterprise knowledge and your AI agents, turning data built for people into data agents can use safely, under the permissions and intent that already govern it.

01Closes: Unreachable

Agent-ready

Structured and unstructured data that agents can actually use.

02Closes: Unprotected

Permissions at the data layer

Security holds even as agents consume information and generate outputs.

03Closes: Incomplete

Context engineering

Build context from human intent, with people in the loop to capture institutional and tacit knowledge.

04Closes: Uncoordinated

Project workspaces

A shared environment where humans and AI agents collaborate toward a specific organizational intent.

The context engineering workflow

A six-step workflow from knowledge ingestion to versioned, human-curated context delivery.

enterpriseRAG structures retrieval as a deliberate, human-governed process from initial knowledge processing through stakeholder curation and versioned output. Steps 1–4 and 6 run within the platform; generation and evaluation (step 5) happen in your LLM orchestrator of choice.

01
Build enterprise knowledge system
01
Build enterprise knowledge system
Transform enterprise knowledge into a retrieval-ready system. Processing includes chunking, summarisation, keyword extraction, entity extraction, and image/table extraction. This is a one-time setup, with ongoing functionality to keep the knowledge system up-to-date.
02
Define the project scope
02
Define the project scope
The user defines a high-level scope for the context as a Project, establishing the intent that will govern all retrievals within it.
03
Surface candidate material
03
Surface candidate material
The platform surfaces candidates based on project intent through multiple retrieval modalities: vector similarity, keyword matching, knowledge graph traversal, metadata filtering, and structured data queries.
04
Curate contextHUMAN-IN-THE-LOOP
04
Curate contextHUMAN-IN-THE-LOOP
The user reviews candidates, selecting, rejecting, reordering, and annotating them. The assembled context is summarised for review before submission, making explicit what the orchestration engine or LLM will see.
05
Generate and evaluateExternal
05
Generate and evaluateExternal
The LLM Orchestrator (or LLM directly) generates output based on the curated context from enterpriseRAG, a prompt from the user, and a choice of LLM service. The user evaluates the output, refines the prompt, and regenerates as needed.
06
Version and branch
06
Version and branch
Each generation output can be saved in enterpriseRAG as a version, capturing the context, prompt, and output. Users can branch, compare versions, and roll back, following the same mental model as version control in software development.
Retrieval modalities
Six ways to surface candidate material (step 3)
Vector similarity
Semantic nearest-neighbour across chunked and vectorised documents
Keyword search
Term-frequency matching for exact terminology
Metadata filters
Restrict by date range, author, type, or classification
Knowledge graph
Entity and relationship traversal beyond text similarity
Query structured data
Query SQL and No-SQL databases and external APIs
Image metadata
Retrieve images by extracted metadata and generated captions
Platform features

The platform implements eight discrete capabilities, each tracing to a documented enterprise requirement.

Features are not additive. Each capability addresses a specific failure mode in automated RAG or a constraint imposed by regulated enterprise deployments.

01 · Permission fidelity

Access control and IAM integration

Integrates with Microsoft Entra ID and Google Workspace. Document-level permissions for Read, Modify, Delete, Destroy, Share, Process, etc are inherited rather than re-implemented. Any output inherits the union of restrictions on all source documents that contributed to it.

02 · Human primacy

Enterprise content management

Two complementary tiers: a centrally governed repository and user-owned private workspaces. Documents pass through a five-stage processing pipeline for chunking, summarisation, keyword extraction, entity extraction, and image/table extraction before any user interacts with them.

03 · Human primacy

Project-based task management

A Project captures a single intent and contains all artefacts associated with pursuing it: document scope, collaborators, context build history and generated outputs. Projects are deliberately isolated from one another for audit integrity.

04 · Human primacy · Transparency

Context construction and retrieval

Rather than injecting top-k results, the platform provides a structured workspace to build the context. Users select, reject, reorder, and annotate context elements. A context summary can be generated before submission, making explicit what the LLM will see.

05 · Transparency

Versioning and state management

Each saved state captures: selected context elements and generated output. States can be compared side-by-side. Any prior state can be restored. Branching allows parallel exploration of different context strategies for the same task.

06 · Collaboration

Collaborative workflows

Projects can be shared with other stakeholders who contribute to the context construction within their own access boundaries. A user with access to a restricted collection can contribute from it; collaborators without that access see that those elements exist but cannot access the underlying documents.

07 · Model agnosticism

LLM and orchestration flexibility

No constraint on model or orchestration layer. Works with public LLM APIs such as OpenAI, Anthropic, Google OR with privately hosted open-weight models within the enterprise boundary, hybrid configurations, and any orchestration framework via standard interfaces.

08 · Enterprise readiness

Audit, traceability, and observability

All actions including document access, context selection, output generation are logged with user identity and timestamp. Every generated output carries a provenance record linking it to the specific chunks, images, and tables that contributed to it.

Design principles

Four principles, each a direct response to a documented failure mode in enterprise RAG deployments.

Human primacy

Retrieval is a starting point for human judgment, not a replacement for it. Stakeholders inspect, approve, curate, and construct the context before it reaches the LLM. The platform does not attempt to automate this judgment but it creates the conditions under which it can be exercised efficiently.

Transparency

Users see exactly what will be submitted to the model. There are no black-box retrieval steps whose outputs are invisible to the person who initiates the query. Every generated output carries a provenance record linking it to the specific documents that informed it.

Permission fidelity

Access controls on source documents propagate to every derived artefact: context snapshots, prompt configurations, and generated outputs. A report compiled from a Confidential document cannot be shared with a recipient lacking that clearance. Such restrictions are enforced at the platform layer.

Model/Prompt agnosticism

The platform imposes no constraint on which Prompt, LLM or LLM orchestration engine processes the final context. Teams choose the prompts and models that fits their requirements and capabilities. This can be public APIs, privately hosted open-weight models, or hybrid routing based on context sensitivity.

Platform positioning

enterpriseRAG operates as the context engineering layer between enterprise knowledge and AI inference.

It is not an LLM, an embedding model, a vector database, or an orchestration framework. Its function is to ensure inference operates on the right information, assembled by the right people, within the access boundaries already governing those source documents.

Above
Business executivesAnalystsReporting toolsDecision support systemsWorkflow automation
enterpriseRAG
Context engineering workspaceHITL curationPermission enforcementVersioningCollaborationAudit trail
Below
Document storesStructured databasesVector databasesIdentity directoriesLLM APIsOrchestration frameworks

Automated retrieval cannot access the domain knowledge that is not encoded in any document.

Domain experts and executives carry knowledge about their organisation that no document captures: which data sources are reliable, which figures are preliminary, which analyses require corroboration from a second source. This judgment is currently excluded from the AI pipeline entirely.

The Human-in-the-Loop workflow is the mechanism by which this tacit knowledge enters the AI pipeline in a controlled, documented, and repeatable way. The platform does not attempt to automate this judgment. It creates the conditions under which it can be exercised efficiently, with a full audit record of every decision made.

Enterprise-specific constraints

Five constraints that distinguish enterprise RAG deployments from research and prototype implementations.

Access control, multi-stakeholder workflows, auditability, model routing, and data variety are requirements that enterprise organisations cannot defer. enterpriseRAG was designed around these constraints from the outset, not retrofitted to them.

Access control
Enterprise requirement

Source documents carry confidentiality levels. Any output derived from a restricted document must inherit that restriction.

How enterpriseRAG addresses it

Permission inheritance calculator derives output access level from the full set of source permissions. Enforced at the platform layer, not left to user discretion.

Multi-stakeholder workflows
Enterprise requirement

Complex analytical tasks require input from multiple people with different roles and clearances.

How enterpriseRAG addresses it

Projects as shared workspaces with per-user and per-group role assignment. Stakeholders contribute from their own access domain and no permission escalation is possible.

Auditability
Enterprise requirement

Regulated industries require a durable record of what information was provided to an AI system and who authorised its use.

How enterpriseRAG addresses it

All actions logged with user identity and timestamp. Every output carries a provenance record. Audit export API for enterprise SIEM and compliance tooling.

LLM flexibility
Enterprise requirement

Data residency or confidentiality requirements may prevent routing sensitive context to public LLM endpoints.

How enterpriseRAG addresses it

Full support for locally hosted models and hybrid routing. Sensitive context stays within the enterprise boundary; routing is configurable per context sensitivity level.

Data variety
Enterprise requirement

Enterprise corpora span structured databases, unstructured documents, images, tables, and metadata which are often in the same query.

How enterpriseRAG addresses it

Multi-perspective document representations: vectors, knowledge graphs, keyword indexes, extracted images and tables, structured data connectors, temporal and geographical facets.

Contact

Discuss deployment requirements with a solutions engineer.

enterpriseRAG supports cloud, VPC, and air-gapped deployments. Bring your data source inventory, access control model, and LLM preference, we will scope the deployment accordingly.

SOC 2 Type II
On-premises deployment available
No data leaves your boundary