De los datos al diálogo: cómo S&P Global Energy convirtió su patrimonio de datos estructurados en conversacional con agentes Databricks Genie y MCP

El objetivo de S&P Global era mejorar fundamentalmente la forma en que los clientes descubren y consumen información de valor en nuestros productos de datos e investigación. Aunque la búsqueda y el resumen impulsados por AI son importantes, el mayor valor comercial proviene de permitir una toma de decisiones más rápida mediante el acceso en lenguaje natural a datos confiables, análisis más completos entre diferentes materias primas y la capacidad de conectar insights que tradicionalmente existen en líneas de negocio separadas. Los agentes de AI ayudan a los clientes a descubrir relaciones, generar investigaciones de manera más eficiente y obtener inteligencia accionable a partir de un conjunto de información más amplio de lo que antes era posible.   —Priyanka John, vicepresidenta de S&P Global Energy

Si alguna vez ha intentado poner un entorno de datos estructurados grande y complejo a disposición de asistentes y agentes de AI, es probable que se haya topado con la misma pared que nosotros: los agentes son tan buenos como el contexto al que pueden acceder, y los datos empresariales rara vez se encuentran en un único lugar ordenado y bien documentado.

En S&P Global Energy, nuestros datos abarcan productos químicos, petróleo crudo, productos refinados, gas y electricidad, gas natural licuado (LNG) y más — y cada materia prima es en sí misma una rica familia de conjuntos de datos. El LNG por sí solo incluye especificaciones de instalaciones, cargamentos, interrupciones, fundamentos de oferta y demanda, netbacks, precios históricos y proyectados, y contratos. Los productos químicos abarcan capacidad, producción, utilización, comercio, demanda por uso final y por derivado, cambios en el inventario y balances de oferta y demanda a nivel de país y región. Nuestras otras materias primas siguen patrones similares. Estos datos residen en Databricks y en varias fuentes ajenas a Databricks.

Nuestro objetivo era ambicioso pero sencillo de expresar: hacer que todo nuestro entorno de datos estructurados estuviera disponible para el consumo externo por parte de agentes de AI a través del Model Context Protocol (MCP) — de modo que tanto los agentes y asistentes de nuestros clientes como los nuestros pudieran hacer preguntas en lenguaje natural y obtener respuestas confiables y gobernadas.

Evaluamos varios enfoques. Lo que mejor nos funcionó, por un amplio margen, fueron los Databricks Genie Agents, expuestos como servidores MCP administrados, integrados en paquetes específicos de dominio con una capa de proxy MCP.

En esta publicación, aprenderá:

• Cómo nuestros expertos en la materia (SMEs) diseñan Genie Agents enfocados (uno por grupo de conjuntos de datos dentro de cada materia prima) sin escribir una sola línea de código de agente.
• Cómo cada Genie Agent se convierte automáticamente en un servidor MCP gobernado, listo para conectarse a cualquier cliente o agente compatible con MCP.
• Cómo utilizamos un proxy basado en FastMCP para integrar múltiples servidores Genie MCP en endpoints compuestos para preguntas multidominio.
• Por qué esta arquitectura redujo drásticamente nuestro tiempo de comercialización para productos de datos impulsados por AI.

Los Genie Agents permiten a nuestros expertos de dominio convertir directamente en productos su conocimiento de los datos. Lo que antes requería un ciclo de desarrollo completo ahora toma días, y cada respuesta permanece dentro de nuestro límite de gobernanza. —Priyanka John, vicepresidenta de S&P Global Energy

El desafío: los datos estructurados son fáciles de almacenar, pero es difícil interactuar con ellos

Los modelos de lenguaje grande son sorprendentemente buenos para conversar y razonar, pero no pueden responder preguntas sobre sus datos a menos que construya un puente hacia ellos. Para los datos empresariales estructurados, ese puente históricamente ha significado una de las siguientes opciones:

1. Pipelines de texto a SQL creados a mano — potentes, pero frágiles. Cada cambio de esquema, cada nombre de columna ambiguo, cada definición de métrica específica del dominio (¿qué se considera un día de interrupción?) se convierte en una tarea de ingeniería.
2. APIs personalizadas por caso de uso — cada nuevo patrón de pregunta necesita un nuevo endpoint, un nuevo sprint, una nueva versión.
3. Exportar datos a herramientas de AI externas — lo que duplica los datos, afecta su actualización y se sale de su perímetro de gobernanza.

Cada uno de estos enfoques comparte el mismo problema: las personas que mejor entienden los datos (nuestros SMEs y analistas) no son quienes construyen la capa de acceso. Cada insight tenía que pasar por un backlog de ingeniería. Nuestro tiempo de comercialización para una nueva experiencia de datos conversacionales se medía en meses.

