Fala dataholics! Chegamos no último post da série de Tools, e não tem jeito mais bonito de fechar do que juntando os agentes do Copilot Studio com o Databricks, que é a alma desse blog. Nos quatro posts anteriores a gente aprendeu a dar tools pro agente de três formas: conector pronto, API REST via OpenAPI e servidor MCP. Hoje a gente aplica isso no Lakehouse. Fiz uma animação de fechamento e embaixo dela eu abro os dois caminhos.

O que veremos nesse post:

• Caminho 1: SQL Warehouse pelo conector Databricks

• Caminho 2: Model Serving como REST API tool

• Quando é tool e quando é Genie

• Resumo (e o fecho da série)

Caminho 1: SQL Warehouse pelo conector Databricks

A forma mais direta de deixar o agente consultar seus dados é usando o conector do Databricks, que já existe pronto no catálogo do Copilot Studio, exatamente o cenário do post [1]. Esse conector vem com um menu de ações prontas, e a estrela pra dados é a Execute a SQL statement, que roda uma query num SQL Warehouse seu (serverless ou classic, tanto faz). Tem outras ações também, tipo disparar e listar jobs, mas pra responder sobre dados é a query que importa.

Na prática você adiciona o conector como tool, configura a conexão com o seu workspace e o warehouse, e dá pro agente uma query tipo esta:

SELECT status, COUNT(*) AS total
FROM vendas
GROUP BY status

Aí quando o usuário pergunta algo que cai nessa consulta, o agente roda a query no seu warehouse e devolve a resposta já mastigada. É o mesmo modelo de tool que a gente viu na série, só que a fonte agora é o seu Lakehouse.

Detalhe importante: esse caminho depende de você ter o Managed MCP servers habilitado (em preview) no seu workspace do Databricks, então confere isso antes de sair configurando, pra não travar na metade.

Caminho 2: Model Serving como REST API tool

O segundo caminho é pra quando você não quer só consultar dado, mas chamar um modelo que você serviu no Databricks. Um endpoint de Model Serving nada mais é do que uma API REST: você manda um JSON com a entrada e recebe a predição de volta. E se é uma API REST, você já sabe o final da história, ela sobe como REST API tool, o mesmo caminho dos posts [2] e [4].

Você descreve o endpoint num OpenAPI, sobe pelo wizard de REST API e configura a autenticação com o token do Databricks (como API key no header de authorization). Pronto, o seu modelo virou uma ferramenta que o agente aciona sozinho quando faz sentido, tipo classificar um chamado ou prever um churn no meio da conversa.

Quando é tool e quando é Genie

Aqui vale um recado pra você não usar a ferramenta errada. Os dois caminhos de cima são pra chamada específica: uma query que você já sabe, ou um modelo com entrada e saída definidas. Eles são certeiros e previsíveis.

Reginaldo, e se eu quiser que o usuário pergunte qualquer coisa sobre os dados, em linguagem natural?

Aí a ferramenta certa não é uma tool de SQL na mão, é o Genie. O Genie é o especialista do Databricks em transformar pergunta em linguagem natural em SQL, com o contexto curado do seu Genie Space. Ele também se conecta ao Copilot Studio, mas como é um mundo à parte e cheio de detalhe, eu vou dedicar uma série inteira só pra ele. Então guarda essa régua: tool pra ação certeira, Genie pra explorar os dados.

RESUMO

• SQL Warehouse: use o conector Databricks pronto e a ação Execute a SQL statement pra rodar uma query no seu warehouse. Precisa do Managed MCP servers habilitado no workspace.

• Model Serving: o endpoint é uma API REST, então sobe como REST API tool, igual aos posts [2] e [4], com o token do Databricks na autenticação.

• Chamada específica (query ou modelo) é caso de tool. Pergunta aberta em linguagem natural é caso de Genie.

• Com isso a série fecha as formas de dar tools pro agente: conector, REST, MCP, Azure Function e agora Databricks.

E é isso, dataholics, fechamos a série de Tools do Copilot Studio. Passamos pelo catálogo de conectores, criamos tools do zero com REST e OpenAPI, conectamos servidores MCP, chamamos uma Azure Function e hoje plugamos o Databricks. O próximo passo natural é ir fundo no Genie, e é pra lá que a gente vai. Obrigado por acompanhar a série inteira.

