Chamberlain Insights

Plataforma de analítica C-level con IA que sustituye un dashboard BI estático por un equipo de agentes especializados que razonan, se autocorrigen y escalan a humanos cuando hace falta criterio. Construida a medida sobre la estructura OKR de una sola compañía — no una plataforma genérica — y validada al céntimo contra la herramienta BI legacy.

Mi rol

AI product engineer

Período

2026

Estado

En producción

Stack

React/Vite/TSFastAPILangGraphDatabricksUnity CatalogSQL Statement APIpgvector

El brief era simple sobre el papel y duro en la práctica: sustituir un dashboard BI de refresco semanal usado por el equipo ejecutivo por algo que pudiera contestar preguntas cross-dominio en lenguaje natural, no solo renderizar tiles de KPI. Cinco dominios OKR, decenas de key results, tres sistemas upstream — financiero, billing por suscripción, gold dimensional — y una vara de exactitud no negociable: cada número publicado tenía que reconciliar al céntimo contra la herramienta BI legacy. El punto de partida era un POC de pipeline único que resolvía «¿cuánto es X?» limpio pero colapsaba en preguntas que requerían descomposición: por qué cayó el volumen de un segmento mientras subía su precio medio, dónde está la brecha entre target y actuals. Los pipelines lineales no contestan eso. Un equipo de agentes sí.

Databricks App con frontend React 19 + Vite + TypeScript y backend FastAPI que envuelve un pipeline LangGraph multi-agente: un Supervisor StateGraph más tres sub-grafos especialistas, todos sobre Databricks serving endpoints, Unity Catalog y un Lakebase Postgres con pgvector.

1. Supervisor StateGraph que descompone preguntas ejecutivas en sub-tareas y reensambla la respuesta final.
2. Data Agent con once nodos: intent, golden cache, few-shot, generación SQL, validación, ejecución y narración.
3. Reasoning Agent dedicado a síntesis cross-dominio sobre los resultados consolidados de los sub-agentes.
4. Validation Agent determinístico — sin LLM en el loop — para cross-reference contra la herramienta BI legacy.
5. Inferencia sobre Databricks serving endpoints con Claude Opus, Sonnet y Haiku según rol y coste por nodo.
6. Ejecución SQL vía SQL Statement API contra Unity Catalog leyendo solo del schema semántico curado.
7. Lakebase Postgres con pgvector para golden cache de 1024 dimensiones, charts pinneados y cola de revisión humana.
8. MLflow Tracing instrumentando cada llamada LLM y SSE haciendo streaming de la ejecución al frontend en vivo.

Multi-agente sobre monolito.

Un Supervisor descompone la pregunta ejecutiva en sub-tareas y las despacha a tres especialistas — Data Agent (text-to-SQL con autocorrección y caché golden), Reasoning Agent (síntesis narrativa cross-dominio) y Validation Agent (cross-reference determinístico, sin LLM en el loop) — antes de reensamblar la respuesta. El patrón es estándar en finance ops; el valor aquí está en la disciplina de orquestación.

Autocorrección como feature de producto.

Cuando el SQL generado falla o produce un outlier, el Data Agent lee el error, reintenta con feedback explícito y publica la traza. Cuando la confianza es baja o el impacto alto, dispara un checkpoint HITL a través de la primitiva interrupt-and-resume del framework de grafo.

Penny-perfect o no se publica.

Cada número publicado se reconcilia contra la herramienta BI legacy dentro de una tolerancia documentada. Los números que no pueden cuadrar quedan flagueados como TBD, nunca aproximados en silencio: la confianza del ejecutivo se construye una respuesta a la vez y se pierde en una sola.

• El bug más caro que atrapamos fue una discrepancia de doble-dígito porcentual que todo el mundo asumió que era un mismatch de definición. Cuatro métricas de volumen comercial en el dominio financiero estaban sobre-contando contra la herramienta legacy. Las primeras tres hipótesis fueron todas semánticas — segmento, jerarquía, filtro de tipo de producto. Reescribimos el SQL tres veces. Nada cerró el gap.
• La causa raíz vivía aguas arriba. La herramienta legacy leía de una tabla origen distinta — una vista de estado financiero a nivel de modelo, no la fact diaria — y aplicaba un filtro de tipo de moneda heredado del sistema origen que jamás llegó a nuestra copia. La lección: validar el join antes de debatir la semántica. Cada métrica posterior recibe un check de procedencia de tabla origen antes de tocar un fragmento de SQL.
• Regla arquitectónica no negociable: la aplicación lee únicamente del schema semántico curado, nunca de tablas origen crudas. Enforced en la capa de configuración para que no se cuele por accidente en una rama feature.
• La validación se sacó del repo de la aplicación a notebooks reusables propiedad del equipo de data engineering, con un gate de varianza inferior a la décima de punto antes de que cualquier flag de fuente se active en producción.
• El sistema atrapa sus propias anomalías en directo. El demo flow muestra deliberadamente cómo el agente flaguea un valor, reintenta con un filtro corregido y recupera la respuesta correcta delante de la audiencia — la transparencia es el producto.

• Cinco de seis dominios OKR vivos en la plataforma, cubriendo la mayor parte de la superficie de key results — todos los dominios cuya data origen existe en el warehouse.
• Backend y frontend feature-complete: cinco tarjetas de dashboard, input de query en lenguaje natural, chat multi-agente con traza de razonamiento, UX HITL de confirm/refine/reject, charts pinneados por usuario, panel admin con revisión de golden queries y shell renderizado en Three.js.
• Caché golden de treinta y cinco queries seedadas desde SQL validado, entregando respuestas sub-tres-segundos en las preguntas comunes.
• Text-to-SQL cubriendo la cola larga en menos de ocho segundos con autocorrección sobre errores y outliers detectados en runtime.
• Validación al céntimo en dos dominios contra la herramienta BI legacy, dos más reconciliando dentro de tolerancia estricta y uno direccional pendiente de un rebuild upstream.
• Demo en vivo donde el sistema se autocorrige delante del público — flaguea, reintenta y recupera la respuesta sin intervención manual.

Estado actual

Backend y frontend feature-complete sobre cinco dominios OKR; caché golden de treinta y cinco queries en producción; dos dominios validados al céntimo, dos dentro de tolerancia y uno direccional pendiente de rebuild upstream; demo flow embarcado y operativo.

Próximos pasos

Sexto dominio desbloqueado cuando su data origen aterrice en el warehouse. Las lecciones del pivot de alineamiento PBI a tres workstreams informan el contrato upstream del dominio restante para garantizar que la validación al céntimo sostenga al añadirlo.