Voltar ao blog EN
26 de abril de 2026

Evoluindo aplicações agênticas no Microsoft Fabric: deploy automatizado e integração com Data Agents

Nos últimos meses, tenho acompanhado de perto como o Microsoft Fabric tem acelerado sua evolução para competir diretamente no espaço de IA e agentes.…

Microsoft Fabric AI Data Engineering

Introdução

Nos últimos meses, tenho acompanhado de perto como o Microsoft Fabric tem acelerado sua evolução para competir diretamente no espaço de IA e agentes. Não é segredo que o mercado está em uma corrida intensa: Databricks lançou o Mosaic AI Agent Framework, a AWS tem o Bedrock Agents, e a OpenAI continua empurrando o estado da arte com novas capacidades de orquestração, e o Claude então… nem se fala. O Fabric, que começou como uma plataforma unificada de dados e analytics, claramente decidiu que não vai ficar de fora dessa disputa.

Já existem alguns artigos distucinto o problema operacional clássico: o que acontece quando um agente sai do POC e começa a interagir com usuários reais, dados reais e processos de negócio em escala? Observabilidade, governança, avaliação. Tudo isso é essencial, mas há uma camada anterior a essa discussão que precisa ser endereçada primeiro: como você estrutura o ciclo de vida dessas aplicações agênticas de forma reproduzível? E como você conecta esses agentes diretamente ao seu ecossistema de dados sem criar gambiarras de integração?

É exatamente isso que a Microsoft tem endereçado nas últimas atualizações do Fabric: um conjunto de capacidades que vai desde automação de deploy até a introdução formal dos chamados Data Agents, que permitem que agentes conversem com seus dados de forma nativa dentro da plataforma. Vou destrinchar cada uma dessas frentes com o nível de detalhe que elas merecem.

Desenvolvimento Técnico

O problema do ciclo de vida em aplicações agênticas

Antes de falar sobre as soluções, é importante entender o problema. Aplicações agênticas têm uma complexidade de ciclo de vida muito maior do que um modelo preditivo tradicional. Um modelo de classificação tem um pipeline relativamente linear: coleta de dados, treino, validação, deploy, monitoramento. Um agente, por outro lado, envolve múltiplos componentes orquestrados: modelos de linguagem, ferramentas externas, memória, state management, e frequentemente múltiplos sub-agentes cooperando.

Isso significa que o conceito de “versão” de uma aplicação agêntica é mais nebuloso. Você pode mudar o prompt de sistema, trocar o modelo base, adicionar uma nova ferramenta, ou alterar a lógica de orquestração, e qualquer uma dessas mudanças pode impactar dramaticamente o comportamento observado. Sem uma estrutura de deploy automatizado e rastreável, você rapidamente perde a capacidade de correlacionar mudanças de comportamento com mudanças de configuração.

Deploy automatizado no Fabric: CI/CD para agentes

O Fabric tem avançado na direção de tratar aplicações agênticas como artefatos de primeira classe dentro do seu ecossistema de deployment. A integração com Git (suportando tanto Azure DevOps quanto GitHub) permite versionar não apenas notebooks e pipelines, mas também as definições dos agentes, incluindo configurações de modelos, definições de ferramentas e prompts.

A estrutura de deployment automatizado aproveita as APIs REST do Fabric para orquestrar promoções entre workspaces, o que é o equivalente funcional a ambientes de desenvolvimento, staging e produção. Um fluxo típico fica assim:

