Direct answer
Retrieval quality decides answer quality, so it is engineered and evaluated separately from generation. The enterprise-specific parts are permission filtering at query time, keeping sources citable so a claim can be traced, and freshness — because a stopped sync produces confident answers from stale data.
Retrieval-augmented generation (RAG)
An architecture in which a model answers using content fetched from an external source at query time, rather than only from what it was trained on. The retrieval step selects and filters that content before the model sees it.
Permission filtering is the enterprise difference
An index built across several permission domains will return a passage the requester cannot see, because similarity does not know about access. Filter at query time using the requester's permissions, or partition the index per domain. Filtering after retrieval is too late — the restricted content has already entered the context.
What to get right before tuning the model
Most disappointing results are retrieval problems presented as model problems.
Chunking
Split on document structure rather than a fixed length, so a retrieved passage is self-contained.
Hybrid search
Combine keyword and vector search; identifiers and product codes fail on similarity alone.
Citations
Return the source with the passage, so an answer can be traced rather than trusted.
Freshness
Track when each source was last synced and surface it, because staleness is silent.
Retrieval evals
Measure whether the right passage was fetched, separately from whether the answer read well.
Where RAG is the wrong tool
Retrieval answers questions from documents. It does not compute, reconcile or enforce a rule. Where the real question is what a system's current state is, a query against that system is the right answer, and dressing it as retrieval adds a layer that can be wrong.
The Propose–Decide–Execute pattern
CodeDTX builds agentic systems on the Propose–Decide–Execute pattern: agents may only write proposals with evidence attached, a named human records an approval or rejection with a reason, and a separate execution layer carries out approved work and logs the artifact. No agent holds a write tool to the outside world.
- 01
Propose
The agent analyses live system state and drafts a change, with the evidence it relied on attached to the proposal.
- 02
Decide
A named human approves, edits, or rejects with a reason. Risk tier determines who is allowed to decide.
- 03
Execute
A separate execution layer performs approved work — merge, publish, call, write — and records the resulting artifact.
- 04
Audit
Actor, reason, evidence, artifact, tokens, and cost are retained for every run, so any decision can be reconstructed later.
The six layers we build and review against
- 1
Agent layer
Agent architecture, tool use, memory and context, multi-agent patterns, structured outputs, orchestration.
- 2
Integration layer
MCP servers, tool contracts, API and database adapters, authentication, permissions, legacy system access.
- 3
Knowledge layer
Retrieval and RAG, vector and search architecture, enterprise knowledge sources, data access controls.
- 4
Reliability layer
Evals, tracing, observability, cost and latency budgets, fallbacks, regression tests.
- 5
Safety layer
Guardrails, prompt-injection defense, PII and data boundaries, human-in-the-loop gates, audit trails.
- 6
Product layer
The application people actually use: interfaces, approval queues, and operational runbooks.
Frequently asked
Is RAG better than fine-tuning?
They solve different problems. Retrieval brings in facts that change and keeps them citable; fine-tuning shapes behaviour and format. Enterprise questions about current state are usually retrieval problems, because the facts move faster than any training cycle.
Why does retrieval work in a demo and fail on our documents?
Usually chunking and identifiers. Real documents have structure, tables and codes that fixed-length splitting destroys, and pure vector search misses exact identifiers. Both are fixable in the retrieval layer without touching the model.
How do we evaluate retrieval on its own?
Assemble a set of real questions with the passage that should be returned, then measure whether it is retrieved and ranked. That isolates retrieval from generation, so an improvement can be attributed to the change that caused it.
Have a workflow that should become AI-enabled?
Tell us about the system it lives in. We reply from an engineering seat, not a sales deck.