¡Jueves de post! Antes de empezar con el post, me gustaría hacer una mención especial al equipo timdel, que se une a cada jaleo sólo con proponerlo… ¿Quién es el equipo timdel? Pues dos referentes, magas e increíbles personas como son Sara Alonso y Mónica Mesa (con chistes incluidos). Sin ellas, esto hubiera sido casi impensable montarlo. ¡Gracias chicas!

Algunos pensaréis, Javi, llevabas tiempo sin publicar… es verdad, el motivo de llevar unas semanas desconectado es por una buena causa (la llegada al mundo de mi segunda hija Lucía). ¿Y que vengo a contaros hoy? Vengo con una de esas historias que empiezan con un “Equipo Timdel, que os parece si probamos si esto funciona” y terminan convirtiéndose en una pequeña aventura por varias capas del ecosistema Microsoft.

Y es exactamente lo que ocurre cuando queremos crear un agente en Microsoft Foundry, conectarlo con un Fabric Data Agent y terminar publicándolo en Microsoft Teams. Sobre el papel la idea parece la mar de sencilla:

Creo un agente, lo conecto a mis datos y lo publico en Teams.

Pero en la práctica, hay unas cuantas piezas que tienen que encajar:

Microsoft Fabric à Fabric Data Agent  à Microsoft Foundry Agent   à Azure Bot Service   à Microsoft Teams

Y cada una de esas piezas tiene su papel. Ninguna sobra, ninguna se puede saltar.

En este post os voy a contar el proceso completo, paso a paso, desde la creación del agente de datos en Fabric hasta su publicación final en Teams. Y os aviso ya: no es difícil, pero conviene entender qué hace cada capa para no volverse loco por el camino.

1. ¿Qué quería conseguir con todo esto?

El objetivo era crear un agente capaz de responder preguntas sobre un modelo de datos en Fabric. Es decir, algo de este estilo:

  • ¿Cuáles son las ventas por categoría?
  • ¿Qué clientes tienen mayor margen?
  • ¿Cómo han evolucionado las ventas por año?
  • ¿Cuál es el top 10 de productos?

Pero con una diferencia MUY importante: no quería que el agente respondiera “de memoria” ni con conocimiento general. Quería que respondiera consultando el modelo de datos real. Nada de inventarse cosas, nada de aproximaciones. Datos, datos y datos. Y ahí es donde entra en juego Fabric Data Agent.

Microsoft Fabric nos permite crear agentes de datos capaces de responder preguntas sobre datos almacenados en Fabric, incluyendo modelos semánticos de Power BI, Lakehouses, Warehouses y otros orígenes compatibles. Y lo bueno es que estos agentes se pueden conectar después con Microsoft Foundry para construir experiencias conversacionales sobre datos empresariales. Vamos, que las piezas ya están puestas encima de la mesa, sólo hay que saber montarlas.

2. Primera pieza: creamos el Fabric Data Agent

Lo primero que hay que tener claro es que el primer paso no está en Foundry. El primer paso está en Microsoft Fabric.

¿Por qué? Porque Foundry no se va a conectar directamente al modelo semántico. Foundry se va a conectar a un Fabric Data Agent, y será ese Data Agent quien se encargue de hablar con el modelo de datos.

La idea es esta:

Modelo semántico de Power BI  à Fabric Data Agent  à Agente de Foundry

Así que lo primero es crear el agente de datos en Fabric.

Paso 1. Entrar en el workspace de Fabric

Entramos en el workspace donde se encuentra el modelo semántico o el origen de datos que queremos consultar. En mi caso, el objetivo era trabajar sobre un modelo de datos ya preparado.

Y aquí quiero pararme un segundo, porque esto es importante: cuanto mejor preparado esté el modelo, mejores respuestas va a dar el agente. La IA no arregla un mal modelo. Si el modelo tiene nombres confusos, medidas duplicadas, tablas técnicas visibles, columnas mal nombradas o relaciones poco claras, el agente también va a sufrir esa confusión. Y créeme, se nota.

Que no os pase como en las películas de terror donde el protagonista abre la puerta que no debería… La IA con un modelo caótico es exactamente eso :).

Paso 2. Crear un nuevo Fabric Data Agent

Dentro del workspace hacemos:

Nuevo elemento → Agente de Datos

 

 

Y le damos un nombre claro. Por ejemplo:

Agente de Datos – Tenerife (sí, es el mismo que usamos para la demo de la TenerifeSummer)

 

La idea es que el nombre permita identificar de un vistazo qué modelo o área de negocio está cubriendo. Nada de nombres tipo “Agente1” o “Prueba_final_definitiva_esta_si”. Nombres que hablen por sí solos.

Y aquí veríamos la pantalla de creación del Fabric Data Agent desde el workspace de Fabric, con el formulario para asignarle nombre y descripción.

3. Conectar el Fabric Data Agent al modelo de datos

