A prototype needs three pieces. Production needs a context layer.
Documents → retrieval → model can prove the idea. Production gets harder when the answer depends on who is asking, what they are allowed to see, which source is authoritative, what customer or account state matters, and whether the agent can take an action.
You can build this yourself. The question is what you want to own.
Basic RAG is straightforward. The engineering grows when the same context has to stay secure, current, measurable and reusable across more than one application.
| Production capability | Build it yourself | DataGOL |
|---|---|---|
| Ingestion & parsing | Build and maintain connectors, parsing and document handling | Configured ingestion across documents, SaaS systems, databases and APIs |
| Context & ontology | Reconstruct business meaning inside each application | Identity, entities, business definitions and source authority are reusable context |
| Hybrid retrieval & reranking | Integrate search, metadata filters and ranking logic | Semantic and exact-match retrieval, reranked by recency, authority and workload |
| Permissions in retrieval | Add entitlement filtering to every retrieval path | Ineligible context is removed before ranking and before it reaches the model |
| Structured + unstructured together | Build separate access patterns and join them in the application | Documents and operational data are queried through one governed context layer |
| Benchmarking & model routing | Test models manually and rework integrations as choices change | Benchmark on your workload, then route models behind the same application boundary |
| Grounding & continuous evals | Build and maintain an evaluation harness per application | Shared evals for retrieval, groundedness, refusal behavior and regressions |
| Cost measurement | Add custom instrumentation after the prototype works | Parsing, retrieval and model cost tracked separately and per query |
| Governed actions | Build tool orchestration, approvals and rollback paths | Propose / approve execution with a trace of what the agent did |
| Private deployment & audit | Treat deployment, traces and auditability as separate platform work | Cloud or private deployment with execution traces captured for debugging and review |
The economics change when this stops being one RAG application. Ingestion, permissions, context, evaluation and runtime infrastructure can be reused across the next agent instead of rebuilt for each one.
The boundary is fairly simple.
Use the smallest architecture that can safely support the workload. DataGOL starts to matter when RAG stops being only document search.
Keep the stack small when the problem is small
- One narrow Q&A use case over a small corpus
- Mostly public or low-risk information
- Documents change infrequently
- No structured operational data is needed
- The agent answers questions but does not take actions
An LLM, a managed vector database and a simple RAG framework may be enough. We wouldn't recommend adding infrastructure you don't need.
When RAG becomes shared production infrastructure
- Multi-source Documents, tables and operational systems together
- Permissions Different customers, employees, partners or tenants
- Authority Freshness and source-of-truth rules affect the answer
- Shared context The same knowledge powers more than one agent
- Governance Evals, cost, audit or private deployment matter
- Actions The agent can propose or execute operational work
What this looks like in production.
Three live engagement patterns. Names are withheld at the customers' request; the numbers are from the actual workloads.
One assistant, three audiences
Public, customer and staff experiences share one context layer; login decides what each audience may retrieve.
A million documents, priced first
Nine models and 190 scored runs established accuracy and economics before the production pipeline was written.
Answers where the team already works
The company wiki is indexed and kept current; the assistant answers inside the chat tool employees already use.
Bring one use case.
We'll benchmark representative data, test retrieval and permissions, identify likely failure modes and estimate production economics — then tell you plainly whether you need a simple RAG stack, DataGOL, or something in between.
Benchmark the workload before you commit to the architecture.
There's no universally "best RAG model" — only the best model for your documents and your questions. We run your documents through several models at once, score each one against ground truth your experts supply, and separate accuracy from cost. The figures below are from one customer's real corpus — a property and financial management firm, nine models, 190 scored runs. Treat the ranking as evidence for that workload, not a general-purpose RAG leaderboard; retrieval accuracy and groundedness are benchmarked separately, in the eval table below.
| Model | Tier | Classify | Extract | $ / doc | @ 1M docs | Role |
|---|---|---|---|---|---|---|
| Gemini 3.7 Flash | Budget | 95.2% | 56.2% | $0.0102 | $10,183 | Top classifier |
| Gemini 2.5 Flash Recommended | Budget | 93.7% | 61.5% | $0.0026 | $2,567 | Best value |
| Qwen3.6 27B | Budget | 90.5% | 62.1% | $0.0178 | $17,788 | Strong both |
| Claude Haiku 4.5 | Mid | 88.9% | 74.2% | $0.0083 | $8,332 | Best extractor |
| Kimi K2.6 | Premium | 86.5% | 60.4% | $0.0193 | $19,276 | Premium option |
| Phi-4 32B | Budget | 57.1% | 39.1% | $0.0006 | $585 | Pre-screening |
No single model won at both classification and extraction — Gemini 3.7 Flash classifies best, Claude Haiku 4.5 extracts best, and the recommended chain splits the work between two models rather than compromising on one. At this document scale, parsing and page processing are roughly 84% of the bill; the model is the other 16%. Optimizing only the model misses the bigger lever.
Measured separately, not blended
Classification, extraction, retrieval, groundedness, hallucination rate and entitlement correctness each get their own number — an average would hide one type failing completely.
Parse, then model
Every figure above splits into a parsing cost (identical across models) and a model cost, so a cheaper model is visible as a real saving, not lost in a blended total.
Sometimes the taxonomy is wrong
When models across the set fail the same document type, that's a signal to inspect the taxonomy, source data and preprocessing before assuming the answer is simply a better model.
Evals that keep production honest
A benchmark establishes the starting configuration. Evals measure what changes after — a new document type, model update, prompt change or corpus shift.
| Dimension | How it's measured | What it protects against |
|---|---|---|
| Retrieval accuracy | Golden question set per tier; correct passage in the top results, recall@k. | An answer that reads well because the model wrote around a missing source. |
| Groundedness | Automated claim-level attribution — checks whether factual claims are supported by retrieved passages. | Fluent text that cites a real document and still says something it doesn't. |
| Hallucination rate | Adversarial and out-of-scope question sets — how often the agent answers when it should decline. | Confidence in the absence of evidence. |
| Entitlement correctness | Per-tier automated entitlement tests can run as part of the release process. Pass or fail, not a score. | The failure that ends the programme, not just degrades it. |
| Cost per query | Tracked against your target, broken into parsing, retrieval and model. | A pilot that works and a bill that doesn't scale. |
| Latency | End to end, median and 95th percentile. | An accurate agent nobody waits for. |
These run before launch and continue in production, including after model, prompt or corpus changes — not a one-time certificate. The same scorecard helps surface regressions before they reach users.
Private models, hosted by us if you want
Run the recommended model in your own tenant, or let us host it. The application stays model-flexible behind the same evaluation layer, so changing providers doesn't mean rebuilding the agent around one model API.
Caching and compaction, not just page count
Repeated context in a conversation is cached rather than re-sent; long threads are compacted before they hit the model. Both can reduce cost per query while preserving the context the task needs — their impact is measured through the same evals.
Which type of RAG does your application actually need?
The basic idea is retrieval-augmented generation: fetch relevant context before the model answers. The production work is deciding what may be retrieved, what's authoritative, how it's ranked, and when the system should refuse.
Where RAG sits in the bigger picture
The steps below are what happens inside a single retrieval. All of it sits inside a larger context layer — the same one serving customer, employee, embedded and operational agents at once.
The governed context layer sits across existing data, document and application systems; it does not require moving every source into a new system of record.
Inside a single retrieval
Chunking strategy by document class
One window size for every document is a decision too, and usually the wrong one — set once at ingest, not something you tune per query.
| Document class | Strategy | Window |
|---|---|---|
| Policies & manuals | Semantic | ~700 tok |
| Spec sheets | Layout aware | per table |
| Contracts | Clause split | per clause |
| Support tickets | Whole record | 1 per ticket |
| Call transcripts | Speaker turn | ~400 tok |
Useful when the corpus is small and low-risk
Semantic retrieval plus generation is often enough for a narrow, public FAQ.
Use this when: a small public corpus supports
straightforward Q&A.
DataGOL's role: possibly unnecessary — a simple managed stack may be
enough here.
Meaning plus exact-match retrieval
Worth it once documents have versions, part numbers, or clauses that meaning-search blurs.
Use this when: revisions, part numbers or clause
references need to outrank a merely similar passage.
DataGOL's role: merges and reranks,
configured using document metadata such as recency and authority.
Filtered before the model sees it
Entitlement filtering removes ineligible chunks before scoring and ranking. The same filter also reads persona and context metadata — department, region, plan tier — so retrieval narrows to what's relevant for this caller, not only what's allowed.
Use this when: the same corpus serves customers,
employees, partners or tenants with different access.
DataGOL's role: carries identity and
entitlement rules into retrieval itself.
Documents answer part of it, systems the rest
The agent retrieves knowledge, checks a system of record, and can propose a governed action.
Use this when: the answer requires both
knowledge retrieval and an operational system.
DataGOL's role: the data/context substrate and
the governed connection between retrieval, tools, and the action.
Follows the chain across documents
Some answers aren't in any single paragraph — "which customers are affected by this recall" means hopping from a part, to the products containing it, to the orders, to the accounts. A graph stores those connections so the agent can follow them. Worth it once questions span several documents and systems, and the connection between them is the answer.
Use this when: the answer depends on
relationships across documents, entities or systems.
DataGOL's role: uses ontology and
context relationships so the agent can traverse enterprise meaning, not just text similarity.
Once it's live, you need to see what it's doing.
Benchmarking tells you whether the proposed architecture performs on your workload before you commit to it. The control plane tells you what happens after it goes live — cost, which model ran, which skill or prompt version fired, and a full trace when something needs a closer look. The context and control layers are independent of the agent surface, so teams can use DataGOL with agents embedded in their own applications and workflows.
See the bill before it surprises you
Cost tracked per query, per agent and per model — not just at benchmark time. Caching and context compaction keep running in production, and spend that drifts from target is visible before the invoice is.
The routing keeps working after launch
The chain you benchmarked — one model to classify, another to extract, a cheap model to pre-screen — keeps running as the workload shifts. When a better or cheaper compatible model becomes available, it can often be introduced through routing and evaluation rather than rebuilding the application.
A versioned library, not a string buried in code
Agents draw from a shared library of skills and prompts instead of a prompt hardcoded per agent. Prompt and skill changes can be evaluated against the golden set before release, helping catch regressions before they reach users.
End-to-end traces for production runs
Which documents were retrieved, which were excluded by entitlement, which model ran, what was cited, and what was declined and why — the execution trace supports both debugging and audit review.
Inside the control plane
An agent's traces, cost and error rate, alongside the models, skills and guardrails it's actually running — from DataGOL Lens. Here it's caught a real problem: an error-rate spike and a skill conflict, both surfaced before they became a bigger one.
What a trace actually shows
| Step | What's recorded |
|---|---|
| Identity resolved | Caller, tier, entitlement scope |
| Retrieval | Candidates considered, chunks excluded by entitlement, final top-k |
| Rerank | Similarity vs. final rank, and why |
| Model call | Model, skill / prompt version, tokens, cost |
| Groundedness check | Pass or fail, cited passages |
| Answer or action | What shipped, or what was proposed for approval |
Same architecture. Different business surface.
Start with the problem you have, not with "we need RAG." These are the four patterns we see most often.
Q&A and knowledge assistants
"We want employees or customers to ask questions instead of searching documents."
Answer from policies, manuals or product docs, with citations and permission-aware retrieval.
One knowledge base, different views
"Public, customer, partner and employee experiences need to see different things — from the same knowledge."
Public, customer, partner and employee experiences are queried through one governed context layer; identity decides what each sees.
Classification and extraction
"We have a pile of scanned documents that needs to become structured data."
Turn scanned mail, contracts, statements and forms into typed records with confidence scoring and human review.
Support and connector agents
"We want an AI support agent that understands the product and the customer — this shows RAG is one component, not the whole solution."
Combine manuals with CRM, ticketing and operational systems so the agent can propose the next action.
Same requirement, many fronts
Whatever the vertical, the agent needs to sit on top of the same three things — documents, tables and ontologies — to give the right answer for this specific case, not a generic one.
A broken 3D printer, HVAC unit or lawn mower
Reads that model's manual, its diagnostic tree and the parts catalog, and walks the customer through the fix for their unit — not a generic troubleshooting script.
A technician standing in front of the unit
Pulls the service history, warranty status and the exact torque spec from the manual and the ticketing system together, before the panel comes off.
A client asking about their own plan
Answers from the account data, the product prospectus and the firm's compliance rules — not the marketing brochure.
A teaching assistant
Answers from the curriculum and the textbook, calibrated to where this student actually is, not the whole syllabus at once.
A coaching assistant
Combines the program's playbook with this person's own history and the situation in front of them right now.
Documents, tables, ontologies
These workloads can combine unstructured content, structured records and the business definitions connecting them, through the same governed context layer behind a very different front end.
Three engagements, in more detail
One assistant, three audiences
A public site bot, a customer-portal bot and a staff bot were the obvious plan. We built one, and let login decide what it can retrieve.
- Public visitors: product and wound-care guidance only
- Customers: also get training content
- Staff: also get the handbook and internal systems
- Runs inside their healthcare-compliant cloud
A million documents, priced first
Decades of scanned mail and contracts, heading for a million documents a year. We benchmarked nine models on their real files before writing a pipeline.
- Best-value model: 93.7% accurate at $0.0026 / doc
- Three document types cleared for production immediately
- Three more were failing for every model — a definition problem
Answers where the team already works
Their knowledge lived in a wiki nobody searched. We indexed it and put the assistant inside the chat tool the team has open all day.
- Wiki indexed and kept in sync automatically
- Answers in 1:1 and group chat, sources attached
- No new tool for anyone to log into
What should you actually decide before building RAG?
Model choice is one line item. These decisions determine whether the system gets trusted, secured and kept affordable after the demo.
Ask
What document and data types exist? Scanned, structured, versioned, tabular, conversational, multimodal?
Why it matters
Different classes need different parsing and chunking. One window for everything creates silent quality problems.
How DataGOL handles it
Per-class chunking Source-specific ingestion and document-class-specific parsing and chunking, instead of one generic pipeline.
Ask
Which source wins when two documents disagree? How fast does content change?
Why it matters
RAG retrieves what exists. It can't infer which contradictory source your business trusts unless you encode it.
How DataGOL handles it
Authority + recency Written onto each chunk at ingest, so retrieval can prefer the source your business trusts.
Ask
Who can see each source, section, customer record or tenant?
Why it matters
Entitlements have to apply before retrieval. A sentence in the prompt is not a security boundary.
How DataGOL handles it
Native entitlement gate Part of the retrieval boundary — excluded before ranking, not filtered after generation.
Ask
Do people search by meaning, exact identifiers, clauses, error codes, or relationships across records?
Why it matters
This decides semantic vs. keyword vs. hybrid search, reranking, and whether a relationship graph earns its cost.
How DataGOL handles it
Hybrid + graph Metadata filters, reranking and relationship traversal, combined depending on the workload.
Ask
What are the questions with known-correct answers? What must the agent refuse to answer?
Why it matters
Without a golden set, "accuracy" is subjective and model switching becomes guesswork.
How DataGOL handles it
Golden eval set Representative questions and expected answers, used at benchmark time and again in production.
Ask
Does the agent only answer, or can it update a CRM, open a ticket, or post a transaction?
Why it matters
Read-only RAG and operational agents need very different audit and human-approval requirements.
How DataGOL handles it
Propose / approve RAG sits inside a governed agent workflow with tool access and a trace of what happened.
Ask
What's the target cost per document, per conversation, or per completed workflow?
Why it matters
Parsing, reranking, and page volume can matter more than the headline price of the model.
How DataGOL handles it
Cost decomposition Parsing, retrieval and model cost benchmarked separately, before production scale.
Ask
Which cloud, which models, what residency, BAA, or zero-retention requirements apply?
Why it matters
Pick the deployment boundary before the application hardens around a vendor you can't easily leave.
How DataGOL handles it
Model-flexible Cloud or private deployment with model flexibility, so deployment choices don't hard-wire the application to one provider.
Bring one use case.
We'll benchmark representative data, test retrieval and permissions, identify likely failure modes and estimate production economics — then tell you plainly whether you need a simple RAG stack, DataGOL, or something in between.
Frequently asked questions
The direct answers to what buyers and technical evaluators ask most often.
What exactly is DataGOL?
DataGOL is governed context infrastructure for production AI agents. It connects documents, structured data, enterprise systems, permissions, business context, retrieval, evals and runtime controls underneath the agent or application your users interact with.
Is DataGOL a RAG platform?
RAG is one access pattern within DataGOL, not the whole platform. DataGOL is designed for applications that also need permissions, structured data, ontology, model evaluation, auditability, runtime control or agent actions.
When should we use DataGOL instead of building RAG ourselves?
A simple RAG stack may be enough for one low-risk Q&A application. DataGOL becomes more relevant when multiple agents or audiences need the same governed context, structured and unstructured data together, permission-aware retrieval, continuous evals, private deployment or operational actions.
What does DataGOL replace in our AI architecture?
DataGOL can reduce the custom infrastructure teams otherwise build around each agent for ingestion, parsing, permissions, context, retrieval, evals, model routing, tracing, cost measurement and governed actions. It does not require replacing the systems that already own your business data.
Does DataGOL replace Snowflake, Databricks, our warehouse or our lakehouse?
No. DataGOL sits across existing warehouses, lakehouses, SaaS systems, databases, documents and APIs and makes that information usable as governed context for AI applications.
Can we keep our existing AI application or agent?
Yes. DataGOL is designed to sit underneath the agent surface, so teams can keep their own product experience, application logic and workflows while using DataGOL for context, permissions, retrieval and runtime control.
Does DataGOL lock us into one model or provider?
No. DataGOL is designed to be model-flexible. Teams can benchmark models against the same workload, compare quality, latency and cost, and change compatible models without rebuilding the entire application around one provider.
Can DataGOL work with our existing agent framework?
The context and control layers are intended to sit underneath the application rather than dictate the front-end agent experience. The exact integration pattern depends on how the current agent is built and which DataGOL integration surfaces are used.
How does DataGOL handle permissions and tenant isolation?
Permissions are enforced at the retrieval boundary. Content the current user or tenant is not entitled to access is excluded before eligible context is ranked and passed to the model.
Can DataGOL combine structured and unstructured data?
Yes. A production agent can use documents together with structured records from databases and enterprise systems, so an answer can combine manuals, account state, CRM history, product data, ticket history and other relevant context.
How does DataGOL reduce hallucination risk?
DataGOL does not claim to eliminate hallucinations. It reduces and measures the risk through permission-aware retrieval, grounding checks, citations, refusal testing, golden eval sets and production traces.
How do we know whether an agent is production-ready?
DataGOL can evaluate retrieval accuracy, groundedness, refusal behavior, entitlement correctness, latency and cost. These measures can be used before launch and reused after model, prompt or corpus changes.
What does the DataGOL control plane show?
The control plane can show model and prompt versions, retrieval behavior, excluded context, citations, cost, errors and execution traces. This helps teams debug failures, evaluate changes and understand what happened after an agent runs.
Can DataGOL support agents that take actions, not just answer questions?
Yes. RAG can sit inside a broader governed agent workflow that reads context, calls operational systems and proposes or executes actions. Higher-risk workflows can include propose-and-approve controls and execution traces.
Can DataGOL run in our cloud or private environment?
DataGOL supports cloud and private deployment patterns. The exact architecture depends on requirements such as residency, networking, model hosting, privacy and regulated workloads.
How do developers integrate with DataGOL?
Applications can connect through supported APIs, connectors and integration surfaces such as MCP where appropriate. The goal is for developers to consume governed context and runtime controls without rebuilding the same infrastructure inside each application.
How does DataGOL reduce the cost of production AI?
DataGOL measures more than model tokens. Parsing, retrieval, context size, reranking, caching and model choice can all affect cost, and the larger economic benefit comes from reusing the same context, permissions, evals and runtime infrastructure across multiple agents.
What does our engineering team still own?
Your team can continue to own the product experience, business logic, workflows and application-specific behavior. DataGOL provides more of the reusable infrastructure around context, retrieval, evaluation, governance and runtime operation.
What happens in a DataGOL proof of value?
A PoV uses a real workload and representative data to test retrieval, permissions, model performance, grounding, failure modes, deployment requirements and expected production cost. The goal is to determine whether the right answer is a simple RAG stack, DataGOL, or something in between.
When is DataGOL probably overkill?
If the requirement is one small public Q&A application with a stable corpus, no sensitive permissions, no structured data and no agent actions, a simpler managed RAG stack may be the better choice.