A funded hybrid AI programme still fails if MonGo ships a strong model inside a weak system. Architecture and operating design must cover channels, authentication, banking APIs, knowledge, retrieval, models, guardrails, evaluation, escalation, monitoring, governance, cost and ownership.

This article is Part IV of the Banking Customer-Service AI playbook. It follows Part I, Part II and Part III.

---

1. Purpose of this phase

Central question:

How should MonGo organise, design, build, secure and operate the AI service so that it remains useful, controllable and scalable?

A well-performing model inside a poorly designed system is still a poor enterprise solution.

---

2. Target solution scope

Product A — Agent knowledge assistant​

Intent identification; approved policy/product retrieval; source-grounded suggestions with citations; summarisation; structured CRM notes; escalation recommendations. The employee reviews and sends the final response.

Product B — Authenticated customer assistant​

Routine account/product questions; payment and card status; fees and limits; guided approved processes; human transfer. Cannot make final complaint or lending decisions, determine fraud liability, close accounts, give personalised investment advice or make irreversible high-impact changes.

---

3. Target Operating Model

Current state problems​

Customer Service owns contact-centre performance; Technology owns applications; teams maintain local knowledge; QA is sample-based; AI experiments are siloed. Unclear: who approves prompts, owns wrong answers, decides release fitness, updates knowledge, investigates AI incidents, owns AI cost or can stop the service.

Future principles​

1. Business-owned, technology-enabled
2. Product rather than project
3. Central standards, federated delivery
4. Risk-based governance
5. Human accountability
6. Reusable foundations
7. Evidence before scale

Components​

People: sponsor, CS product owner, AI PM, architects, AI/software/data engineers, knowledge managers, designers, security/privacy/RAI specialists, model validators, SREs, FinOps, change leads, agents.

Processes: use-case approval, knowledge publication, architecture review, model selection, prompt release, evaluation, security testing, production approval, monitoring, incidents, benefits, vendor review, retirement.

Technology: model gateway, retrieval, prompt registry, evaluation, observability, API management, IAM, knowledge repository, data platform, service management.

Data domains: product/policy knowledge, customer profile, transaction status, interaction history, complaints, vulnerability guidance, evaluation datasets, telemetry.

Governance: AI steering, design authority, model risk, security, privacy, RAI, production readiness, benefits review.

---

4. AI Operating Model — hub and spoke

Hub owns	Spoke (Customer Service) owns	Controls provide
Platforms, model access, retrieval, evaluation standards, registries, security patterns, governance standards, observability, specialist engineering, vendors	Outcomes, journeys, backlog, requirements, knowledge priorities, adoption, benefits, CS performance	Policy, independent review, challenge, approval, assurance, incident oversight

Activity	Primary owner	Support
Define customer outcome	Customer Service	Product, Strategy
Approve knowledge	Knowledge Owner	Compliance, Legal
Build retrieval	AI Engineering	Data Engineering
Approve model	AI Design Authority	Model Risk, Security
Approve production	Service Owner	Risk, Operations
Monitor answer quality	AI Product Owner	Evaluation
Handle customer incident	Service Operations	Risk, Engineering
Track benefits	Benefit Owner	Finance, Product
Manage supplier	Procurement	Technology, Risk
Retire capability	Service Owner	Architecture, Risk

---

5. Build–Buy–Partner

Build/control: banking workflows, escalation, customer-protection rules, evaluation datasets, retrieval config, knowledge taxonomy, integrations, product metrics, risk-control mappings, CX.

Buy: foundation models, cloud, managed vector DB, observability, API management, identity, contact-centre tech, general security.

Partner: implementation acceleration, independent assurance, red teaming, accessibility, specialist cloud architecture, model validation, regulatory interpretation.

Foundation-model decision: multiple managed models via a controlled gateway—not a proprietary LLM. Faster capability, reduced dependency, central policy/logging/routing.

---

6. TOGAF (adapted)

Principles: harm prevention over automation; sensitive actions need authorisation; production interactions traceable; models replaceable; approved knowledge identifiable; human fallback; consistent security across models.

Architecture Vision: reusable secure AI platform supporting customer and employee experiences through approved knowledge, controlled banking access and measurable human oversight.

