Qatar Post AI

Solution Docs · powered by Eloquent

Qatar Post AI — Solution Architecture

How the four Qatar Post solutions are built on the Eloquent platform

Version 1.1 — July 2026 · Prepared by Eloquent for Qatar Post


1. Executive Summary

The four Qatar Post solutions documented in this folder — the Website Assistant, the Branch Assistant, the Internal AI Assistant, and Customs Clearance AI — are not four separate bespoke builds. They are four use cases configured on a single Eloquent platform deployment, sharing one multi-tenant backend, one agents engine, one chat service, one knowledge layer, and one analytics stack.

Each solution is delivered as:

  1. One or more Eloquent Agents — declarative configurations (goal, system prompt, skills, tools, model) created in the no-code Agent Builder, no platform code changes required.
  2. A custom front-end surface — a branded UI (public widget, kiosk avatar, internal portal) built with the @elqnt/* packages, talking to Eloquent over HTTPS/SSE through the API Gateway.
  3. A set of integrations — Qatar Post's own APIs (Track & Trace, Pricing, OTP, Customs Declaration, Office 365) wired in as agent skills/tools or workflow steps.

The platform does the heavy lifting. Streaming chat, tool orchestration, retrieval-augmented answers, document citations, multi-tenancy, analytics, background jobs, and workflow execution are all provided by Eloquent. Qatar Post's investment is in configuration (agents + skills) and presentation (the front-end shells) — not in rebuilding AI infrastructure.

This document maps each solution onto the Eloquent platform architecture. It is grounded in the Eloquent administration guide:


2. The Eloquent Platform (the shared backend)

Eloquent is an enterprise AI platform with a microservices architecture: front-end applications, a single API Gateway, backend services, and shared data stores. Everything Qatar Post builds sits on top of this — Qatar Post is one tenant (organization) on the deployment.

Key platform guarantees (from the System Architecture guide):

PropertyWhat it means for Qatar Post
Single entry pointAll four front-ends talk only to the API Gateway over HTTPS. Browsers/kiosks never touch backend services or databases directly.
JWT-scoped multi-tenancyEvery request carries Qatar Post's orgId in a signed JWT. The gateway enforces tenant context; no cross-org data access is possible at any layer.
SSE chat transportStreaming AI responses use stateless Server-Sent Events — works behind standard load balancers, auto-reconnects, no sticky sessions.
Managed service-to-service messagingBackend services coordinate over an internal message queue. Front-ends and integrations never see NATS/queues — that's fully managed.
Self-hosted / data residencyThe platform runs on Kubernetes (AKS/EKS/GKE/OKE or on-prem) via Helm, so the Qatar Post deployment can be pinned to a region or installed on-premise.

3. One Tenant, Many Agents

Qatar Post is a single Eloquent organization. Within that tenant, the four solutions are realized as agents and (for customs) a workflow — all sharing the same knowledge libraries, OTP service, analytics, and isolated data stores.

Notice the reuse: the Website Assistant and Branch Assistant share the same six service-flow tools, the same OTP service, the same public knowledge library. The Branch Assistant is a separate agent only so its prompts can be tuned for the in-branch, voice-first context — it inherits the rest.


4. The Eloquent Agent Anatomy (every surface follows this)

Each solution is an instance of the same agent model. From the Building Agents guide, an agent is a declarative configuration:

Tools execute in one of three modes — this distinction is what makes the Qatar Post service flows work:

ModeRuns whereUsed by Qatar Post for
sync (server tool)Backend, via internal messagingknowledge_search, entity queries, customs API calls
async (server tool)Backend, fire-and-forgetNotifications, long jobs
asyncClient / client-functionThe front-endOpening the side-car wizards (Track, Send, Hold/Forward, PO Box, Pricing, Locator). The agent "calls a tool" → the widget intercepts it → opens a pre-filled form. This is the agent→UI bridge.

The client-function pattern is documented in the Custom Agent UIs guide ("Client-Side Tool Execution") and is the backbone of the public and branch self-service flows.


5. Solution-by-Solution Mapping

5.1 At a glance

SolutionEloquent building blockCustom front-endPrimary integrations
Website Assistant1 public agent + 7 skills, client-function tools, OTP, public KB libraryEmbeddable widget (<script>) built on @elqnt/chatTrack & Trace, Pricing, Forward/Hold, PO Box, OTP, Azure Speech
Branch Assistant1 kiosk agent (reuses website skills) + 3 branch skills, avatar-state hintsFull-screen Rive-animated kiosk UI on @elqnt/chatSame QP APIs + Azure Speech + branch peripherals (printer, QID, locker)
Internal AI AssistantMultiple specialist agents, Agent Builder, Knowledge Management + Libraries, Service Desk, Analytics, ProjectsEmployee chat portal + Admin Console (Eloquent App)Jira / ServiceNow / webhook ITSM, Office viewers, Web Speech
Customs Clearance AIWorkflow engine + document ingestion + entities + KG (HS-code lookup)Job dashboard + human-review UIOffice 365 inbound email, Azure Form Recognizer, Customs Declaration API

5.2 Capability → surface matrix

Which Eloquent capabilities each surface leverages:

Eloquent capabilityWebsiteBranchInternalCustoms
Agents engine (chat)
SSE streaming chat
Client-function tools (side-cars)
Knowledge Base / Libraries✅ (HS codes)
Document citations
OTP / light KYC✅ (consent)
Workflow engine
Document ingestion / Form Recognizer
Entities (dynamic CRUD)✅ (tickets, tasks)✅ (manifests, declarations)
Service Desk / ITSM
Analytics + CSAT✅ (job metrics)
Background jobs / scheduler
Voice (Azure Speech / Web Speech)

5.3 Conversational surfaces — shared request flow

The Website, Branch, and Internal assistants all follow the same runtime flow. The only differences are the front-end shell and the agent configuration:

5.4 Conversational vs. workflow surfaces

Three of the four solutions (Website, Branch, Internal) are conversational agents that share the runtime flow above. Customs Clearance is the exception — it is a workflow, not a chat: an email-triggered pipeline with a human-review gate, built on the workflow engine + document ingestion + entities rather than the chat service. Its end-to-end flow and review UI live in the Customs Clearance AI doc.


6. Front-End Strategy — Widget vs. Custom UI

Eloquent offers two ways to surface an agent. Qatar Post uses both, picking per surface:

ApproachWhenQatar Post surfaces
Embeddable widget (no-code, configured in Admin → Embed)Quick chat bubble, default styling acceptableCould back a simple internal embed
Custom UI (@elqnt/chat, @elqnt/agents, @elqnt/kg, @elqnt/api-client)Full branding, RTL/bilingual, voice, side panels, kiosk, portal embeddingWebsite Assistant, Branch Assistant, Internal Assistant

The Qatar Post front-ends are textbook custom UIs as described in the Custom Agent UIs guide: bilingual Arabic/English with RTL, voice I/O via Azure Speech, document-citation side panels, client-side tool execution, and postMessage portal embedding. The guide's own "government organization" reference example (bilingual + RTL + KG client-tools + citation viewer + voice + telemetry + portal embedding) is the same architecture these solutions use.

Why this matters: Qatar Post owns the look, language, and journey; Eloquent owns the protocol, auth, streaming, and state. New surfaces (mobile app via createFetchSSETransport, WhatsApp via createWhatsAppTransport) are additional transports against the same agents — no backend rework.


7. Configure-Don't-Code: What Lives Where

A clear delineation of responsibilities, which is the central message of this architecture:

LayerProvided by Eloquent (platform)Configured / built for Qatar Post
InfrastructureKubernetes, Helm, PostgreSQL, ClickHouse, Redis, message queue, API GatewayRegion / on-prem placement, domains, secrets
AI runtimeAgents engine, chat service, SSE, tool orchestration, model providersAgent goals, system prompts, model selection
KnowledgeIngestion pipeline, embeddings, semantic search, KG, citationsWhich documents/libraries (HR, IT, Finance, public KB, HS-code list)
CapabilitiesSkill/tool framework, workflow engine, entities, scheduler, Service DeskWhich skills per agent, the customs workflow, QP API tool definitions
Front-end@elqnt/* SDK packages, embeddable widgetThe branded widget, kiosk avatar, internal portal, review UI
IntegrationsConnector framework (email, ITSM, webhooks, HTTP API tools)Qatar Post API endpoints, Office 365 mailbox, OTP/SMS provider
OperationsAnalytics, chat logs, audit trail, CSAT, multi-tenant isolationDashboards Qatar Post staff read; review workflows

Everything in the right-hand column is configuration and presentation — done through the Admin Console and a front-end app — not modifications to the platform. That is what makes these four solutions fast to deliver, consistent to operate, and cheap to extend.


8. Azure Production Deployment (Landing-Zone Topology)

Section 2 describes the platform in provider-neutral terms. In production for Qatar Post it is deployed on Microsoft Azure using an enterprise landing-zone topology: a shared Hub / Connectivity landing zone centralises network and security services, VNET-peered to a dedicated QPOST AI Landing Zone (Production) that hosts the AKS cluster running the Eloquent services and the Azure AI services the four solutions depend on.

QPOST AI Azure landing-zone architecture — Hub/Connectivity landing zone VNET-peered to the QPOST AI Landing Zone (Production)

Hub / Connectivity landing zone — shared services fronting the workload: Azure Firewall / NVA, Bastion, DDoS Protection, Private DNS, API Management, and centralised Log Analytics.

QPOST AI Landing Zone (Production) — the workload zone, grouped by function:

GroupAzure services
ProcessingAzure OpenAI · AI Speech · AKS cluster · Document Intelligence · Translator
StorageCosmos DB (Gremlin + Mongo) · data store
NetworkNetwork Security Group · VNET · Private DNS · Route Table
MonitoringApplication Insights
PlatformManagement / build VMs · Container Registry · Key Vault · Communication Services

8.1 Resource inventory

The concrete production resources and how each maps back to the platform capabilities described above. All diagnostics flow to the shared Log Analytics workspaces (la-qpost-hub-qc-001, with security-relevant resources also to la-security-hub-qc-001).

Azure resourceResource namePlatform roleLog Analytics
Azure Kubernetes Serviceaks-qpostai-prd-sc-01Runs all Eloquent backend services, the API Gateway, and the Qatar Post front-end surfacesla-security-hub-qc-001 · la-qpost-hub-qc-001
Open AIoai-qpostai-prd-sc-01GPT models for chat completions and data extractionla-qpost-hub-qc-001
Speech Servicespch-qpostai-prd-sc-01Voice input/output (Website & Branch assistants)la-qpost-hub-qc-001
Document Intelligencedi-qpostai-prd-sc-01Form Recognizer — customs manifest & declaration extractionla-qpost-hub-qc-001
Cosmos DB (Gremlin)cosmos-gremlin-qpostai-prd-sc-01Knowledge graph storela-qpost-hub-qc-001
Cosmos DB (Mongo)cosmos-mongo-qpostai-prd-sc-01Document / entity storela-qpost-hub-qc-001
Key Vaultkv-qpostai-prd-sc-01Secrets, keys, and connection stringsla-security-hub-qc-001 · la-qpost-hub-qc-001
Event Grid system topicstqpostaiprdsc01-4edd3b08-84fd-4ae4-ae50-eff92696a497Storage event notificationsla-qpost-hub-qc-001
Container Registrycrqpostaiprdsc01Eloquent + Qatar Post container imagesla-qpost-hub-qc-001

Everything in this zone corresponds directly to the abstract components in Section 2: AKS hosts the backend services and gateway; Azure OpenAI, Speech, Document Intelligence, and Translator are the model and document providers; the Cosmos DB instances back the knowledge graph and entity stores; Key Vault holds the secrets; the Container Registry serves the images; and Log Analytics provides the observability layer behind the analytics stack.


9. Cross-Cutting Concerns

  • Security & isolation — single tenant; per-org PostgreSQL schema + ClickHouse database + Redis key space + queue storage; JWT-enforced org context; API Gateway is the only public surface. (See Multi-Tenancy.)
  • Light KYC — OTP service (4-min expiry, 3 resends, single-use token, masked mobile) gates any customer-record mutation across Website and Branch.
  • Observability — one analytics stack across all surfaces: chats, messages, active users, token cost per model, tool-usage frequency, conversion funnels, CSAT word-clouds, and per-branch breakdowns.
  • Extensibility — a new service flow = one new skill + one client-function tool + one side-car component. A new internal assistant = one new agent in the Agent Builder. A new customs rule = a workflow edit. None require platform changes.
  • Portability — agents are exported/imported as JSON; agents are resolved by name (not ID) so the same front-end config promotes cleanly across dev/staging/production.

10. Related Documents