Una vez creado el Fabric Data Agent, toca decirle qué datos puede consultar. Aquí seleccionamos el origen. En este caso puede ser:

  • Modelo semántico de Power BI
  • Lakehouse
  • Warehouse
  • KQL Database

Para este escenario, el interés estaba en que el agente pudiera responder preguntas sobre un modelo de datos, por lo que seleccionamos el modelo semántico correspondiente, en este caso Demo Claude:

  

Y aquí Microsoft es muy claro: para usar un Fabric Data Agent desde Foundry, primero hay que crear y publicar el Data Agent en Fabric, y después conectar Foundry con ese agente mediante los identificadores del workspace y del artefacto. Es decir, no hay atajos. Primero Fabric, luego Foundry.

4. Preparar el agente de datos: no todo debe estar disponible

Este punto es CLAVE. Y me atrevería a decir que es donde muchos proyectos se caen sin saber por qué. Crear un agente no significa abrirle la puerta a todo el modelo. No conviene que el agente vea absolutamente todo. Conviene que vea aquello que necesita para responder bien.

Por ejemplo, en un modelo comercial puede tener sentido exponer:

  • DimDate
  • DimProduct
  • DimCustomer
  • DimStore
  • FactSales
  • Medidas principales

Pero quizá no tiene sentido exponer:

  • Tablas técnicas
  • Tablas auxiliares
  • Columnas de ordenación
  • Identificadores internos
  • Tablas de documentación
  • Tablas temporales
  • Columnas que no aportan significado de negocio

El objetivo es que el agente tenga un mapa limpio. Porque cuando el usuario pregunte:

¿Cuáles son las ventas por categoría?

el agente debe entender claramente qué es “ventas”, qué es “categoría” y dónde está la lógica correcta. No queremos que tenga que elegir entre veinte columnas parecidas. Queremos darle una autopista, no un laberinto. Y esa diferencia se nota MUCHO en la calidad de las respuestas.

5. Añadir instrucciones al Fabric Data Agent

Después de seleccionar el origen, añadimos instrucciones. Estas instrucciones sirven para guiar el comportamiento del agente dentro de Fabric.

Por ejemplo:

Eres un agente especializado en responder preguntas sobre el modelo comercial.

Usa siempre las medidas existentes antes de calcular importes manualmente.

Para preguntas de ventas, usa la medida [Ventas].

Para preguntas de margen, usa [Margen] o [Margen %].

Para preguntas temporales, utiliza la tabla DimDate.

Si no hay datos suficientes para responder, indícalo claramente.

No inventes datos.

No respondas preguntas fuera del ámbito del modelo.

Esto es importante porque no basta con conectar el modelo. También hay que explicarle al agente cómo queremos que lo interprete.

Es como darle acceso a una biblioteca. No sólo necesita entrar, también necesita saber qué libros consultar y cómo usarlos. Y aquí veríamos la pantalla de configuración de instrucciones del Fabric Data Agent, con el cuadro de texto donde vamos escribiendo todas estas indicaciones.

  

 

6. Probar el Fabric Data Agent en Fabric

Antes de ir a Foundry, hay que probar el agente en Fabric. Y esto no es opcional, es OBLIGATORIO. No tiene sentido conectar algo a Foundry si todavía no sabemos si funciona correctamente en origen.

Así que primero hacemos preguntas sencillas:

  • ¿Cuáles son las ventas totales?
  • ¿Cuáles son las ventas por año?
  • ¿Cuáles son los productos con mayor venta?

Después podemos ir complicándolo un poco:

  • Compara las ventas de este año frente al año anterior.
  • Dime el margen por categoría de producto.
  • ¿Qué clientes tienen mayor margen?

Aquí debemos comprobar dos cosas:

  1. Que el agente entiende la pregunta.
  2. Que la respuesta tiene sentido con el modelo.

  

 

Este paso es básico. Insisto, básico. Porque si el Fabric Data Agent ya responde mal dentro de Fabric, Foundry no lo va a mejorar mágicamente. Foundry no es un exorcista de datos, no viene a arreglar lo que no funciona antes. Si aquí no va, más arriba tampoco va.

7. Publicar el Fabric Data Agent

Una vez probado, hay que publicar el agente de datos. Esto es importante porque Foundry necesita conectarse a un Fabric Data Agent publicado. No a un borrador, no a algo a medio hacer. Para publicar el Fabric Data Agent basta con hacer clic sobre el botón de “Publicar”:

 

  

Y nos aparece la siguiente ventana en la que añadimos una descripción con los cambios aplicados en nuestro agente y le damos a Publicar:

  

 

Después de publicarlo, necesitamos recuperar dos valores de la URL:

  • workspace_id
  • artifact_id

La URL del agente tendrá una pinta parecida a esta:

https://fabric.microsoft.com/groups/<workspace_id>/aiskills/<artifact_id>

El workspace_id es el identificador que aparece después de /groups/.

Y el artifact_id es el identificador que aparece después de /aiskills/.

