Enterprise investigation assistants need EA, LangGraph, MCP, and RAG

Enterprise architecture for a multi-source investigation assistant — back office, Grafana logs, and transaction summaries

Investigators rarely live in one system of record. A useful assistant must align back-office tickets, Grafana logs, and transaction summaries on one timeline. That is an enterprise-architecture problem: boundaries, governance, and phased delivery—not a weekend chatbot.

Why this is an EA problem, not a “chatbot” project

Chat UIs hide the hard parts: which source is authoritative for an amount, who may see PII, how tool calls cross network zones, and how answers cite evidence. Architecture Decision Records and TOGAF-style phases keep those questions explicit before prompts multiply.

ADM in one sentence

The Architecture Development Method sequences vision, business, data, technology, opportunities, migration, governance, and change—so delivery does not skip consent and control.

Preliminary Phase — principles before prompts

Agree principles early: least privilege, cite-or-refuse, tools prove while RAG explains, and human approval for irreversible actions. Without principles, every new connector invents its own trust model.

Phase A — Architecture Vision: pain in business language

Investigators waste hours hopping between portals to answer “what happened to this payment?” Vision success looks like a single threaded narrative with links to ticket ids, log lines, and ledger entries—not a generic LLM essay.

Phase B — Business Architecture: what investigation means

Map roles (analyst, fraud ops, auditor), triggers (chargeback, anomaly alert), and outcomes (close, escalate, request more data). Each outcome implies different tool permissions.

Phase C — Data Architecture: three truths, one timeline

Back-office, observability, and transactions each tell partial truth. Normalize identifiers, time zones, and entity keys so joins are real. Store provenance on every retrieved span.

Phase D — Technology Architecture: LangGraph, MCP, RAG roles

LangGraph orchestrates stateful investigation workflows. MCP exposes governed tools into segregated systems. RAG summarizes and explains; it does not silently invent balances.

User question →
classify intent + extract entities (player_id, time window, txn id)
→ plan tools (which sources, in what order)
→ execute tools (parallel where independent)
→ reconcile (timeline merge, conflict detection)
→ answer (cited) OR escalate

Why LangGraph? (ARB decision)

Investigations branch: sometimes pull logs first, sometimes ledger first, sometimes wait on a human. Graphs with checkpoints beat linear chains when pauses and replays are normal.

MCP — one protocol, many enterprise boundaries

Each MCP server sits at a trust boundary with its own auth. The agent discovers tools without embedding every SDK. Network policies stay attached to servers, not to prompt text.

RAG — explains; tools prove

Embeddings retrieve narrative context; balance checks and log queries go through tools that hit systems of record. Mixing the two without labels creates false confidence.

Phase E — Opportunities & Solutions

Build orchestration in-house; buy or reuse connectors where vendors already wrap core systems; avoid rewriting Grafana or the ledger.

Phase F — Migration: pilot without betting the bank

Start with one investigation type, one business unit, shadowed answers reviewed by humans. Expand sources only after cite-or-refuse metrics stabilize.

Phase G — Implementation governance

ARB locks decisions: which tools are allowed, where secrets live, how traces are retained.

ADR-008:
Player investigation assistant
LangGraph orchestration, MCP tools, RAG for context onlyStatus:
Accepted Date: 03/01/2026
Deciders: Architecture Board, Support Ops, Fraud, Payments, SRE, Data Platform, Risk
Context: Support, fraud ops, and back office investigate player issues by manually querying transaction summaries, Grafana/Loki logs, and back-office APIs. Answers are slow, inconsistent, and hard to audit. A generic "chat with your data" approach risks hallucinated financial facts and unbounded database access.
Decision Build an internal player investigation assistant: LangGraph- stateful orchestration (classify → plan → execute tools → reconcile → answer or escalate). Chosen over linear chains and one-shot prompts because investigations branch (payment vs gameplay vs bonus), require explicit state for audit, and need deterministic edges (e.g. FAILED txn → always pull payment-service logs) that ARB can diagram and version in Phase H MCP servers - one bounded tool surface per system of
record: `transaction_summary` - read-only parameterized queries on summary views `grafana_loki` - time-bounded LogQL with service allowlist `back_office` - scoped REST for account flags and context RAG - embed docs only (schema, enums, runbooks, ADR snippets); never live txn rows or log streams Citations required - factual claims must reference tool output ids Fail closed on ambiguous `player_id` or conflicting tool resultsConsequences Positive: Faster investigations; consistent citations; reusable MCP servers for future automations; clear security boundary (tools vs retrieval). Negative: LangGraph flow maintenance; MCP server ownership per domain team; golden-question regression suite required on model changes. Obligations: No free-form SQL from the model; quarterly access review; version MCP schemas when summary views change; shadow mode before full rollout.Alternatives considered | Alternative | Why rejected | |-------------|--------------| | Single prompt with DB + Grafana credentials | Ungovernable; audit nightmare | | RAG over exported txn/log snapshots | Stale truth; PII surface area | | Buy vendor "AI ops" suite only | Poor fit to gaming txn + custom back office; lock-in | | Dashboards only | Solves visibility, not synthesis and audit trail | | Autonomous agent with write tools | Unacceptable risk on wallet/account paths for v1 |