Business Architecture capabilities: intent management, knowledge management, human escalation, case management, AI QA, AI incident management.

Data Architecture classes: (1) public/product knowledge, (2) internal policy/procedure, (3) customer/transaction, (4) AI operational/evaluation—each with different access and retention.

Applications: mobile/online banking, agent desktop, CRM, contact centre, knowledge repo, AI orchestration, model gateway, evaluation, monitoring, case management.

Technology: containerised AI services, managed model endpoints, private networking, centralised identity, encrypted storage, multi-region DR, centralised telemetry.

Work packages: knowledge governance, model gateway, retrieval, agent-assist, customer assistant, evaluation, human handoff, observability, AI security.

Migration: TA1 agent-assist (no autonomous actions) → TA2 authenticated information access → TA3 controlled reversible actions → target reusable multi-domain AI platform.

---

7. ArchiMate

Motivation: rising demand, faster-service expectations, cost, regulatory scrutiny → goals of safe resolution, lower AHT, consistency, human support → requirements for approved knowledge, traceability, escalation, secure access, continuous evaluation.

Business: actors (customer, agent, knowledge manager, service owner, fraud specialist); services (payment/card support, knowledge assist, escalation); processes (authenticate → intent → retrieve → resolve → escalate → record).

Application / Technology: digital banking, agent desktop, orchestration, retrieval, model gateway, CRM, knowledge, monitoring; cloud compute, private network, identity, secure storage, API gateway, containers, logging.

Makes explicit that payment-status success depends on authentication, payment APIs, knowledge, orchestration, monitoring and escalation—not the model alone.

---

8. C4 Model

System Context​

Users: customer, agent, knowledge manager, operations analyst, risk reviewer, support engineer. Externals: core banking, payments, CRM, identity, contact centre, model providers, monitoring. Central: MonGo AI Customer-Service Platform.

Containers​

Channel adapter · Conversation orchestration · Retrieval · Model gateway · Guardrails · Tool service · Evaluation · Observability.

Components (orchestration)​

Intent classifier · Policy router · Context manager · Retrieval coordinator · Prompt builder · Tool permission checker · Response validator · Confidence evaluator · Escalation manager · Audit logger.

---

9. Domain-Driven Design

Domains: Customer Identity, Payments, Cards, Customer Service, Complaints, Fraud, Knowledge Management, AI Interaction, AI Governance, Service Operations.

Bounded contexts: AI Interaction (state, prompts, retrieval, responses, escalation); Knowledge (approved content, ownership, versioning, metadata, publication); Payment (status, history, interpretation, exceptions); Customer Service (cases, history, routing, assignment, outcome); Governance (inventory, risk class, evaluation approvals, evidence, release).

Anti-corruption layer: map legacy codes (P01, PDG, A7, R99) to Pending / Completed / Declined / Reversed. The LM never interprets raw legacy codes.

---

10. Event Storming — lost card

Events: Card Reported Missing → Customer Authenticated → Card Selected → Temporary Freeze Requested → Card Frozen → Replacement Requested → Suspicious Transaction Detected → Fraud Case Created → Customer Notified.

Policies: suspicious transactions → fraud case; “temporarily misplaced” → offer temporary freeze; low identity confidence → human; tool failure → do not claim success.

Distinguishes what AI may propose, what deterministic services execute, what humans approve and what must be recorded.

---

11. API-First Architecture

Principles: explicit schemas, strong auth, least privilege, versioning, idempotency, rate limits, error contracts, audit IDs, data minimisation, timeouts.

Payment-status API returns normalised status, timestamp, merchant display name, permitted explanation, next actions, escalation flag—not fraud scores, unnecessary PII, raw backend errors or other-account data.

Unavailable status → STATUS_UNAVAILABLE, last update timestamp, approved fallback message, escalation route. The LM must not guess.

---

12. Event-Driven Architecture

Customer Service Interaction Completed → CRM notes, benefits analytics, evaluation, notifications, ops monitoring, risk analytics.

AI Safety Threshold Breached → incident platform, AI ops, risk, product owner, model gateway. Possible auto-response: reduce traffic, disable intent, route to humans, fallback model, open major incident.