Si no lo cogemos por despiste, saber que lo podemos encontrar haciendo clic sobre “Más opciones” del agente (los 3 puntitos):

  

Y luego hacemos clic sobre “Configuración”:

  

Y en la ventana que se nos abre, hacemos clic sobre la opción de “Publicación” y ahí tenemos la información.

  

 

 

Microsoft lo documenta precisamente así: estos dos valores se copian desde la URL del Fabric Data Agent para crear la conexión desde Foundry. Ni más ni menos. Es un copia y pega, pero conviene tenerlos identificados a la primera para no ir buscándolos luego.

Y aquí veríamos la URL del Fabric Data Agent con los dos identificadores señalados, para que se vea con claridad qué parte es cada cosa.

8. Segunda pieza: creamos el agente en Microsoft Foundry

Con Fabric ya preparado, ahora sí, saltamos a Microsoft Foundry. Aquí creamos el agente que será la cara visible de la solución.

Porque atención a esto: el usuario no hablará directamente con el Fabric Data Agent. El usuario hablará con el agente de Foundry. Y el agente de Foundry hablará con Fabric por debajo.

La arquitectura mental sería esta:

Usuario à Agente de Foundry à Herramienta Microsoft Fabric à Fabric Data Agent à Modelo de datos

Entramos en Foundry, seleccionamos el proyecto y creamos un nuevo agente. Le damos un nombre claro. 

 

  

 

Por ejemplo: AgenteFabric

Lo importante, otra vez, es que el nombre diga lo que hace. Nada de acrónimos raros que dentro de tres meses no sepamos ni qué significan :)

Una vez creado, debemos seleccionar el modelo con el que queremos trabajar, para este caso, hemos elegido el gpt-4.1 (un modelo sencillo y económico), pero tenemos muchísimos más modelos:

  

 

9. Añadir instrucciones al agente de Foundry

Aquí hay otro punto importantísimo. El agente de Foundry necesita saber CUÁNDO debe usar Fabric. Porque si no se lo indicamos, puede intentar responder con conocimiento general. Y eso es justo lo que NO queremos.

Queremos que, cuando el usuario pregunte por datos, el agente consulte Fabric. Punto. No queremos que se ponga a improvisar respuestas sobre ventas basándose en “conocimiento del mundo” o cosas así.

Por tanto, añadimos instrucciones de este estilo:

Eres un agente especializado en análisis de datos empresariales.

Cuando el usuario pregunte por ventas, margen, clientes, productos, tiendas, evolución temporal, rankings o cualquier métrica del modelo comercial, debes usar la herramienta Microsoft Fabric.

No respondas preguntas de datos empresariales usando conocimiento general.

Si no hay datos suficientes para responder, indícalo claramente.

No inventes datos.

No inventes causas de negocio.

Este punto parece pequeño, pero es fundamental. La conexión le dice al agente dónde puede ir. Las instrucciones le dicen cuándo debe ir. Y sin las dos cosas, la cadena se rompe.

 

  

10. Crear la conexión con Microsoft Fabric en Foundry

Ahora tenemos que conectar Foundry con el Fabric Data Agent. En Foundry vamos a:

Herramientas → Conectar una herramienta → Agente de datos de Fabric → Agregar herramienta

  

 

 

 

 

Y aquí introducimos los dos valores que hemos obtenido antes:

  • workspace_id
  • artifact_id

Y guardamos la conexión.

  

Microsoft nos indica que la conexión de Fabric dentro del proyecto de Foundry apunta al Fabric Data Agent mediante esos identificadores, y que el identificador de la conexión tiene formato de recurso del proyecto Foundry. Es decir, no estamos apuntando a un objeto genérico, estamos apuntando a UN agente concreto en UN workspace concreto. Muy quirúrgico.

Y aquí veríamos la pantalla de Connected resources en Foundry con la conexión Microsoft Fabric ya creada.

  

 

11. Añadir la conexión al agente

Este paso puede parecer repetido, pero NO lo es. Que quede claro esto porque a mí me lió al principio.

Una cosa es crear la conexión en el proyecto. Otra cosa distinta es añadir esa conexión al agente. Es decir:

La conexión existe en Foundry pero no significa automáticamente que: El agente la está usando

Son dos cosas diferentes. Hay que ir al agente y añadir Microsoft Fabric como herramienta o fuente de conocimiento.

El flujo sería:

Agente → Seleccionamos el agente →Herramientas- Agregar – Examinar todas las herramientas → Agente de datos de Fabric → Seleccionar conexión existente

  

 

Nota, en la captura veis usado recientemente el agente de datos de Fabric, porque ya lo he usado, pero si no aparece, hay que seguir los pasos anteriormente comentados.

  

 

Una vez seleccionada, guardamos los cambios. Y aquí conviene crear o actualizar una versión del agente. Porque en la experiencia nueva de Foundry, lo que se publica no es una edición suelta del agente, sino una versión preparada del agente. Este matiz también es importante y luego lo veremos.

 

¡Continua en el siguiente post!