Phase H — Change management

Models drift; investigation policy should not. Version prompts and tools like APIs; retrain staff when refusal behavior changes.

What we learned (“and” not “vs”)

LangGraph and MCP and RAG cooperate: orchestration, access, and explanation. Treating them as rivals wastes the architecture.

When not to build this

If a single CRM search already answers 95% of tickets, a multi-source agent is ceremony. Build when cross-system timeline assembly is the bottleneck.

Wrapping up

Enterprise investigation assistants succeed when architecture names the truths, the tools, and the human gates—then LangGraph merely executes that design.

Deeper notes on Phase C joins

Investigators lose trust when timestamps disagree by hours because one system is UTC and another is local. Standardize on UTC in the assistant’s timeline view and show original zones as metadata. Entity resolution (account id versus email versus device id) belongs in data architecture, not in a prompt that guesses. Prefer deterministic master-data lookups via MCP tools before fuzzy RAG mentions.

Deeper notes on Phase D control plane

LangGraph state should carry investigation id, actor id, allowed tool set, and a scratchpad of hypotheses. MCP tool descriptors must declare side-effect class (read vs write). RAG collections are partitioned by sensitivity. The ARB should reject designs that let the model invent SQL against production warehouses; only curated tools may touch those systems.

Pilot metrics that matter

• Median time to first cited evidence
• Percent of answers with at least two independent source types
• Human override rate on tool calls
• Refuse rate on insufficient evidence
• Cross-tenant access attempts blocked

Vanity metrics like “messages sent” do not prove investigative value.

Anti-patterns

Building a mega-index of everything without ACL fields; letting the LLM choose raw database drivers; skipping Phase H so prompts drift weekly without review; treating Grafana as optional color instead of a first-class evidence channel for runtime failures.

Narrative example

An analyst asks why a payout reversed. The graph opens the case tool (back office), pulls related transaction ids, queries logs around the settlement timestamp, and only then drafts a summary with citations. If logs are missing, the assistant refuses certainty and asks for a wider time window—rather than fabricating a processor narrative.

Security architecture snapshots

Place MCP servers in the same security zones as the systems they wrap. The orchestrator in a DMZ should only see tool endpoints, not database connection strings. Short-lived tokens per investigation beat long-lived service keys shared across agents. Record tool invocations in an immutable audit log distinct from model traces so compliance can read who pulled which ledger line without downloading full prompts.

Relationship to existing ITSM

Do not replace the case tool on day one. Write assistant outputs back as case comments with citations. Analysts remain accountable; the graph accelerates assembly. Phase F pilots that attempt to auto-close cases usually stall on trust—shadow mode comments build that trust with evidence.

Skills versus raw tools (optional layer)

As tool catalogs grow, investigation “skills” can package sequences (pull case → fetch txs → query logs → summarize) while MCP remains the capability layer. That mirrors broader industry direction without requiring a new standard before the pilot proves value.

Executive summary for ARB

Ask for funding against reduced handle time and improved auditability, not against “having an agent.” Show a before/after timeline assembly demo with three sources. Commit to refuse rates and ACL tests as release gates. With that framing, LangGraph and MCP are implementation details of an approved architecture—not a science project beside the architecture.

Data contracts for the three truths

Publish a small schema for CaseEvent, LogAnchor, and LedgerPosting shared by MCP tools and indexers. Investigation timelines deserialize those objects rather than free text. When a source cannot provide a field, mark it null explicitly so the synthesizer cannot hallucinate a fill-in. Contracts evolve through the same ARB path as services—not through prompt edits alone.

Document the control-flow assumptions beside the code so future edits cannot silently delete an edge or a filter. Prefer machine-checkable assertions over tribal knowledge shared only in chat threads. Rehearse failure drills whenever topology or identity rules change.