---

13. Cloud Adoption Framework

Strategy (faster experimentation, scalable inference, reusable services, observability, controlled access) → Plan (capability, skills, migration, security, cost, operating model) → Ready (landing zones, segmentation, identity, encryption, logging, policy, tagging) → Adopt (retrieval, gateway, orchestration, evaluation, observability) → Govern (regions, services, residency, budgets, tags, security, deploy controls) → Manage (availability, capacity, FinOps, incidents, backup, DR).

---

14. Well-Architected pillars

Pillar	Worked control
Operational excellence	Prompt/model/retrieval/tool changes need change record, evaluation run, approver, rollback version
Security	Temporary scoped tokens—not permanent credentials
Reliability	Preferred model down → approved fallback → deterministic guidance → human
Performance	Small classifier; embeddings for retrieval; large model only when needed; templates for simple status
Cost	Per use case: budget, max tokens, model tier, cost-per-resolution target
Sustainability	Proportionate model size; card-status via small model or deterministic response

---

15. Zero Trust

Every access authenticated, authorised, context-aware, minimised and monitored.

Payment request must carry verified service identity, customer session, purpose, scope, correlation ID and expiry. Payment service verifies ownership, status-only authorisation, approved environment and normal access patterns.

Payment assistant may read status and permitted merchant info. May not move money, change instructions, access other accounts, read fraud scores or override payment controls.

---

16–19. Data Mesh, Fabric, Lakehouse, Medallion

Data products (Payments, Cards, Customer Service) each need owner, docs, schema, quality SLOs, access policy, lineage, change notice, support—plus central standards for identifiers, security, privacy, metadata, retention and quality.

Data Fabric catalogues metadata, lineage, integration, policy, quality, MDM, access and discovery; records source, owner, version, approval, effective date, retrieval time, classification and lineage for each retrieved article.

Lakehouse holds conversation, evaluation, ops, feedback and model-performance data—not live transactional banking.

Medallion: Bronze (raw transcripts, traces, retrieval, feedback, events) → Silver (masked, normalised intents, outcomes, linked sources, validated tools) → Gold (safe resolution, cost/resolution, groundedness, escalation quality, CSAT, benefits, risk indicators).

---

20. Platform Engineering

Without a platform, every team reinvents model access, logging, retrieval, security, evaluation, deploy and cost control.

Capabilities: model gateway · retrieval platform · evaluation platform · observability · developer portal (templates, patterns, pipelines, ownership).

Golden path: register use case → approved template → authorised knowledge → approved models → evaluation criteria → automated controls → approved pipelines → register ownership and support.

---

21. MLOps

Used for intent classification, escalation prediction, vulnerability detection, demand forecasting, routing.

Lifecycle: collect → features → train → evaluate → approve → deploy → monitor → retrain → retire.

Intent classifier monitoring: distribution, low-confidence rate, routing errors, drift, escalation outcomes; metrics include accuracy, precision, recall, high-risk confusion, channel and language-level performance.

---

22. LLMOps

Artefacts: prompts, models, retrieval/embedding/guardrail versions, eval datasets, validators, traces, costs.

Prompt release example (payment-explanation-v1.4 → v1.5): version → offline eval (500 standard / 100 ambiguous / 100 adversarial / 50 vulnerable) → compare correctness, groundedness, plain language, escalation, cost, latency → shadow → 5%/20%/50%/100% rollout → rollback if quality or safety falls.

---

23. AgentOps

Requirements: tool registry, permissions, action approval, trajectory logging, step limits, timeouts, memory controls, recovery, human interruption, outcome evaluation.

Temporary card freeze trajectory: confirm auth → identify card → retrieve status → explain → explicit confirm → freeze tool → verify result → notify → audit. Cannot freeze another card, order replacement without permission, infer confirmation, claim success early or continue after identity failure.

Controls: max eight steps; one card per action; explicit confirmation; session-bound tool call; escalate after two failures; full trajectory retained.

---

24. DevSecOps pipeline