Referências:

https://learn.microsoft.com/en-us/azure/databricks/integrations/msft-power-platform/copilot-studio

https://learn.microsoft.com/en-us/connectors/databricksinc/

Fique bem e até a próxima.

#copilotstudio #databricks #sqlwarehouse #modelserving #ia #agentes #datainaction

Hey dataholics! We've reached the last post in the Tools series, and there's no prettier way to close it than by bringing together Copilot Studio agents and Databricks, which is the soul of this blog. In the four previous posts we learned to give the agent tools in three ways: a ready-made connector, a REST API via OpenAPI and an MCP server. Today we apply that to the Lakehouse. I made a closing animation and below it I break down the two paths.

What we'll cover in this post:

• Path 1: SQL Warehouse via the Databricks connector

• Path 2: Model Serving as a REST API tool

• When it's a tool and when it's Genie

• Summary (and the series wrap-up)

Path 1: SQL Warehouse via the Databricks connector

The most direct way to let the agent query your data is using the Databricks connector, which already exists in the Copilot Studio catalog, exactly the scenario from post [1]. This connector comes with a menu of ready actions, and the star for data is Execute a SQL statement, which runs a query on one of your SQL Warehouses (serverless or classic, either works). There are other actions too, like triggering and listing jobs, but for answering about data the query is what matters.

In practice you add the connector as a tool, configure the connection to your workspace and warehouse, and give the agent a query like this one:

SELECT status, COUNT(*) AS total
FROM vendas
GROUP BY status

Then when the user asks something that falls into this query, the agent runs it on your warehouse and returns the answer already chewed over. It's the same tool model we saw in the series, only the source is now your Lakehouse.

Important detail: this path depends on you having Managed MCP servers enabled (in preview) in your Databricks workspace, so check that before you start configuring, so you don't get stuck halfway.

Path 2: Model Serving as a REST API tool

The second path is for when you don't just want to query data but call a model you served on Databricks. A Model Serving endpoint is nothing more than a REST API: you send a JSON with the input and get the prediction back. And if it's a REST API, you already know how the story ends, it goes up as a REST API tool, the same path as posts [2] and [4].

You describe the endpoint in an OpenAPI, upload it through the REST API wizard and configure authentication with the Databricks token (as an API key in the authorization header). Done, your model became a tool the agent triggers on its own when it makes sense, like classifying a ticket or predicting churn in the middle of the conversation.

When it's a tool and when it's Genie

Here's a heads-up so you don't reach for the wrong tool. The two paths above are for a specific call: a query you already know, or a model with a defined input and output. They're precise and predictable.

Reginaldo, and what if I want the user to ask anything about the data, in natural language?

Then the right tool isn't a hand-written SQL tool, it's Genie. Genie is the Databricks specialist at turning a natural-language question into SQL, with the curated context of your Genie Space. It also connects to Copilot Studio, but since it's a world of its own and full of detail, I'm going to dedicate a whole series just to it. So keep this rule of thumb: a tool for a precise action, Genie to explore the data.

RECAP

• SQL Warehouse: use the ready-made Databricks connector and the Execute a SQL statement action to run a query on your warehouse. Needs Managed MCP servers enabled in the workspace.

• Model Serving: the endpoint is a REST API, so it goes up as a REST API tool, just like posts [2] and [4], with the Databricks token for authentication.

• A specific call (query or model) is a tool case. An open natural-language question is a Genie case.

• With that the series closes the ways to give tools to the agent: connector, REST, MCP, Azure Function and now Databricks.

And that's it, dataholics, we've closed the Copilot Studio Tools series. We went through the connector catalog, built tools from scratch with REST and OpenAPI, connected MCP servers, called an Azure Function and today we plugged in Databricks. The natural next step is to go deep into Genie, and that's where we're headed. Thanks for following the whole series.

References:

https://learn.microsoft.com/en-us/azure/databricks/integrations/msft-power-platform/copilot-studio

https://learn.microsoft.com/en-us/connectors/databricksinc/

Stay well and see you next time.

#copilotstudio #databricks #sqlwarehouse #modelserving #ai #agents #datainaction