# Exemplo de pipeline Azure DevOps para deploy de agente no Fabric
trigger:
  branches:
    include:
      - main
      - release/*

stages:
  - stage: DeployDev
    jobs:
      - job: DeployAgentDev
        steps:
          - task: AzureCLI@2
            displayName: 'Deploy Agent to Dev Workspace'
            inputs:
              azureSubscription: '$(AZURE_SUBSCRIPTION)'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                # Autenticação via Service Principal
                az login --service-principal \
                  -u $(SP_CLIENT_ID) \
                  -p $(SP_CLIENT_SECRET) \
                  --tenant $(TENANT_ID)
                
                # Deploy via Fabric REST API
                curl -X POST \
                  "https://api.fabric.microsoft.com/v1/workspaces/$(DEV_WORKSPACE_ID)/items" \
                  -H "Authorization: Bearer $(az account get-access-token --query accessToken -o tsv)" \
                  -H "Content-Type: application/json" \
                  -d @agent_definition.json

  - stage: DeployProd
    dependsOn: DeployDev
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - job: DeployAgentProd
        steps:
          - task: AzureCLI@2
            displayName: 'Promote Agent to Production'
            inputs:
              azureSubscription: '$(AZURE_SUBSCRIPTION)'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                # Uso da Deployment Pipeline API do Fabric
                curl -X POST \
                  "https://api.fabric.microsoft.com/v1/pipelines/$(PIPELINE_ID)/deploy" \
                  -H "Authorization: Bearer $(az account get-access-token --query accessToken -o tsv)" \
                  -H "Content-Type: application/json" \
                  -d '{
                    "sourceStageOrder": 1,
                    "targetStageOrder": 2,
                    "items": [{"objectId": "$(AGENT_ITEM_ID)", "objectType": "AISkill"}]
                  }'

Esse fluxo resolve um problema concreto que qualquer time que já operou LLMs em produção conhece bem: a falta de rastreabilidade entre o que está rodando em prod e o que está no repositório.

Data Agents: a integração nativa com o ecossistema de dados

Esta é, na minha opinião, a parte mais interessante das atualizações recentes. Os Data Agents no Fabric são agentes que têm acesso nativo aos artefatos de dados da plataforma: lakehouses, warehouses, semantic models do Power BI e eventualmente outras fontes gerenciadas pelo OneLake.

A proposta de valor é direta: ao invés de você construir manualmente um agente com acesso a banco de dados via JDBC, escrever camadas de abstração para lidar com schemas dinâmicos, e gerenciar contexto sobre quais tabelas existem, o Fabric oferece uma camada de integração que já entende a estrutura dos seus dados. O agente pode receber perguntas em linguagem natural e gerar queries sobre seu lakehouse ou warehouse sem que você precise construir toda essa plumbing.

O fluxo de funcionamento interno segue uma lógica parecida com Text-to-SQL clássico, mas com algumas diferenças importantes:

# Exemplo conceitual de como um Data Agent interage com um Lakehouse no Fabric
# usando o SDK do Azure AI e integração com Fabric

from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

# Inicialização do cliente
client = AIProjectClient(
    subscription_id="<subscription_id>",
    resource_group_name="<resource_group>",
    project_name="<project_name>",
    credential=DefaultAzureCredential()
)

# O Data Agent no Fabric já tem o schema do Lakehouse como contexto
# O sistema injeta automaticamente metadados das tabelas relevantes

def query_data_agent(user_question: str, agent_id: str) -> dict:
    """
    Envia uma pergunta para o Data Agent configurado no Fabric.
    O agente resolve internamente:
    1. Identificação das tabelas relevantes no Lakehouse
    2. Geração de SQL/DAX baseado no schema
    3. Execução da query
    4. Formatação da resposta
    """
    thread = client.agents.create_thread()
    
    message = client.agents.create_message(
        thread_id=thread.id,
        role="user",
        content=user_question
    )
    
    run = client.agents.create_and_process_run(
        thread_id=thread.id,
        assistant_id=agent_id
    )
    
    if run.status == "completed":
        messages = client.agents.list_messages(thread_id=thread.id)
        return {
            "status": "success",
            "response": messages.get_last_text_message_by_role("assistant"),
            "run_id": run.id  # Para rastreabilidade e avaliação posterior
        }
    else:
        return {
            "status": "failed",
            "error": run.last_error,
            "run_id": run.id
        }

# Uso
resultado = query_data_agent(
    user_question="Qual foi o total de vendas por região no último trimestre?",
    agent_id="<data_agent_id_no_fabric>"
)
print(resultado["response"])

Comparação com abordagens alternativas

Vale contextualizar onde o Fabric se posiciona em relação a outras plataformas:

**Databricks + Mosaic AI:**O Databricks tem o Unity Catalog como base para dar contexto aos agentes sobre os dados disponíveis. A diferença é que o Databricks oferece mais flexibilidade na orquestração (via LangChain, LlamaIndex ou o próprio Agent Framework), mas exige mais configuração manual. O Fabric está apostando em uma experiência mais guiada e integrada, com menos fricção para quem já vive no ecossistema Microsoft.

Azure AI Foundry: O Fabric e o Azure AI Foundry estão convergindo nas suas capacidades. A distinção está ficando mais tênue: o Fabric traz a camada de dados, o AI Foundry traz a camada de modelos e avaliação. A Microsoft está claramente orquestrando esses serviços para trabalharem juntos, com o Fabric servindo como o plano de dados unificado para aplicações agênticas corporativas.

Limitações : O Text-to-SQL e Text-to-DAX gerado pelos Data Agents ainda tem limitações conhecidas em queries complexas com múltiplos joins, lógica de negócio não óbvia no schema, ou quando as tabelas têm nomenclaturas ambíguas. A qualidade do resultado é fortemente dependente de como o schema está documentado (descrições de colunas, tabelas bem nomeadas, metadados ricos no Lakehouse).

Exemplo prático: configurando um Data Agent no Fabric

O processo de criar um Data Agent no Fabric hoje segue os seguintes passos:

1. Criar o artefato AI Skill no Workspace:

Dentro do workspace do Fabric, você cria um item do tipo “AI Skill” (o Data Agent). Nesse processo, você seleciona quais fontes de dados do Lakehouse ou Warehouse o agente terá acesso.

2. Enriquecer o contexto do schema:

Este passo é crítico e frequentemente negligenciado. Você deve adicionar descrições nas tabelas e colunas que o agente usará. O Fabric usa essas descrições para melhorar a precisão da geração de SQL.

-- Exemplo de como documentar suas tabelas no Fabric Warehouse
-- para melhorar a qualidade do Data Agent

-- Adicionando descrições via T-SQL no Fabric Warehouse
EXEC sp_addextendedproperty 
    @name = N'MS_Description',
    @value = N'Tabela de fatos de vendas consolidada diariamente. 
               Granularidade: uma linha por transação de venda. 
               Atualizada todo dia às 06h00 via pipeline ETL.',
    @level0type = N'SCHEMA', @level0name = N'dbo',
    @level1type = N'TABLE',  @level1name = N'fct_vendas';

EXEC sp_addextendedproperty 
    @name = N'MS_Description',
    @value = N'Valor líquido da venda após descontos, em BRL.',
    @level0type = N'SCHEMA', @level0name = N'dbo',
    @level1type = N'TABLE',  @level1name = N'fct_vendas',
    @level2type = N'COLUMN', @level2name = N'valor_liquido_brl';

3. Configurar instruções de sistema:

O Data Agent aceita um system prompt onde você pode definir restrições de comportamento, contexto de negócio e orientações sobre como interpretar perguntas ambíguas. Pense nisso como o “contrato” entre o agente e o domínio de dados que ele representa.

4. Testar e avaliar:

O Fabric oferece uma interface de chat integrada para testar o agente diretamente. Para avaliação sistemática, você pode integrar com as capacidades de avaliação do Azure AI Foundry, capturando pares de pergunta/resposta e avaliando corretude das queries geradas.

5. Expor via API:

Uma vez validado, o Data Agent pode ser exposto como uma API REST que suas aplicações consomem. Essa API se integra com a autenticação do Entra ID, o que resolve o problema de controle de acesso sem precisar gerenciar tokens customizados.

Conclusão

O que fica claro ao analisar essa evolução do Fabric é que a Microsoft está jogando um jogo de convergência. A plataforma está consolidando o que antes exigia múltiplos serviços distintos (um data warehouse, um serviço de ML, uma camada de orquestração de agentes e uma API gateway) em uma experiência unificada.

Para times que já estão no ecossistema Microsoft, isso é genuinamente atraente. A fricção de integração é menor, a governança via Microsoft Purview já existe, e a curva de adoção para quem conhece Power BI e Azure Data Factory é razoável.

Para times que avaliam o Fabric como nova plataforma, os pontos de atenção continuam sendo os mesmos de sempre: a maturidade das capacidades ainda está em evolução acelerada (o que significa que algumas features ainda têm limitações operacionais), e a flexibilidade de customização tende a ser menor do que em stacks mais abertas como Databricks ou soluções baseadas em LangChain.

O próximo passo natural desta série é observabilidade e avaliação em produção, porque deploy é apenas o começo. Saber se o seu Data Agent está respondendo corretamente, identificar quando ele alucina uma query ou interpreta mal uma pergunta de negócio, e ter mecanismos para corrigi-lo sem um ciclo de release completo, esse é o problema que vai separar as implementações maduras das experimentais.

E o Fabric, ao que tudo indica, sabe disso e está construindo nessa direção.

Publicado originalmente no Medium — Medium