Necesitábamos un enfoque en el que los expertos de dominio pudieran diseñar y publicar directamente el acceso conversacional a los datos, la ingeniería pudiera estandarizar cómo se conectan los agentes y la gobernanza se mantuviera centralizada. Eso es exactamente lo que nos brindaron los Genie Agents junto con el MCP.

La arquitectura: Genie Agents como capa semántica, MCP como contrato

Nuestra arquitectura tiene tres capas, y cada capa pertenece a las personas más adecuadas para ella. El diagrama anterior muestra el flujo de extremo a extremo, incluido lo que se encuentra dentro de la red de S&P Global Energy y lo que se encuentra en el entorno del cliente externo.

Capa 1: los SMEs diseñan un Genie Agent por grupo de conjuntos de datos

Aquí es donde comienza la magia y, notablemente, no requiere código.

Nuestros SMEs comienzan seleccionando las tablas relevantes para un dominio de negocio:

• Si las tablas ya residen en Databricks, las utilizan directamente a través de Unity Catalog.
• Si los datos residen en una fuente ajena a Databricks, los importan a través de conectores de Lakehouse Federation — sin movimiento de datos ni pipelines duplicados. Las tablas federadas aparecen junto a las tablas nativas y heredan la misma gobernanza.

Luego, agrupan las tablas relacionadas y crean un Genie Agent por grupo de conjuntos de datos — no un único agente gigante por materia prima. Cada subcategoría de una materia prima se convierte en su propio Genie Agent enfocado. Dentro de LNG, por ejemplo:

• Genie Agent de activos y contratos de LNG — activos, operadores, pronósticos de capacidad y contratos a largo plazo
• Genie Agent de cargamentos de LNG Agent — seguimiento de cargamentos, fletamentos (fixtures), orígenes/destinos y términos comerciales
• Genie Agent de licitaciones de LNG  — licitaciones con emisores, volúmenes y plazos de entrega
• Genie Agent de interrupciones de LNG — interrupciones y eventos de mantenimiento con impacto en la capacidad
• Genie Agent de oferta y demanda de LNG — fundamentos con desgloses regionales e historial de escenarios
• Genie Agent de netbacks de LNG — netbacks a partir de precios de referencia (hub), fletes, evaporación (boil-off) y pérdidas
• Genie Agent de precios de LNG — curvas de precios históricas y proyectadas

Todas las demás materias primas siguen el mismo patrón con sus propias subcategorías. Los productos químicos, por ejemplo, cuentan con Genie Agents a nivel de grupo para capacidad, producción, utilización de capacidad, comercio, demanda por uso final y por derivado, cambios en el inventario y balances de oferta y demanda a nivel de país y región; el petróleo crudo, los productos refinados y el gas y la electricidad se organizan de manera similar. El resultado es una flota de Genie Agents pequeños y con un alcance bien definido, en lugar de un puñado de herramientas de AI desarticuladas y dispersas.

Dentro de cada agente, los SMEs agregan el contexto que hace que text-to-SQL realmente funcione en el mundo real: descripciones de tablas y columnas, consultas de ejemplo, activos confiables para métricas críticas y definiciones comerciales (por ejemplo, “el almacenamiento flotante se define como cargamentos inactivos durante 3 días o más en embarcaciones que viajan por debajo de un umbral de velocidad”). Este es el paso que las soluciones genéricas de texto a SQL omiten, y es el paso que determina si los usuarios confían en las respuestas.

La perspectiva organizativa clave: la curación se convirtió en una actividad de dominio, no en una actividad de ingeniería. La persona que sabe lo que significa “almacenamiento flotante” en un contexto de LNG es la persona que le enseña a un Genie lo que significa.

Capa 2: Cada agente de Genie es automáticamente un servidor MCP

Aquí es donde Databricks hizo el trabajo pesado por nosotros. Cada agente de Genie se expone como un servidor MCP administrado por Databricks de forma predeterminada, en un endpoint con el formato:

https://<workspace-hostname>/api/2.0/mcp/genie/{genie_space_id}

No hay nada que implementar ni nada que alojar. Cada servidor expone una interfaz de herramientas pequeña y limpia; esencialmente dos herramientas por agente:

1. Una herramienta de consulta (genie_query_space): el agente envía una pregunta en lenguaje natural al agente.
2. Una herramienta de respuesta (genie_poll_response): el agente realiza consultas periódicas con el mismo ID de conversación y de mensaje para recuperar la respuesta completa una vez que esté lista, incluyendo el SQL generado y el conjunto de resultados.

Este patrón de dos herramientas, de tipo preguntar y luego consultar, resulta ideal para cargas de trabajo de agentes: las preguntas se ejecutan de forma asíncrona en un SQL warehouse, y el agente realiza consultas periódicas con el ID de conversación y de mensaje devuelto por la herramienta de consulta hasta que la respuesta esté lista.

De igual importancia, estos servidores administrados están gobernados por Unity Catalog. Un agente de Genie (o el usuario detrás de él) solo puede acceder a los agentes y a las tablas subyacentes para los que tiene permiso de visualización. La autenticación la gestiona la plataforma. No tuvimos que crear una capa de seguridad en torno a nuestro acceso de AI; heredamos la que ya teníamos.

Capa 3: Composición de agentes de Genie grupales en paquetes de materias primas con un proxy FastMCP proxy

Un agente de Genie por grupo de conjuntos de datos mantiene a cada agente enfocado y preciso. Pero las preguntas comerciales reales suelen abarcar varios grupos: “¿Cómo afectaron las interrupciones recientes en Sabine Pass a las primas de carga hacia Asia?” afecta tanto al agente de Genie de Outages como al de Cargo a la vez, y las preguntas que abarcan varias materias primas, como “¿Cómo afectan los precios de la nafta a los márgenes de producción de productos químicos?”, abarcan los agentes de Genie de Refined Products y Chemicals.

En lugar de crear un único agente gigante (lo que reduce la calidad de las respuestas) o de obligar a cada cliente a configurar una docena de servidores independientes, utilizamos las capacidades de proxy y composición de FastMCP para crear endpoints de MCP compuestos (normalmente uno por materia prima), montando los servidores MCP de Genie a nivel de grupo de esa materia prima detrás de un único servidor con herramientas con espacio de nombres. Los compuestos de nivel superior pueden agrupar varias materias primas de la misma manera:

from fastmcp import FastMCP

# Each group-level Genie Agent is a managed MCP server on Databricks 
cargo = FastMCP.as_proxy(genie_mcp_config(“lng_cargo_agent_id”), name=“cargo”) 
outages = FastMCP.as_proxy(genie_mcp_config(“lng_outages_agent_id”), name=“outages”) 
netbacks = FastMCP.as_proxy(genie_mcp_config(“lng_netbacks_agent_id”), name=“netbacks”) 

# Compose the group Genies into one commodity bundle 
lng = FastMCP(name=“lng-composite”) 
lng.mount(cargo, prefix=“cargo”)
lng.mount(outages, prefix=“outages”)
lng.mount(netbacks, prefix=“netbacks”) 

# The same pattern repeats for Chemicals, Crude Oil, Refined Products, Coal …

(Fragmento ilustrativo: adáptelo a su versión de FastMCP y configuración de autenticación).

El resultado: un agente se conecta a un endpoint compuesto por materia prima y ve un conjunto seleccionado de herramientas grupales: cargo_genie_query_agent, outages_genie_query_agent, netbacks_genie_query_agent, etc., cada una emparejada con su contraparte genie_poll_response. El LLM del agente decide a qué Genie de grupo dirigir una pregunta, o distribuye una pregunta que abarca varios grupos entre varios de ellos, y luego sintetiza los resultados.

Esto nos dio lo mejor de ambos mundos: agentes de Genie a nivel de grupo específicos y de alta precisión en la base, y un acceso conversacional amplio para todas las materias primas y todo el patrimonio de datos en la parte superior.

Qué cambió para el negocio

Para nuestras partes interesadas del negocio, los detalles técnicos anteriores se traducen en algunos resultados muy tangibles.

El tiempo de comercialización se redujo drásticamente. Anteriormente, poner en marcha una nueva experiencia de datos conversacionales implicaba un ciclo de desarrollo completo: requisitos, diseño de API, ingeniería de text-to-SQL, pruebas e implementación. Con esta arquitectura, lanzar un nuevo grupo de conjuntos de datos (o una materia prima completa) significa que un SME crea y cura los agentes de Genie correspondientes; el endpoint de MCP existe en el mismo momento en que se crea el agente.

Los SME se convirtieron en editores, no en solicitantes. Los expertos en el dominio que entienden los cargamentos de LNG o los balances de oferta y demanda de productos químicos ya no abren tickets para que se expongan sus datos; curan un agente de Genie y este se activa de inmediato. El esfuerzo de ingeniería pasó de crear capas de acceso personalizadas a mantener una capa de proxy delgada y reutilizable.

