Enterprise Multi-Agent RAG Platform
A company-wide knowledge platform built on multiple cooperating LLM agents — grounded, cited, and continuously evaluated.
Architecture and methodology are described at a high level; production code and internal data are proprietary.
Role: Technical Lead / Architect · Period: 2025.11 – Present · Stack: Python, LangChain, LangGraph, Azure OpenAI, Azure AI Search, FastAPI, React
I architected an enterprise, domain-specific multi-agent RAG platform end-to-end, taking it from a single-agent pilot to a company-wide initiative.
- Origin — grew out of the earlier data-standardization system, promoted from a single-agent plan into a multi-agent flagship.
- What it does — turns fragmented internal knowledge into a queryable, cited assistant over shared Azure infrastructure.
- Three cooperating sub-agents — a knowledge QnA assistant, a data-standardization assistant, and a code-analysis agent.
- Status — live with ~30 practitioners and expanding company-wide; two of the three agents shipped two months ahead of target.
The three agents
Knowledge QnA chatbot — a 9 sub-agent Self-RAG / CRAG loop with token streaming and source citation. Across a 151-query operational evaluation it passed all 10 operational metrics; a 50-question, 4-model LLM-as-judge evaluation scored 5.0 / 5.0 on factuality and reasoning (gpt-4.1).
Data-standardization assistant — a Rule + ALBERT classifier + RAG hybrid (LangGraph Reflexion loop) that auto-recommends three metadata fields; the productionized successor of the earlier data-standardization system. Across a 101-query evaluation it passed all 10 operational metrics.
Code-analysis agent — grounded a ~400K-line Python codebase (32 repos, 1,453 files) into 40K AST facts, a code graph (11,729 nodes / 38,783 edges), and a 42K search index. A 3-architecture benchmark — raw Claude Code vs. Claude Code + a metadata/skill harness vs. self-built orchestration, 9 variants — put the self-built, determinism-first grounded pipeline on a mini-tier model (GPT-5.4-mini) 1st (composite 0.977), validated with paired t-test / McNemar / Cohen's d / bootstrap CI over a 6-metric composite; now nearing production deployment. Full comparison in the case study below.
Platform foundation
- RAG pipeline — Parent-Child + contextual chunking, hybrid search (BM25 + vector), child→parent mapping, and reranking to suppress hallucination; a LangChain → LangGraph → Agentic 3-stage orchestration roadmap.
- Evaluation & MLOps — LLM-as-judge auto-scoring (factuality, reasoning, out-of-scope, multi-turn) + architecture A/B benchmarking + metric logging for operations, cutting estimated cloud operating cost by ~32%.
Architecture
The platform’s sub-agents share a common foundation — a hybrid (BM25 + vector) RAG index with parent-child + contextual chunking and reranking — and a common evaluation loop. The knowledge QnA assistant runs a 9 sub-agent Self-RAG / CRAG loop with token streaming and citation; the data-standardization and code-analysis agents reuse the same grounding and orchestration. An LLM-as-judge stage scores every interaction and feeds quality signals back to each agent.
flowchart TB
DOCS[Internal knowledge] --> IDX[(Hybrid RAG index<br/>BM25 + vector, parent-child)]
Q[User query] --> ORCH[Orchestration / control plane]
IDX --> ORCH
ORCH --> A1[Knowledge QnA assistant<br/>9 sub-agent Self-RAG / CRAG]
ORCH --> A2[Data-standardization assistant<br/>Rule + classifier + RAG]
ORCH --> A3[Code-analysis agent<br/>self-built orchestration]
A1 --> OUT[Grounded, cited output]
A2 --> OUT
A3 --> OUT
OUT --> EVAL[LLM-as-judge evaluation]
EVAL -. quality feedback .-> ORCH
Orchestration follows a deliberate LangChain → LangGraph → Agentic roadmap, so the control plane grows in capability without locking into a single framework.
Per-agent architecture
The three agents share the RAG foundation but run different orchestration strategies: the QnA assistant is corrective + Self-RAG, the standardization assistant pins a deterministic rule engine ahead of RAG to minimize autonomous judgment, and the code-analysis agent stacks Graph RAG under Agentic RAG.
Knowledge QnA — corrective + Self-RAG
flowchart LR
Q[User query] --> R[Hybrid retrieval<br/>BM25 + vector]
R --> G{Relevance grade}
G -- fail --> RW[Rewrite /<br/>re-retrieve]
RW --> R
G -- pass --> A[Generate + cite]
A --> SC{Self-check}
SC -- revise --> A
SC -- ok --> OUT[Streamed, cited answer]
Data standardization — Rule + ALBERT + RAG hybrid
flowchart LR
M[Metadata field] --> RULE[Rule engine<br/>300+ rules, abbrev dict]
M --> CLF[ALBERT domain classifier]
M --> RAG[RAG recommender]
RULE --> MRG[Merge + confidence]
CLF --> MRG
RAG --> MRG
MRG --> AUD{Domain auditor<br/>LangGraph corrective}
AUD -- revise --> RAG
AUD -- ok --> OUT[3 metadata recommendations]
Code analysis — 2-layer RAG, Graph then Agentic
flowchart LR
CB[~400K-line codebase] --> IDX[40K AST facts<br/>code graph, 11.7K nodes]
IDX --> L1[Layer 1: Graph RAG<br/>code relations]
L1 --> L2[Layer 2: Agentic RAG<br/>autonomous exploration]
L2 --> OUT[Grounded answer<br/>with provenance]
Case study — self-built orchestration vs. Claude Code
Problem. A general-purpose CLI agent (Claude Code) could already answer internal questions, but its cost-per-query profile did not scale to company-wide adoption, and “it feels better” is not an argument a platform decision can rest on.
What changed. I benchmarked three architectures head-to-head — raw Claude Code, Claude Code wrapped in a metadata/skill harness, and a dedicated self-built orchestration around the RAG pipeline that keeps the control plane in-house — across 9 variants (including the latest Claude Sonnet 5) on a 51-question eval set with a 6-metric composite, treating the comparison as a designed experiment rather than a demo.
| Rank | Architecture | Model (channel) | Composite | Latency (s) | Cost ($) |
|---|---|---|---|---|---|
| 1 | Self-built orchestration | GPT-5.4-mini (API) | 0.977 | 11.6 | 0.076 |
| 2 | Claude Code + meta/skills | Sonnet 4.6 (sub) | 0.875 | 161.6 | 0.66 |
| 3 | Claude Code (raw) | Opus 4.8 (sub) | 0.840 | 110.7 | 0.76 |
| 4 | Claude Code + meta/skills | Haiku 4.5 (sub) | 0.836 | 64.2 | 0.19 |
| 5 | Claude Code (raw) | Sonnet 4.6 (sub) | 0.828 | 95.8 | 0.44 |
| 6 | Claude Code + meta/skills | Opus 4.8 (sub) | 0.823 | 169.2 | 1.32 |
| 7 | Claude Code (raw) | Sonnet 5 (sub) | 0.815 | 108.8 | 0.50 |
| 8 | Claude Code (raw) | Sonnet 5 (int) | 0.800 | — | — |
| 9 | Claude Code (raw) | Haiku 4.5 (sub) | 0.758 | 51.8 | 0.136 |
Composite = weighted sum of accuracy, no-hallucination, completeness, structure-traceability, relevance, and citation. Latency and cost are per query; the response-collection channel is in parentheses — sub = subscription CLI, API = direct API, int = interactive (efficiency not measured). The self-built orchestration answers in a single grounded API call, so it is both the cheapest and the fastest while topping the composite.
Result. The self-built, determinism-first orchestration won overall — a grounded mini-tier model leading frontier CLI agents on answer quality at up to ~17× lower cost per query, with the gap established by paired t-test · McNemar · Cohen’s d · bootstrap CI rather than impression — the evidence that justified moving from a single-agent pilot to a company-wide rollout. The winning pipeline is now nearing production deployment.
Why it matters
A self-built harness keeps the control plane in-house — three payoffs:
- Vendor flexibility — models are borrowed, but the control code is ours, so we are not locked to one provider’s stack.
- Cost control — determinism-first grounding runs on a cheap mini-tier model.
- Knowledge as a durable asset — captured in-house rather than rented from a single provider.
I made this case beyond my own team, too: across two Microsoft workshops I led the technical discussion and persuaded a Microsoft architect and seven engineers of the self-built orchestration approach over a general-purpose Copilot CLI.