Code (SAST, deps, secrets, policy) → Build (signed artefacts, SBOM, container scan, provenance) → Test (unit/integration/security, prompt injection, data leakage, eval regression) → Deploy (env approval, IaC policy, identity, config) → Operate (runtime security, threat detection, IR, vuln management).

---

25. Site Reliability Engineering

SLI / SLO	Target
Customer-assistant availability	99.9%
Agent-assistant availability	99.95%
Standard response latency	95% < 4s
Payment API success	99.5%
Human handoff success	99%
Trace capture	99.99%

99.9% monthly error budget ≈ 43 minutes. Budget burned early → pause features, prioritise reliability, reduce rollout, disable unstable capabilities.

Postmortem example: incorrect “pending payment failed” messages—status mapping change, uncommunicated schema update, missing regression cases, incomplete context. Fixes: contract tests, schema versioning, fallbacks, expanded eval, dependency-change alerts.

---

26. FinOps

Tag by product, use case, environment, channel, model, owner, cost centre. Track cost per conversation/resolution/model/intent, tokens, evaluation, retrieval, variance.

Optimisation: payment assistant $0.21 → $0.09 via context filtering, shorter prompts, smaller models for simple cases, cached policy summaries. At 1M interactions: $210K → $90K ($120K annual reduction).

---

27–28. ATAM and ADRs

ATAM: largest model for every turn improves language quality but raises cost, latency, vendor dependency, scaling complexity and environmental impact. Prefer complexity-based routing: small classifier · deterministic status · medium for standard · large for complex summarisation.

ADR example — central model gateway: all production model access via gateway. + central security, usage visibility, portability, consistent policy; − platform dependency, possible latency, hub capacity. Status: Approved.

---

29. End-to-end interaction flow

1. Request from customer or agent
2. Channel authenticates
3. Minimum context forwarded
4. Intent identified
5. Policy router classifies
6. Guardrails inspect input
7. Retrieval of approved knowledge
8. Tools fetch permitted banking data
9. Model gateway selects approved model
10. Prompt builder constructs controlled context
11. Model drafts answer
12. Validator checks grounding and policy
13. Confidence/risk → respond / clarify / deterministic / escalate
14. Log interaction
15. Evaluation and monitoring receive telemetry
16. CRM receives approved summary
17. Benefits analytics records outcome

---

30. Architecture principles

1. Deterministic systems for deterministic facts
2. LMs for interpretation/generation—not systems of record
3. Do not expose raw legacy complexity to the model
4. Every tool action explicitly authorised
5. Every material response traceable
6. Every model and prompt versioned
7. Critical capabilities have fallbacks
8. Model providers replaceable
9. Human escalation always available
10. Operational cost measured per use case
11. Shared capabilities implemented once
12. Architecture reflects customer harm, not only technical failure

---

31. Stage gates

Gate	Evidence
Architecture approval	TOM, system context, data flows, security boundaries, integration, supplier strategy, quality attributes
Platform readiness	Gateway, retrieval, evaluation, observability, identity, deployment pipeline
Pilot technical readiness	C4, threat model, API contracts, prompt registry, eval dataset, runbooks, fallbacks
Production readiness	SLOs, incident testing, DR, cost budgets, load tests, security approval, operational ownership

---

32. Phase outputs

TOM and AI operating model; build–buy–partner; enterprise/business/data/application/technology architecture; ArchiMate and C4; bounded contexts; event models; API contracts; EDA; cloud landing zones; Well-Architected and Zero Trust; Data Mesh/Fabric; lakehouse/medallion; AI platform; MLOps/LLMOps/AgentOps; DevSecOps; SRE; FinOps; ADRs; production-readiness criteria.

---

33. Core conclusion

Not: customer message → language model → answer.

Rather:

Authenticated user → controlled orchestration → approved data and knowledge → governed model access → validated response or authorised action → human oversight → monitoring, evidence and continuous improvement.

Next phase: AI Engineering, Evaluation and Experimentation—CRISP-DM, ML and Agent Development Lifecycles, RAG, prompt engineering, tool-using agents, human-in-the-loop, experiment tracking, golden datasets, RAG/LLM/agent evaluation, offline and online evaluation, A/B testing, adversarial evaluation, red teaming, model validation and Production Readiness Review.