Don't miss your chance to take the Fabric Data Engineer (DP-700) exam on us!
Learn moreNext up in the FabCon + SQLCon recap series: The roadmap for Microsoft SQL and Maximizing Developer experiences in Fabric. All sessions are available on-demand after the live show. Register now
Hello Fabric Community,
I am participating in a Microsoft Dev AI Hackathon and building an AI-powered agricultural platform using Django, Microsoft Fabric, and Azure OpenAI.
I have a practical challenge and would appreciate guidance from the community:
• I have a custom ML model (trained using PyTorch / scikit-learn) that I trained locally using my PC’s external GPU.
• Microsoft Fabric Data Science notebooks have limited compute and cannot connect to my local GPU.
• Due to Azure student credit limits, I prefer not to retrain the model in Azure ML.
My current design approach:
• Use Microsoft Fabric for data analytics, Lakehouse, and notebooks
• Use Azure OpenAI (via Azure AI Foundry) for LLM-based reasoning
• Load and run my locally trained ML model inside the Django backend
• Expose the ML model as a callable function/tool for AI agents
• Build a multi-agent system (Intent Agent → Service Agent → Match Agent → Action Agent)
My questions:
1. Is this a recommended and acceptable architecture when Fabric compute is limited?
2. Is it common to keep ML model training external and integrate it via backend services while using Fabric for analytics?
3. Is designing tool-based agents that call Django ORM and ML models considered best practice in Fabric-based AI systems?
4. Are there any Fabric-native patterns or references for this hybrid setup?
My goal is to follow Microsoft-recommended architecture while staying within student credit limits.
Thanks in advance for your guidance.
Solved! Go to Solution.
Hi @Ravella_Vikhil ,
Thanks for reaching out to the Microsoft fabric community forum.
Architecture looks reasonable, especially when Fabric compute or student credits are limited. Microsoft guidance also shows that Fabric is often used for data analytics and storage, while ML models or agent orchestration can run in external services.
Architecture looks reasonable, especially when Fabric compute or student credits are limited. Microsoft guidance also shows that Fabric is often used for data analytics and storage, while ML models or agent orchestration can run in external services.
https://learn.microsoft.com/en-us/azure/architecture/ai-ml/
Also, in the Microsoft AI Decision Framework, Fabric data agents are mainly designed for analytics scenarios. When workflows require complex orchestration or multi-agent behavior, Microsoft recommends using external agent frameworks that call Fabric APIs instead of doing everything inside Fabric. Because of this, a hybrid design like yours Fabric for Lakehouse and analytics, Azure OpenAI for reasoning, and a backend service for ML inference aligns well with current Microsoft architecture patterns.
If I misunderstand your needs or you still have problems on it, please feel free to let us know.
Best Regards,
Community Support Team
Hello @v-menakakota ,
Thank you both for the clarification and for sharing the guidance.
Your explanation confirms that my proposed hybrid architecture aligns well with Microsoft-recommended patterns, especially when Microsoft Fabric compute or student credits are limited. Using Fabric primarily for Lakehouse storage and analytics, while running ML inference and agent orchestration in an external backend service, fits my use case well.
I also appreciate the insight around the Microsoft AI Decision Framework—that Fabric data agents are mainly optimized for analytics scenarios, and that more complex multi-agent orchestration is better handled using external agent frameworks that call Fabric APIs. This directly supports my approach of implementing tool-based agents that interact with Django services, ORM logic, and locally trained ML models, alongside Azure OpenAI for reasoning.
Thank you again, @v-menakakota , for the helpful direction and reference links. This guidance is very valuable for ensuring my hackathon project follows Microsoft best practices while remaining cost-effective.
Best regards,
Hi @Ravella_Vikhil ,
Thanks for reaching out to the Microsoft fabric community forum.
Architecture looks reasonable, especially when Fabric compute or student credits are limited. Microsoft guidance also shows that Fabric is often used for data analytics and storage, while ML models or agent orchestration can run in external services.
Architecture looks reasonable, especially when Fabric compute or student credits are limited. Microsoft guidance also shows that Fabric is often used for data analytics and storage, while ML models or agent orchestration can run in external services.
https://learn.microsoft.com/en-us/azure/architecture/ai-ml/
Also, in the Microsoft AI Decision Framework, Fabric data agents are mainly designed for analytics scenarios. When workflows require complex orchestration or multi-agent behavior, Microsoft recommends using external agent frameworks that call Fabric APIs instead of doing everything inside Fabric. Because of this, a hybrid design like yours Fabric for Lakehouse and analytics, Azure OpenAI for reasoning, and a backend service for ML inference aligns well with current Microsoft architecture patterns.
If I misunderstand your needs or you still have problems on it, please feel free to let us know.
Best Regards,
Community Support Team
Hello @v-menakakota ,
Thank you both for the clarification and for sharing the guidance.
Your explanation confirms that my proposed hybrid architecture aligns well with Microsoft-recommended patterns, especially when Microsoft Fabric compute or student credits are limited. Using Fabric primarily for Lakehouse storage and analytics, while running ML inference and agent orchestration in an external backend service, fits my use case well.
I also appreciate the insight around the Microsoft AI Decision Framework—that Fabric data agents are mainly optimized for analytics scenarios, and that more complex multi-agent orchestration is better handled using external agent frameworks that call Fabric APIs. This directly supports my approach of implementing tool-based agents that interact with Django services, ORM logic, and locally trained ML models, alongside Azure OpenAI for reasoning.
Thank you again, @v-menakakota , for the helpful direction and reference links. This guidance is very valuable for ensuring my hackathon project follows Microsoft best practices while remaining cost-effective.
Best regards,
Hi @Ravella_Vikhil ,
Thank you for the update.
Best Regards,
Community Support Team
Experience the highlights from FabCon & SQLCon, available live and on-demand starting April 14th.
If you have recently started exploring Fabric, we'd love to hear how it's going. Your feedback can help with product improvements.
Share feedback directly with Fabric product managers, participate in targeted research studies and influence the Fabric roadmap.
| User | Count |
|---|---|
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |