Dos dados ao diálogo: como a S&P Global Energy tornou seu patrimônio de dados estruturados conversacional com Databricks Genie Agents e MCP

O objetivo da S&P Global era melhorar fundamentalmente a forma como os clientes descobrem e consomem insights em nossos produtos de dados e pesquisas. Embora a busca e a sumarização baseadas em AI sejam importantes, o maior valor de negócios vem de permitir uma tomada de decisão mais rápida por meio do acesso em linguagem natural a dados confiáveis, análises mais ricas entre diferentes commodities e a capacidade de conectar insights que tradicionalmente existem em linhas de negócios separadas. Os agentes de AI ajudam os clientes a descobrir relações, gerar pesquisas de forma mais eficiente e extrair inteligência acionável de um conjunto de informações mais amplo do que era possível anteriormente.   —Priyanka John, Vice-presidente, S&P Global Energy

Se você já tentou disponibilizar um patrimônio de dados estruturados grande e complexo para agentes e assistentes de AI, provavelmente se deparou com a mesma barreira que nós: os agentes são tão bons quanto o contexto que conseguem acessar, e os dados corporativos raramente vivem em um único lugar organizado e bem documentado.

Na S&P Global Energy, nossos dados abrangem produtos químicos, petróleo bruto, produtos refinados, gás e energia, gás natural liquefeito (LNG) e muito mais — e cada commodity é, por si só, uma rica família de conjuntos de dados. O LNG sozinho inclui especificações de instalações, cargas, interrupções, fundamentos de oferta e demanda, netbacks, preços históricos e previstos, e contratos. Os produtos químicos abrangem capacidade, produção, utilização, comércio, demanda por uso final e por derivado, variação de estoque e balanços de oferta e demanda em nível de país e região. Nossas outras commodities seguem padrões semelhantes. Esses dados vivem no Databricks e em várias fontes que não são do Databricks.

Nosso objetivo era ambicioso, mas simples de definir: disponibilizar todo o nosso patrimônio de dados estruturados para consumo externo por agentes de AI por meio do Model Context Protocol (MCP) — para que os agentes e assistentes de nossos clientes, bem como os nossos próprios, pudessem fazer perguntas em linguagem natural e obter respostas confiáveis e governadas.

Avaliamos várias abordagens. O que funcionou melhor para nós, por uma ampla margem, foram os Databricks Genie Agents, expostos como servidores MCP gerenciados, compostos em pacotes específicos de domínio com uma camada de proxy MCP.

Neste post, você aprenderá:

• Como nossos especialistas no assunto (SMEs) fazem a curadoria de Genie Agents focados — um por grupo de conjunto de dados dentro de cada commodity — sem escrever uma única linha de código de agente.
• Como cada Genie Agent se torna automaticamente um servidor MCP governado, pronto para ser conectado a qualquer cliente ou agente compatível com MCP.
• Como usamos um proxy baseado em FastMCP para compor múltiplos servidores Genie MCP em endpoints compostos para perguntas de vários domínios.
• Por que essa arquitetura reduziu drasticamente nosso tempo de lançamento no mercado para produtos de dados baseados em AI.

Os Genie Agents permitem que nossos especialistas de domínio transformem seu conhecimento dos dados diretamente em produto. O que antes levava um ciclo completo de desenvolvimento agora leva dias, e cada resposta permanece dentro do nosso limite de governança. —Priyanka John, Vice-presidente, S&P Global Energy

O desafio: dados estruturados são fáceis de armazenar, difíceis de conversar

Os grandes modelos de linguagem são incrivelmente bons em conversação e raciocínio, mas não podem responder a perguntas sobre seus dados a menos que você construa uma ponte para eles. Para dados corporativos estruturados, essa ponte historicamente significou uma das seguintes opções:

1. Pipelines de text-to-SQL criados manualmente — poderosos, mas frágeis. Cada alteração de esquema, cada nome de coluna ambíguo, cada definição de métrica específica do domínio (“O que conta como um dia de interrupção?”) torna-se uma tarefa de engenharia.
2. APIs personalizadas por caso de uso — cada novo padrão de pergunta precisa de um novo endpoint, uma nova sprint, uma nova versão.
3. Exportar dados para ferramentas de AI externas — o que duplica os dados, quebra a atualização e sai do seu perímetro de governança.

Cada uma dessas abordagens compartilha o mesmo problema: as pessoas que melhor entendem os dados — nossos SMEs e analistas — não são as pessoas que constroem a camada de acesso. Cada insight precisava passar por um backlog de engenharia. Nosso tempo de lançamento no mercado para uma nova experiência de dados conversacionais era medido em meses.

Precisávamos de uma abordagem em que os especialistas de domínio pudessem fazer a curadoria e publicar o acesso conversacional aos dados diretamente, a engenharia pudesse padronizar como os agentes se conectam e a governança permanecesse centralizada. Foi exatamente isso que os Genie Agents combinados com o MCP nos proporcionaram.

A arquitetura: Genie Agents como a camada semântica, MCP como o contrato

Nossa arquitetura tem três camadas, e cada camada pertence às pessoas mais adequadas para ela. O diagrama acima mostra o fluxo de ponta a ponta — incluindo o que fica dentro da rede da S&P Global Energy e o que fica no ambiente do cliente externo.

Camada 1: SMEs fazem a curadoria de um Genie Agent por grupo de conjunto de dados

É aqui que a mágica começa e, notavelmente, não requer código.

Nossos SMEs começam selecionando as tabelas relevantes para um domínio de negócios:

• Se as tabelas já vivem no Databricks, eles as usam diretamente por meio do Unity Catalog.
• Se os dados vivem em uma fonte que não é do Databricks, eles os trazem por meio de conectores do Lakehouse Federation — sem movimentação de dados, sem pipelines duplicados. As tabelas federadas aparecem ao lado das tabelas nativas e herdam a mesma governança.

Eles então agrupam tabelas relacionadas e criam um Genie Agent por grupo de conjunto de dados — não um único agente gigante por commodity. Cada subcategoria de uma commodity se torna seu próprio Genie Agent focado. Dentro do LNG, por exemplo:

• LNG Assets & Contracts Genie Agent — ativos, operadores, previsões de capacidade e contratos de longo prazo
• LNG Cargo Genie Agent — rastreamento de carga, fixações (fixtures), origens/destinos e termos comerciais
• LNG Tenders Genie Agent  — licitações com emissores, volumes e janelas de entrega
• LNG Outages Genie Agent — interrupções e eventos de manutenção com impacto na capacidade
• LNG Supply & Demand Genie Agent — fundamentos com divisões regionais e histórico de cenários
• LNG Netbacks Genie Agent — netbacks a partir de preços de hub, frete, evaporação (boil-off) e perdas
• LNG Prices Genie Agent — curvas de preços históricas e previstas

Todas as outras commodities seguem o mesmo padrão com suas próprias subcategorias. Os produtos químicos, por exemplo, têm Genie Agents em nível de grupo para capacidade, produção, utilização de capacidade, comércio, demanda por uso final e por derivado, variação de estoque e balanços de oferta e demanda em nível de país e região; petróleo bruto, produtos refinados e gás e energia são organizados de forma semelhante. O resultado é uma frota de Genie Agents pequenos e com escopo bem definido, em vez de um punhado de ferramentas de AI desconectadas e dispersas.

Dentro de cada agente, os SMEs adicionam o contexto que faz o text-to-SQL realmente funcionar no mundo real: descrições de tabelas e colunas, consultas de exemplo, ativos confiáveis para métricas críticas e definições de negócios (por exemplo, “o armazenamento flutuante é definido como cargas ociosas por 3 dias ou mais em embarcações que viajam abaixo de uma velocidade limite”). Esta é a etapa que as soluções genéricas de text-to-SQL ignoram — e é a etapa que determina se os usuários confiam nas respostas.

O principal insight organizacional: a curadoria tornou-se uma atividade de domínio, não uma atividade de engenharia. A pessoa que sabe o que significa “armazenamento flutuante” em um contexto de LNG é a pessoa que ensina a um Genie o que isso significa.

Camada 2: Cada Genie Agent é automaticamente um servidor MCP

Aqui é onde a Databricks fez o trabalho pesado por nós. Cada Genie Agent é exposto como um servidor MCP gerenciado pela Databricks pronto para uso, em um endpoint com o seguinte formato:

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

Não há nada para implantar e nada para hospedar. Cada servidor expõe uma interface de ferramentas pequena e limpa — essencialmente duas ferramentas por agente:

1. Uma ferramenta de consulta (genie_query_space) — o agente envia uma pergunta em linguagem natural para o agente.
2. Uma ferramenta de resposta (genie_poll_response) — o agente faz consultas periódicas com o mesmo ID de conversa e de mensagem para recuperar a resposta completa assim que estiver pronta, incluindo o SQL gerado e o conjunto de resultados.

Esse padrão de duas ferramentas, do tipo perguntar-e-consultar (ask-then-poll), mostra-se ideal para cargas de trabalho de agentes: as perguntas são executadas de forma assíncrona em um SQL warehouse, e o agente faz consultas periódicas com o ID de conversa e de mensagem retornado pela ferramenta de consulta até que a resposta esteja pronta.

Igualmente importante, esses servidores gerenciados são governados pelo Unity Catalog. Um Genie Agent — ou o usuário por trás dele — só pode acessar os agentes e as tabelas subjacentes que tem permissão para visualizar. A autenticação é tratada pela plataforma. Não precisamos criar uma camada de segurança em torno do nosso acesso de IA; herdamos a que já tínhamos.

Camada 3: Compondo Genie Agents de grupo em pacotes de commodities com um proxy FastMCP

Um Genie Agent por grupo de conjunto de dados mantém cada agente focado e preciso. Mas perguntas de negócios reais rotineiramente cruzam grupos: “Como as interrupções recentes em Sabine Pass afetaram os prêmios de carga para a Ásia?” afeta tanto o Genie Agent de Outages quanto o de Cargo ao mesmo tempo, e perguntas que cruzam commodities, como “Como os preços da nafta estão afetando as margens de produção química?”, abrangem os Genie Agents de Refined Products e Chemicals.

Em vez de criar um único agente gigante (o que reduz a qualidade das respostas) ou forçar cada cliente a configurar uma dúzia de servidores separados, usamos os recursos de proxy e composição do FastMCP para criar endpoints MCP compostos — normalmente um por commodity, montando os servidores Genie MCP de nível de grupo dessa commodity atrás de um único servidor com ferramentas organizadas por namespaces. Compostos de nível superior podem agrupar várias commodities da mesma forma:

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 …

(Trecho ilustrativo — adapte para sua versão do FastMCP e configuração de autenticação.)

O resultado: um agente se conecta a um endpoint composto por commodity e visualiza um conjunto selecionado de ferramentas de grupo — cargo_genie_query_agent, outages_genie_query_agent, netbacks_genie_query_agent e assim por diante, cada uma emparelhada com sua contraparte genie_poll_response. O LLM do agente decide para qual Genie de grupo direcionar uma pergunta, ou distribui uma pergunta que cruza grupos entre vários deles, e depois sintetiza os resultados.

Isso nos deu o melhor dos dois mundos: Genie Agents de nível de grupo específicos e de alta precisão na base, e um acesso conversacional amplo para toda a commodity e todo o acervo de dados no topo.

O que mudou para a empresa

Para as nossas partes interessadas de negócios, os detalhes técnicos acima se traduzem em alguns resultados muito tangíveis.

O time-to-market despencou. Anteriormente, criar uma nova experiência de dados conversacionais significava um ciclo completo de desenvolvimento: requisitos, design de API, engenharia de text-to-SQL, testes, implantação. Com essa arquitetura, lançar um novo grupo de conjunto de dados — ou uma commodity inteira — significa que um SME cria e faz a curadoria dos Genie Agents correspondentes — o endpoint MCP passa a existir no mesmo instante em que o agente é criado.

Os SMEs tornaram-se publicadores, não solicitantes. Os especialistas de domínio que entendem de cargas de LNG ou de equilíbrios de oferta e demanda de produtos químicos não precisam mais abrir chamados para expor seus dados; eles fazem a curadoria de um Genie Agent e ele já fica ativo. O esforço de engenharia mudou da criação de camadas de acesso personalizadas para a manutenção de uma única camada de proxy fina e reutilizável.

A governança já vem integrada. Cada pergunta que um agente faz passa pelas permissões do Unity Catalog, em tabelas governadas (nativas ou federadas), com total auditabilidade. Disponibilizar dados para a IA não significou torná-los disponíveis fora dos nossos controles.

Um único padrão de integração, muitos consumidores — dentro e fora da empresa. Como o MCP é um padrão aberto, os mesmos endpoints compostos atendem aos nossos agentes internos, às nossas experiências de IA voltadas para o cliente e — fundamentalmente — aos nossos clientes externos, que podem conectar seus próprios agentes e assistentes compatíveis com MCP diretamente aos dados governados da S&P Global Energy. Construímos a ponte uma única vez; cada cliente MCP, interno ou externo, pode cruzá-la.

A qualidade das respostas é mensurável e continua assim. Em um domínio onde dados de preços, oferta e contratos orientam decisões reais, os usuários precisam confiar em cada resposta e cálculo. Os Genie Agent Benchmarks oferecem aos nossos SMEs uma maneira integrada de definir perguntas de teste que refletem como os usuários realmente fazem perguntas (incluindo várias formulações da mesma pergunta) e pontuar a precisão do agente de forma automática em relação a respostas verificadas. Igualmente importante, os benchmarks podem ser executados novamente após qualquer refinamento nas instruções, nos dados ou na lógica de negócios, mantendo a precisão ao longo do tempo. O resultado é um ciclo contínuo e eficiente de qualidade: curadoria, benchmark, melhoria e novo benchmark para garantir que nossos agentes permaneçam precisos à medida que nossos dados e as perguntas dos nossos clientes evoluem.

Lições aprendidas e melhores práticas

Algumas conclusões práticas da nossa jornada para equipes que estão considerando um caminho semelhante:

1. Mantenha os Genie Agents focados e bem selecionados. A qualidade da resposta é maior quando um agente cobre um domínio de dados específico com instruções claras e consultas de exemplo. Resista à tentação de criar um agente por commodity — ou pior, um agente para governar a todos. Em vez disso, reúna vários domínios de dados na camada MCP.
2. Use a Lakehouse Federation antes de criar pipelines. Para fontes que não são do Databricks, a federação nos levou ao nível “conversacional” sem um único novo trabalho de ETL. Você sempre pode materializar os caminhos mais acessados (hot paths) mais tarde.
3. Invista na camada semântica. Descrições de colunas, definições de negócios e consultas de exemplo confiáveis são o que separam uma demonstração de um produto. Este é um tempo de SME bem gasto.
4. Organize suas ferramentas compostas em namespaces de forma clara. Quando um agente visualiza ferramentas de muitos Genies de grupo, prefixos como cargo_ e outages_ ajudam o LLM a direcionar as perguntas corretamente.
5. Meça a confiança, não apenas a latência. Acompanhamos a frequência com que os SMEs concordavam com o SQL gerado pelo Genie durante a curadoria — esse é o melhor indicador antecedente para saber se os usuários de negócios adotarão a experiência.

Conclusão

Nosso objetivo era disponibilizar todo o nosso acervo de dados estruturados — abrangendo LNG, Chemicals, Crude Oil, Refined Products, Gas & Power e muito mais — para agentes de IA: de forma segura, precisa e rápida. Com os Genie Agents da Databricks como a camada semântica com curadoria de SMEs, servidores MCP gerenciados como o contrato de integração sem implantação e um proxy FastMCP para composição entre domínios, alcançamos exatamente isso:

• Velocidade: Novos domínios de dados conversacionais entram em operação em dias, não em ciclos de desenvolvimento — impulsionando nosso time-to-market.
• Precisão: Agentes com escopo de domínio e curadoria de SMEs fornecem respostas em que os usuários de negócios realmente confiam.
• Governança: O Unity Catalog protege cada pergunta, tanto em dados nativos quanto federados, sem a necessidade de manter uma pilha de segurança paralela.
• Abertura: Uma única ponte padrão MCP atende a todos os agentes atuais e futuros, internos ou externos.

No entanto, a mudança mais profunda é organizacional: as pessoas que entendem os dados agora são as mesmas que publicam o acesso a eles. Isso, mais do que qualquer tecnologia isolada, foi o que transformou nossos dados estruturados de algo que os usuários consultam em algo com o qual eles podem simplesmente conversar.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original