Los asistentes de investigación empresarial necesitan EA, LangGraph, MCP y RAG.
Las investigaciones empresariales unen tickets, registros y libros contables bajo un marco de gobernanza. Por qué se necesitan EA, LangGraph y MCP para obtener pruebas, y RAG para las explicaciones, en fases.
Arquitectura empresarial para un asistente de investigación multi-fuentes: área administrativa, registros de Grafana y resúmenes de transacciones
Rara vez los investigadores trabajan dentro de un único sistema de registro. Un asistente útil debe alinear las solicitudes de la área administrativa, los registros de Grafana y los resúmenes de transacciones en una misma línea temporal. Eso constituye un problema de arquitectura empresarial: límites, gobernanza y entrega por fases, no un chatbot para fines de semana.
Por qué se trata de un problema de arquitectura empresarial y no de un proyecto de “chatbot”
Las interfaces de chat ocultan las partes más complejas: qué fuente es la autorizada para una cantidad determinada, quiénes pueden acceder a información personal identificable, cómo las herramientas se comunican entre zonas de red y cómo las respuestas citan pruebas. Los registros de decisiones arquitectónicas y las fases al estilo TOGAF mantienen esas cuestiones claras antes de que aumente la cantidad de consultas.
ADM en una frase
El Método de Desarrollo Arquitectónico secuencia la visión, los negocios, los datos, la tecnología, las oportunidades, la migración, la gobernanza y el cambio, de modo que la entrega no omita el consentimiento ni el control.
Fase preliminar: principios antes de las solicitudes
Acuerde los principios desde el principio: mínimo privilegio, citar o rechazar, las herramientas deben demostrar su eficacia mientras RAG explica los detalles, y aprobación humana para acciones irreversibles. Sin principios, cada nuevo conector inventa su propio modelo de confianza.
Fase A: Visión arquitectónica: describir los problemas en lenguaje empresarial
Los investigadores pierden horas yendo de un portal a otro para responder “¿qué pasó con este pago?”. El éxito en esta fase se manifiesta como una narrativa coherente con enlaces a los IDs de los tickets, líneas de registro y entradas contables, no como un ensayo genérico generado por una IA.
Fase B: Arquitectura empresarial: qué implica la investigación
Asigne roles (analista, operaciones contra el fraude, auditor), desencadenantes (estorno, alerta de anomalía) y resultados (cerrar, escalar, solicitar más datos). Cada resultado implica diferentes permisos de herramienta.
Fase C: Arquitectura de datos: tres verdades, un cronograma
El área administrativa, la capacidad de observación y las transacciones revelan cada una una verdad parcial. Normalice los identificadores, zonas horarias y claves de entidad para que las uniones sean precisas. Almacene la procedencia de cada segmento recuperado.
Fase D: Arquitectura tecnológica: LangGraph, MCP, roles RAG
LangGraph orquesta flujos de trabajo de investigación con estado. MCP expone herramientas gestionadas en sistemas separados. RAG resume y explica; no inventa silenciosamente saldos.
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
¿Por qué LangGraph? (Decisión ARB)
Rama de investigaciones: a veces se obtienen primero los registros, otras veces el libro mayor, y en ocasiones se espera a que intervenga un humano. Los gráficos con puntos de control son superiores a las cadenas lineales cuando las pausas y las reproducciones son algo habitual.
MCP: un protocolo, muchas fronteras empresariales
Cada servidor MCP se encuentra en una frontera de confianza con su propia autenticación. El agente descubre las herramientas sin tener que incluir cada SDK. Las políticas de red permanecen vinculadas a los servidores, no al texto de las instrucciones.
RAG: explica; las herramientas prueban
Los embeddings recuperan el contexto narrativo; las verificaciones de equilibrio y las consultas a los registros se realizan mediante herramientas que acceden a los sistemas de registro. Mezclar ambos sin etiquetas genera una falsa sensación de confianza.
Fase E: Oportunidades y soluciones
Desarrolle la orquestación internamente; compre o reutilice conectores donde los proveedores ya hayan integrado sistemas clave; evite volver a escribir Grafana o el libro mayor.
Fase F: Migración: pruebas piloto sin arriesgar todo
Comience con un tipo de investigación y una unidad empresarial, revisando las respuestas obtenidas bajo supervisión humana. Amplíe las fuentes solo después de que las métricas de aceptación o rechazo se estabilicen.
Fase G: Gobernanza de implementación
ARB determina las decisiones: qué herramientas están permitidas, dónde se almacenan los secretos y cómo se conservan las trazas.
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 |
Fase H: Gestión de cambios
Los modelos evolucionan; la política de investigación no debe hacerlo. Utilice prompts de versión y herramientas como APIs; vuelva a capacitar al personal cuando cambie el comportamiento de rechazo.
Lo que aprendimos (“y”, no “vs”)
LangGraph y MCP y RAG cooperan: orquestación, acceso y explicación. Tratarlos como rivales desperdicia la arquitectura.
Cuándo no construir esto
Si una sola búsqueda en el CRM ya responde al 95% de los tickets, un agente multi-fuentes es innecesario. Constrúyalo cuando la integración de cronologías entre sistemas sea el cuello de botella.
Conclusión
Los asistentes de investigación empresarial tienen éxito cuando la arquitectura define las verdades, las herramientas y los elementos humanos involucrados; luego LangGraph simplemente ejecuta ese diseño.
Notas más detalladas sobre la integración de la Fase C
Los investigadores pierden confianza cuando las marcas de tiempo difieren en horas porque un sistema utiliza UTC y otro el horario local. Estándarice el uso de UTC en la vista de línea de tiempo del asistente y muestre las zonas originales como metadatos. La resolución de entidades (ID de cuenta frente a correo electrónico frente a ID de dispositivo) debe formar parte de la arquitectura de datos, no de instrucciones que intenten adivinar. Prefiera búsquedas deterministas de datos maestros mediante herramientas MCP en lugar de menciones vagas basadas en RAG.
Notas más detalladas sobre el plano de control de la Fase D
El estado de LangGraph debe contener el ID de la investigación, el ID del agente, el conjunto de herramientas permitidas y una zona de trabajo con hipótesis. Los descriptores de herramientas MCP deben indicar la clase de efecto secundario (lectura o escritura). Las colecciones RAG se dividen según su nivel de sensibilidad. El ARB debe rechazar diseños que permitan al modelo crear consultas SQL contra almacenes de producción; solo las herramientas seleccionadas cuidadosamente pueden acceder a esos sistemas.
Métricas piloto importantes
- Tiempo mediano hasta encontrar la primera evidencia citada
- Porcentaje de respuestas que incluyen al menos dos tipos de fuentes independientes
- Tasa de anulación humana en las llamadas a herramientas
- Tasa de rechazo por evidencia insuficiente
- Intentos de acceso entre usuarios bloqueados
Las métricas superficiales como “mensajes enviados” no demuestran el valor investigativo.
Antipatrones
Crear un megaíndice de todo sin campos ACL; permitir que el LLM elija los controladores de base de datos en bruto; omitir la Fase H para que las peticiones cambien semanalmente sin revisión; tratar a Grafana como un elemento decorativo opcional en lugar de un canal de evidencia de primera categoría para los fallos en tiempo de ejecución.
Ejemplo narrativo
Un analista pregunta por qué se revirtió un pago. El sistema abre la herramienta de casos (back office), obtiene los IDs de las transacciones relacionadas, consulta los registros alrededor de la fecha de liquidación y solo entonces elabora un resumen con referencias. Si faltan registros, el asistente se niega a dar una respuesta definitiva y solicita un período de tiempo más amplio, en lugar de inventar una explicación ficticia.
Instantáneas de la arquitectura de seguridad
Coloque los servidores MCP en las mismas zonas de seguridad que los sistemas que protegen. El orquestador en una DMZ solo debe poder ver los puntos de extremo de las herramientas, no las cadenas de conexión a la base de datos. Los tokens de corta duración por investigación son mejores que las claves de servicio de larga duración compartidas entre agentes. Registre las invocaciones de las herramientas en un registro de auditoría inmutable, distinto a los rastros del modelo, para que el equipo de cumplimiento pueda saber quién consultó qué línea del registro sin tener que descargar los prompts completos.
Relación con ITSM existente
No reemplace la herramienta de gestión de casos desde el primer día. Escriba los resultados del asistente como comentarios en el caso, acompañados de referencias. Los analistas siguen siendo responsables; la estructura gráfica acelera el proceso. Los pilotos de la fase F que intentan cerrar automáticamente los casos suelen tropezar con problemas de confianza; los comentarios en modo sombra construyen esa confianza mediante pruebas concretas.
Habilidades versus herramientas básicas (capa opcional)
A medida que crecen los catálogos de herramientas, las “habilidades” de investigación pueden encapsular secuencias (obtener caso → recuperar transacciones → consultar registros → resumir), mientras que MCP sigue siendo la capa de funcionalidades. Esto refleja la dirección general de la industria sin necesidad de un nuevo estándar hasta que el piloto demuestre su valor.
Resumen ejecutivo para ARB
Solicite financiación en función de la reducción del tiempo de manejo y de una mejor capacidad de auditoría, no en base a “tener un agente”. Muestre una demostración de la secuencia antes/después con tres fuentes. Se comprometa a rechazar las tarifas y las pruebas ACL como requisitos para el lanzamiento. Con este enfoque, LangGraph y MCP son detalles de implementación de una arquitectura aprobada, no un proyecto independiente junto a ella.
Contratos de datos para las tres verdades
Publica un esquema sencillo para CaseEvent, LogAnchor y LedgerPosting que sean compartidos por las herramientas MCP y los indexadores. Los cronogramas de investigación deserializan esos objetos en lugar de texto libre. Cuando una fuente no pueda proporcionar un campo, indícalo explícitamente como null para que el sintetizador no genere valores ficticios. Los contratos evolucionan a través del mismo camino ARB que los servicios, y no solo mediante ediciones de prompts.
Dokumenta las suposiciones del flujo de control junto al código, para que las ediciones futuras no eliminen silenciosamente algún nodo o filtro. Prefiere afirmaciones verificables por máquinas en lugar del conocimiento interno compartido únicamente en hilos de chat. Realiza simulacros de fallos cada vez que cambien las reglas de topología o identidad.
Lecturas relacionadas
- Triaje de flotas con LangGraph: cortocircuito de emergencia antes de los diagnósticos RAG — Los informes de vehículos por WhatsApp requieren primero un triaje; las órdenes de parada de emergencia omiten la recuperación de datos, mientras que los síntomas normales activan manuales, generación con Llama y evaluaciones de fidelidad.
- FastMCP Voice Stack Parte 2: Orquestación con LangGraph para agentes de voz — Se añaden el estado de LangGraph, bordes condicionales, herramientas y verificadores de puntos de control para hacer que el servidor MCP de la Parte 1 funcione de una conversación a otra.