An Enterprise Design for Azure Machine Learning - An Architect's Viewpoint
This article provides an opinionated design for an enterprise-level data science capability, implemented within an Azure data platform. The guidance provides a starting point for the design of an ML platform that fits your business requirements.Azure OpenAI path to production – A case study with PowerBuddy
Join us on a transformative journey as PowerSchool revolutionizes the educational landscape with Azure OpenAI. Discover how generative AI is enhancing every facet of learning, from personalized content creation to sophisticated grading systems. Dive into PowerSchool's innovative approaches to integrating advanced AI models in K-12 education, and explore their strategic monitoring and scaling of AI applications. This is where the future of education takes shape – powered by AI and crafted by PowerSchool.Introducing Meta Llama 3 Models on Azure AI Model Catalog
Unveiling the next generation of Meta Llama models on Azure AI: Meta Llama 3 is here! With new capabilities, including improved reasoning and Azure AI Studio integrations, Microsoft and Meta are pushing the frontiers of innovation. Dive into enhanced contextual understanding, tokenizer efficiency and a diverse model ecosystem—ready for you to build and deploy generative AI models and applications across your organization. Explore Meta Llama 3 now through Azure AI Models as a Service and Azure AI Model Catalog, where next generation models scale with Azure's trusted, sustainable and AI-optimized high-performance infrastructure.Predict steel quality with Azure AutoML in manufacturing
This post will guide you through how we, Lotta Åhag and Gustav Kruse, used Azure AutoML and the 'Enterprise Scale ML (ESML) solution accelerator for Azure', to build an end-2-end machine learning solution in 6 weeks. The value of the solution is estimated to reduce 3.35 tons of Co2 emissions of propane and decrease electricity usage of 90MWh per year after putting the solution into production. The ecological impact is much higher less quality rejections will save a lot of resources including coal (and gas) needed to produce the steel. We collaborated with the Epiroc Data Scientist, Erik Rosendahl, who worked with the ESML templates for operation and governance. This is the story we want to share, about an end-2-end, machine learning solution on Azure. We wanted to leverage AI for steel manufacturing, in the area of heat treatment quality, with the goal to enhance the process to be able to reduce CO2. We got help from 2 student data scientists who wanted to execute this as their master thesis. In 6 weeks, they managed to leverage Azure Machine Learning and the ESML AI factory at Epiroc, using AutoML to build a machine learning model w an end-2-end pipeline from datalake to Power BI report. The team quickly got its own set of Azure resources as an ESML Project which ensured both enterprise grade scale and security – and out came a new AI innovation, with ecological wins - 3.35 ton C02 reduction and 30% less quality rejections. //Jonas Jern, Head of Digital Innovation, Epiroc Drilling Tools AB
Your Agents Need More Than a Place to Run
In architecture reviews with enterprise teams moving their first agentic applications toward production, I often hear the same plan: the team has containerized their agent and intends to run it on the managed Kubernetes cluster the organization already trusts. The reasoning is sensible, since the platform team knows the tooling and security has approved the network model, and for the first use case or two it is often the right call. Having watched this unfold in my years leading AgenticAI customer engineers and forward deployed engineers, and now helping customers reach production on Azure, I want to describe what happens next, before leaders commit rather than after. One thing to note is Azure supports multiple ways to build and operate agents. Foundry Agent Service provides an integrated managed runtime around your agent code. Azure Kubernetes Service supports teams that need Kubernetes-level control or want to extend an established platform, while Azure Container Apps provides managed container hosting. These services can work together. The decision is which capabilities and responsibilities best fit the workload. Where the cluster is the right answer A stateless retrieval application, a document extraction pipeline, or a classification job is a web service that happens to call a model, and a container platform runs web services well. A large retail customer of mine ran an invoice extraction agent on containers for over a year with almost no issues, and I never suggested they move it. The cluster remains the right home for several other situations as well. LLM invocations embedded inside existing microservices, event driven, or batch pipelines fit container platforms naturally. Genuine constraints such as air-gapped or sovereign environment, regions where a managed service is not yet offered are a good reason to run your own stack, and strong engineering team that already operates at that level can be a real asset. Even when the agents themselves move to a managed runtime, the tool servers, business APIs, and data services those agents call, often stay on your cluster, so they are complementary far more often than they are competitors. The problem is that these early wins can make agents seem like just another workload. Where the wheels come off The first failure is the state. A research agent that plans, searches, and synthesizes for ninety minutes is a long-running stateful process, while a Kubernetes pod is a disposable container the scheduler may restart at any time. A financial services team I worked with lost costly research run to a routine node upgrade, and responded as capable engineers do by building checkpointing, a durable store, and a resume mechanism. It worked, but they now owned a piece of infrastructure they had to keep correct as their agent's framework changed beneath it. A managed agent runtime absorbs this. Hosted agents in Foundry Agent Service, as one example, give every session a VM-isolated sandbox with a persistent file system, a durable state store that survives crashes and restarts and can hold checkpoints for frameworks such as LangGraph or Microsoft Agent Framework, and a resilient execution mode that recovers long-running work after a process interruption. The second is the human-in-the-loop. A commercial insurance customer’s claims agent needed sign-off from an adjuster and sometimes a second reviewer, with days between steps. Stopping an agent cleanly at the moment it needs a decision, holding its full session for four days without paying to keep it running, and resuming it correctly when the approval arrives is not something a container orchestrator gives out the box. The team built agent session suspend and resume, a queue, a durable state store, notifications, and an approval interface, and ended up with a small workflow engine nobody had planned to own. In hosted agents, an idle session is deprovisioned with its state persisted and restored onto fresh compute when the same session ID returns, so an agent waiting on an approval cost nothing while it waits, and sessions are retained for up to thirty days of inactivity. The approval experience remains yours to design, which is where your engineers' time should go. The third is multi-turn conversation, which quietly pushes teams into building their own context management system. The first version appends each turn to history, and within few turns the history outgrows the context window while cost and latency climb. So, the team adds truncation, then summarization, then retrieval of earlier turns, then per-user and per-tenant scoping, then expiry and deletion rules for privacy. An industrial customer's safety compliance assistant, with conversations stretching across days, followed exactly this path and ended up with a bespoke thread store and summarization pipeline nobody had budgeted for. Its first serious incident came when a summary silently dropped a compliance-relevant instruction. With the Responses protocol in hosted agents in Foundry, conversation history is a durable, platform-managed record keyed by a conversation ID and reachable from any channel, so the thread store is no longer yours to build, although deciding what to summarize or retrieve remains a design choice for your agent. The fourth is identity. On a cluster, the path of least resistance is a shared service account, and in one review a security architect asked which actions had been taken on behalf of which user, only to learn that the logs could not say. Hosted agents create a dedicated Microsoft Entra agent identity for each agent at deploy time, use on-behalf-of flows to act with the user's delegated permissions in interactive scenarios and the agent's own identity in autonomous ones, and keep the agent identifiable for audit in both cases. The fifth is per-user session isolation, which is the difference between an agent that serves many people and an agent that mixes them up. Agents read files, run code, and hold working data, and on a shared pod the default is that many users share a process, a file system, and often a cache. Giving every user session its own sandboxed environment and storage, so that one person's documents and intermediate results can never surface in another's, means engineering hard isolation boundaries and proving them to your security team. Hosted agents make a VM-isolated sandbox per session the default, and their durable state store can partition items per end user, so one store is safe to share across the users of a multitenant agent. And lastly, Evaluation and optimization are where the gap widens. The largest difference between teams that scale and those that stall is evaluation. Because agents are probabilistic and multi-step, staging tests often miss failures such as a wrong tool choice or a policy violation deep in a task. One customer’s agent passed every offline check but degraded unnoticed for weeks after a model update because evaluation stopped at release. Mature teams continuously evaluate production traces, combine automated judges with sampled human review, and red-team regularly.Once quality is measurable, teams can deliberately balance prompts, models, tools, latency, and cost. One team cut per-task cost by routing simple steps to smaller models after evaluation confirmed quality held. Self-built stacks require teams to assemble and maintain tracing, datasets, judges, and release gates. Hosted agents instead combines default OpenTelemetry traces with continuous evaluation, adversarial testing, and datasets generated from agent instructions. Staged closed-loop optimization uses those traces to improve instructions, tool descriptions, and model selection without extra plumbing. The real cost is the velocity gap Leaders usually expect me to quantify the initial build, and that is the smaller number. A team of four building the first agent often becomes ten or twelve within a year, and a growing share of them are maintaining a runtime for agents rather than building agents that serve the business. The enterprise has quietly created an internal agent infrastructure company in a field where the patterns for memory, tools, evaluation, and safety are rewritten every few months, while hyperscalers put hundreds of engineers on exactly this problem and ship at a cadence no single platform group can match. Foundry Agent Service, for instance, bundle content safety guardrails into the runtime and route outbound traffic through a customer virtual network, capabilities that platform teams otherwise assemble one integration at a time. This plumbing does not differentiate your organization, so the question is whether your scarcest engineers should spend years on it or on the workflows, data, and judgment only your company has. This is also why the technology companies held up as examples are a poor template. Many built their own runtimes because managed options did not yet exist and had large platform organizations to carry the load. Even they tend to invest in a custom runtime for the first handful of use cases and then migrate as managed services mature, because the maintenance burden compounds while the strategic value of owning the plumbing does not. What I would do as the leader I am not arguing against Kubernetes or for moving everything tomorrow. Comparable managed runtimes exist across the hyperscalers, and I use hosted agents as the running example only because it is the one I know best from the inside. Managed agent services are still maturing, some workloads have real data residency or customization needs, and abstraction always constrains something. What I am arguing for is a deliberate choice for each use case, guided by three questions: whether the agent must outlive a single request by running long, waiting on humans, or remembering across sessions whether it must act with its own identity, auditable delegation, and policy enforcement whether your team would be building anything a managed service already provides, and who will still maintain it in two years. Key takeaways Match the runtime to the workload. Containers on your existing cluster suit stateless, short-lived agents, while long-running, human-in-the-loop, and memory-dependent agents need capabilities your platform team was never hired to build. Count the hidden team. The real cost of self-hosting is the growing group of engineers maintaining state, identity, memory, guardrails, and tracing instead of solving business problems. Make evaluation continuous and connected to production traces. Pre-release testing alone will miss the drift and trajectory failures that hurt you, and optimization of quality, cost, and latency depends on that evaluation data. Follow the pattern of the leaders, not their early architecture. Companies that built custom runtimes did so before managed options matured, and most of them move toward managed services as those options improve. A practical place to begin is your roadmap for the next twelve months. Sort each use case into stateless and short-lived or long-running and human-dependent, and for every agent in the second group put a price on the engineers who would maintain the runtime rather than the business logic. I would like to hear how you have drawn this line, and where a managed service was not yet ready for something you needed.The Evolution of AI Frameworks: Understanding Microsoft's Latest Multi-Agent Systems
The landscape of artificial intelligence is undergoing a fundamental transformation in late 2024. Microsoft has unveiled three groundbreaking frameworks—AutoGen 0.4, Magentic-One, and TinyTroupe—that are revolutionizing how we approach AI development. Moving beyond single-model systems, these frameworks represent a shift toward collaborative AI, where multiple specialized agents work together to solve complex problems. Think of these frameworks as different but complementary systems, much like how a city needs infrastructure, service providers, and community organizations to function effectively. AutoGen 0.4 provides the robust foundation, Magentic-One orchestrates complex tasks through specialized agents, and TinyTroupe simulates human behavior for business insights. Together, they form a comprehensive ecosystem for building the next generation of intelligent systems. As we explore each framework in detail, we'll see how this coordinated approach is opening new possibilities in AI development, from enterprise-scale applications to sophisticated business simulations. Framework Comparison: A Deep Dive Before we explore each framework in detail, let's understand how they compare across key dimensions. These comparisons will help us understand where each framework excels and how they complement each other. Core Capabilities and Design Focus Aspect AutoGen 0.4 Magentic-One TinyTroupe Primary Architecture Layered & Event-driven Orchestrator-based Persona-based Core Strength Infrastructure & Scalability Task Orchestration Human Simulation Development Stage Beta Preview Early Release Target Users Enterprise Developers Automation Teams Business Analysts Key Innovation Cross-language Support Dual-loop Orchestration Persona Modeling Deployment Model Cloud/On-premise Container-based Local Main Use Case Enterprise Systems Task Automation Business Insights AutoGen 0.4: The Digital Infrastructure Builder Imagine building a modern city. Before any services can operate, you need robust infrastructure – roads, power grids, water systems, and communication networks. AutoGen 0.4 serves a similar foundational role in the AI ecosystem. It provides the essential infrastructure that allows Agentic systems to operate at enterprise scale. The framework's brilliance lies in its three-layer architecture: The Core Layer acts as the fundamental infrastructure, handling basic communication and resource management, much like a city's utility systems. The AgentChat Layer provides high-level interaction capabilities, similar to how city services interface with residents. The Extensions Layer enables specialized functionalities, comparable to how cities can add new services based on specific needs. What truly sets AutoGen 0.4 apart is its understanding of real-world enterprise needs. Modern organizations rarely operate with a single technology stack – they might use Python for data science, .NET for backend services, and other languages for specific needs. AutoGen 0.4 embraces this reality through its multi-language support, ensuring different components can communicate effectively while maintaining strict type safety to prevent errors. from autogen_agentchat.agents import AssistantAgent from autogen_agentchat.task import Console from autogen_ext.models import OpenAIChatCompletionClient async def enterprise_example(): # Create an enterprise agent with specific configuration agent = AssistantAgent( name="enterprise_system", model_client=OpenAIChatCompletionClient( model="gpt-4o-2024-08-06", api_key="YOUR_API_KEY" ) ) # Define a complex enterprise task task = { "objective": "Analyze sales data and generate insights", "data_source": "sales_database", "output_format": "report" } # Execute task with streaming output stream = agent.run_stream(task=task) await Console(stream) # Example usage: # asyncio.run(enterprise_example()) Magentic-One: The Master Orchestra Conductor If AutoGen 0.4 builds the city's infrastructure, Magentic-One acts as its management system. Think of it as a highly skilled orchestra conductor, coordinating various musicians (specialized agents) to create a harmonious performance (completed tasks). The framework's innovative dual-loop architecture demonstrates this orchestration: The Task Ledger works like a conductor's score, planning out what needs to be done. The Progress Ledger functions as the conductor's real-time monitoring, ensuring each section performs its part correctly. Magentic-One's specialized agents exemplify this orchestra metaphor: WebSurfer: Like the string section, handling intricate web interactions FileSurfer: Similar to the percussion section, managing rhythmic file operations Coder: Comparable to the brass section, producing powerful code outputs ComputerTerminal: Like the woodwinds, executing precise commands This specialization has proven its worth through impressive benchmark performances across GAIA, AssistantBench, and WebArena, showing that specialized expertise, when properly coordinated, produces superior results. from magentic_one import ( Orchestrator, WebSurfer, FileSurfer, Coder, ComputerTerminal ) def automation_example(): # Initialize specialized agents agents = { 'web': WebSurfer(), 'file': FileSurfer(), 'code': Coder(), 'terminal': ComputerTerminal() } # Create orchestrator with task and progress ledgers orchestrator = Orchestrator(agents) # Define complex automation task task = { "type": "web_automation", "steps": [ {"action": "browse", "url": "example.com"}, {"action": "extract", "data": "pricing_info"}, {"action": "save", "format": "csv"} ] } # Execute orchestrated task result = orchestrator.execute_task(task) return result # Example usage: # result = automation_example() TinyTroupe: The Social Behavior Laboratory TinyTroupe takes a fundamentally different approach, more akin to a sophisticated social simulation laboratory than a traditional AI framework. Instead of focusing on task completion, it seeks to understand and replicate human behavior, much like how social scientists study human interactions and decision-making. The framework creates detailed artificial personas (TinyPersons) with rich backgrounds, personalities, and behaviors. Think of it as creating a miniature society where researchers can observe how different personality types interact with products, services, or each other. These personas exist within controlled environments (TinyWorlds), allowing for systematic observation and analysis. Consider a real-world parallel: When automotive companies design new vehicles, they often create detailed driver personas to understand different user needs. TinyTroupe automates and scales this approach, allowing businesses to simulate thousands of interactions with different personality types, providing insights that would be impractical or impossible to gather through traditional focus groups. The beauty of TinyTroupe lies in its ability to capture the nuances of human behavior. Just as no two people are exactly alike, each TinyPerson brings its unique perspective, shaped by its programmed background, experiences, and preferences. This diversity enables more realistic and valuable insights for business decision-making. from tinytroupe import TinyPerson, TinyWorld, TinyPersonFactory from tinytroupe.utils import ResultsExtractor def simulation_example(): # Create simulation environment world = TinyWorld("E-commerce Platform") # Generate diverse personas factory = TinyPersonFactory() personas = [ factory.generate_person( "Create a tech-savvy professional who values efficiency" ), factory.generate_person( "Create a budget-conscious parent who prioritizes safety" ), factory.generate_person( "Create a senior citizen who prefers simplicity" ) ] # Add personas to simulation world for persona in personas: world.add_person(persona) # Define simulation scenario scenario = { "type": "product_evaluation", "product": "Smart Home Device", "interaction_points": ["discovery", "purchase", "setup"] } # Run simulation and extract insights results = world.run_simulation(scenario) insights = ResultsExtractor().analyze(results) return insights # Example usage: # insights = simulation_example() Framework Selection Guide To help you make an informed decision, here's a comprehensive selection matrix based on specific needs: Need Best Choice Reason Alternative Enterprise Scale AutoGen 0.4 Built for distributed systems Magentic-One Task Automation Magentic-One Specialized agents AutoGen 0.4 User Research TinyTroupe Persona simulation None High Performance AutoGen 0.4 Optimized architecture Magentic-One Quick Deployment TinyTroupe Minimal setup Magentic-One Complex Workflows Magentic-One Strong orchestration AutoGen 0.4 Practical Implications For organizations looking to implement these frameworks, consider the following guidance: For Enterprise Applications: Use AutoGen 0.4 as your foundation. Its robust infrastructure and cross-language support make it ideal for building scalable, production-ready systems. For Complex Automation: Implement Magentic-One for tasks requiring sophisticated orchestration. Its specialized agents and safety features make it perfect for automated workflows. For Business Intelligence: Deploy TinyTroupe for market research and user behavior analysis. Its unique simulation capabilities provide valuable insights for business decision-making. Conclusion Microsoft's three-pronged approach to multi-agent AI systems represents a significant leap forward in artificial intelligence. By addressing different aspects of the AI development landscape – infrastructure (AutoGen 0.4), task execution (Magentic-One), and human simulation (TinyTroupe) – these frameworks provide a comprehensive toolkit for building the next generation of AI applications. As these frameworks continue to evolve, we can expect to see even more sophisticated capabilities and tighter integration between them. Organizations that understand and leverage the strengths of each framework will be well-positioned to build powerful, scalable, and intelligent systems that drive real business value. Appendix Technical Implementation Details Feature AutoGen 0.4 Magentic-One TinyTroupe Language Support Python, .NET Python Python State Management Distributed Centralized Environment-based Message Passing Async Event-driven Task-based Simulation-based Error Handling Comprehensive Task-specific Simulation-bound Monitoring Enterprise-grade Task-focused Analysis-oriented Extensibility High Medium Framework-bound Performance and Scalability Metrics Metric AutoGen 0.4 Magentic-One TinyTroupe Response Time Milliseconds Seconds Variable Concurrent Users Thousands Hundreds Dozens Resource Usage Optimized Task-dependent Simulation-dependent Horizontal Scaling Yes Limited No State Persistence Distributed Cache Container Storage Local Files Recovery Capabilities Advanced Basic Manual Security and Safety Features Security Aspect AutoGen 0.4 Magentic-One TinyTroupe Access Control Role-based Container-based Environment-based Content Filtering Enterprise-grade Active Monitoring Simulation Bounds Audit Logging Comprehensive Action-based Simulation Logs Isolation Level Service Container Process Risk Assessment Dynamic Pre-execution Scenario-based Recovery Options Automated Semi-automated Manual Integration and Ecosystem Support Integration Type AutoGen 0.4 Magentic-One TinyTroupe API Support REST, gRPC REST Python API External Services Extensive Web-focused Limited Database Support Multiple Basic Simulation Only Cloud Services Full Support Container Services Local Only Custom Extensions Yes Limited Framework-bound Third-party Tools Wide Support Moderate MinimalFundamental of Deploying Large Language Model Inference
"Deploying Large Language Models: Tips & Tricks" explores the complexities of hosting large language models, including challenges such as model size, sharding, and computational resources. The blog offers insights into the technical expertise, infrastructure setup, and significant investment required. It delves into the intricacies of model serving, inference workflows, and the careful planning needed to manage the high volume of requests and data. The post provides valuable tips and tricks for effectively navigating these challenges, making it essential reading for anyone interested in understanding the intricacies of hosting large language models and the associated costs.
