How we build

Production AI Reference Architectures: Private RAG, Multi-Agent & Edge Systems

Blueprints for three problems we are built to solve: the components we use, how data moves through the system, and the metrics and target values we track from day one.

FinTech, Banking & Legal

Private Compliance Knowledge Engine (RAG)

The problem

Compliance, risk and legal teams lose hours searching regulations, internal policies and case files — and that data cannot be sent to public AI services.

Good fit when

  • Data residency or confidentiality is a hard requirement
  • Knowledge is spread across thousands to millions of documents
  • Every answer must be traceable to its source

Architecture

  • Open-weight LLM (Llama, Mistral or Qwen family), quantized and served on the client's own GPU servers or private cloud tenant
  • Ingestion pipeline for parsing, chunking and metadata tagging, including document-level access rights
  • Hybrid retrieval — vector and keyword search — followed by a re-ranking step
  • Permission-aware results: users only retrieve documents they are entitled to see (RBAC)
  • Source citations on every answer and a complete audit log

How a question is answered

  1. A user asks a question in natural language
  2. Retrieval finds candidate passages the user is allowed to see
  3. A re-ranker keeps only the most relevant evidence
  4. The model answers from that evidence alone, with citations

What we measure — and target

  • Retrieval precision@5 agreed per corpus
  • Citation coverage 100% enforced
  • Time-to-first-token < 400 ms
  • Reviewer time per case vs. baseline
Supply Chain & Logistics

Multi-Agent Exception Handling

The problem

Shipment delays, customs holds and carrier issues arrive as emails, portal updates and system alerts. Dispatchers triage each one by hand, so response times depend on who is on shift.

Good fit when

  • Exceptions are frequent and largely repetitive
  • Clear business rules define what can be fixed automatically
  • Core systems (ERP, TMS, carrier portals) expose APIs

Architecture

  • Event intake from ERP/TMS, shared inboxes and carrier or customs APIs
  • A triage agent that classifies each exception and gathers shipment context
  • Specialist agents for re-routing, customs documents and customer updates, calling tools through secure APIs or the Model Context Protocol (MCP)
  • Policy guardrails: any action above an agreed cost or risk threshold is sent to a person for approval
  • A complete action log for audit, with reversible steps wherever the source system allows

How an exception is handled

  1. An exception is detected or received
  2. The triage agent classifies it and collects the shipment data
  3. A specialist agent proposes a resolution
  4. Within policy it acts and updates the customer; otherwise a dispatcher approves

What we measure — and target

  • Share resolved without manual touch set in discovery
  • Time to resolution vs. baseline
  • Over-threshold actions reviewed 100% enforced
  • Cost per exception vs. baseline
B2B SaaS

Edge-Native Platform, Ready for AI Search

The problem

A centrally hosted application is slow for users far from its origin server, and its content is hard for search engines and AI assistants to read and cite.

Good fit when

  • Users are spread across several regions
  • Organic and AI-assistant discovery drive new business
  • Compute-heavy features could run closer to the user

Architecture

  • Rendering and caching on an edge runtime such as Cloudflare Workers, close to each user
  • Compute-heavy parsing and processing compiled to WebAssembly
  • Server-rendered, semantic HTML that crawlers can read without running JavaScript
  • A connected JSON-LD entity graph for the organisation, products, documentation and FAQs
  • Real-user monitoring of Core Web Vitals

How a request is served

  1. The request reaches the nearest edge node
  2. Cached or edge-rendered HTML is returned
  3. The origin is called only for data that must be fresh
  4. Crawlers and AI assistants receive the same structured HTML as users

What we measure — and target

  • P95 latency by region < 50 ms
  • Core Web Vitals LCP < 2.5 s · INP < 200 ms · CLS < 0.1
  • Indexed and cited pages tracked monthly
  • Referrals from AI assistants tracked monthly

Comparison

Public cloud AI wrappers vs. Naringhi sovereign AI architecture

Many AI products are thin wrappers around a public model API. That is often fine for experiments — this is where the two approaches differ once real company data is involved.

Comparison of a typical public cloud AI wrapper and Naringhi's sovereign AI architecture
CriterionTypical public cloud AI wrapperNaringhi sovereign AI architecture
Data egress Prompts and documents are sent to a third-party model provider Zero external egress: models run on-premise, air-gapped or in your private VPC
Latency Every request travels to the provider’s region and depends on its load Inference runs next to your data; pages and APIs are served from the edge (target P95 < 50 ms)
Compliance Bound by the provider’s terms, retention policy and data-residency options You choose where data lives; every query and answer is written to an audit log
Hallucination control Generic answers from training data unless you build retrieval yourself Answers grounded in your documents with enforced citations; questions without evidence are declined or escalated
Cost at scale Pay per token — cost grows in step with usage Mostly fixed infrastructure cost — cost per query falls as usage grows
Ownership Prompts, workflows and integrations tied to one vendor’s API You own the code, configuration and any fine-tuned weights; models can be swapped

A general comparison of the two architectural patterns. Actual latency and cost depend on model size, hardware and traffic, and are estimated for each client during discovery.

Engagement model

From blueprint to production

Each architecture is adapted to your data, systems and constraints through the same four phases. Enterprise on-premise LLM rollouts usually take 4–6 months end to end.

  1. Discovery & architecture

    2–3 weeks

    Workflow mapping and a data audit, ending in a fixed-price architecture proposal with agreed success metrics.

  2. Build & integrate

    First release typically in 8–12 weeks

    Iterative delivery, integrated with the systems your teams already use.

  3. Evaluate & harden

    Before go-live

    Evaluation against the agreed metrics, a security review and guardrail tuning.

  4. Hand-over & support

    After launch

    Documentation and knowledge transfer so your team can run the system; ongoing support can be agreed separately.

Facing a similar problem?

Book a free 30-minute architecture consultation and we will map the right approach to your data, systems and constraints.

Get a Free Consultation