La gobernanza viene integrada. Cada pregunta que hace un agente pasa por los permisos de Unity Catalog, en tablas gobernadas (nativas o federadas), con total auditabilidad. Hacer que los datos estuvieran disponibles para la AI no significó ponerlos a disposición fuera de nuestros controles.

Un único patrón de integración, muchos consumidores, dentro y fuera de la empresa. Debido a que MCP es un estándar abierto, los mismos endpoints compuestos sirven para nuestros agentes internos, nuestras experiencias de AI de cara al cliente y, lo que es fundamental, nuestros clientes externos, quienes pueden conectar sus propios agentes y asistentes compatibles con MCP directamente a los datos gobernados de S&P Global Energy data. Construimos el puente una vez; cada cliente de MCP, interno o externo, puede cruzarlo.

La calidad de las respuestas es medible y se mantiene así. En un dominio donde los datos de precios, suministro y contratos impulsan decisiones reales, los usuarios deben confiar en cada respuesta y cálculo. Las evaluaciones de referencia de agentes de Genie (Genie Agent Benchmarks) ofrecen a nuestros SME una forma integrada de definir preguntas de prueba que reflejan cómo los usuarios formulan realmente las preguntas (incluidas múltiples formas de expresar la misma pregunta) y calificar la precisión del agente automáticamente en comparación con respuestas verificadas. De igual importancia, las evaluaciones de referencia se pueden volver a ejecutar después de cualquier perfeccionamiento de las instrucciones, los datos o la lógica empresarial, de modo que la precisión se mantenga a lo largo del tiempo. El resultado es un bucle de calidad continuo y eficiente: curar, evaluar, mejorar y volver a evaluar para garantizar que nuestros agentes sigan siendo precisos a medida que evolucionan nuestros datos y las preguntas de nuestros clientes.

Lecciones aprendidas y mejores prácticas

Algunas conclusiones prácticas de nuestro recorrido para los equipos que estén considerando un camino similar:

1. Mantenga los agentes de Genie específicos y bien curados. La calidad de la respuesta es mayor cuando un agente cubre un dominio de datos específico con instrucciones claras y consultas de ejemplo. Resista la tentación de crear un agente por materia prima o, peor aún, un único agente para gobernarlos a todos. En su lugar, reúna múltiples dominios de datos en la capa de MCP.
2. Utilice Lakehouse Federation antes de crear pipelines. Para fuentes que no son de Databricks, la federación nos permitió llegar a lo “conversacional” sin un solo trabajo de ETL nuevo. Siempre puede materializar las rutas de acceso rápido más adelante.
3. Invierta en la capa semántica. Las descripciones de las columnas, las definiciones comerciales y las consultas de ejemplo de confianza son lo que separa una demostración de un producto. Este es un tiempo bien invertido por parte de los SME.
4. Asigne espacios de nombres a sus herramientas compuestas de forma clara. Cuando un agente ve herramientas de muchos Genies de grupo, los prefijos como cargo_ y outages_ ayudan al LLM a dirigir las preguntas correctamente.
5. Mida la confianza, no solo la latencia. Realizamos un seguimiento de la frecuencia con la que los SME estaban de acuerdo con el SQL generado por Genie durante la curación; es el mejor indicador adelantado de si los usuarios comerciales adoptarán la experiencia.

Conclusión

Nuestro objetivo era hacer que todo nuestro patrimonio de datos estructurados (que abarca LNG, productos químicos, petróleo crudo, productos refinados, gas y energía, y más) estuviera disponible para los agentes de AI: de forma segura, precisa y rápida. Con los agentes de Genie de Databricks como la capa semántica curada por los SME, los servidores MCP administrados como el contrato de integración sin implementación y un proxy FastMCP para la composición entre dominios, logramos exactamente eso:

• Velocidad: Los nuevos dominios de datos conversacionales se activan en días, no en ciclos de desarrollo, lo que impulsa enormemente nuestro tiempo de comercialización.
• Precisión: Los agentes especializados por dominio y curados por expertos en la materia (SME) ofrecen respuestas en las que los usuarios de negocio realmente confían.
• Gobernanza: Unity Catalog protege cada pregunta, tanto en datos nativos como federados, sin necesidad de mantener una pila de seguridad paralela.
• Apertura: Un único puente con estándar MCP sirve a todos los agentes actuales y futuros, ya sean internos o externos.

Sin embargo, el cambio más profundo es organizativo: las personas que entienden los datos son ahora quienes publican el acceso a ellos. Eso, más que cualquier tecnología individual, es lo que transformó nuestros datos estructurados de algo que los usuarios consultan a algo con lo que simplemente pueden hablar.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original