From insight to action: how Adobe and Microsoft are helping marketers move faster with AI
Today’s marketing leaders are under pressure to do more than ever—deliver meaningful personalization, accelerate execution, and prove measurable business impact. At the same time, teams are navigating increasing complexity: fragmented data, disconnected tools, and insights that arrive too late to act on. AI can change this—but only when it’s embedded directly into how people already work. That’s why Microsoft and Adobe are deepening our partnership: bringing customer experience intelligence, AI-powered workflows, and enterprise-grade AI directly into Microsoft 365 Copilot—so teams can move from insight to alignment to execution in one continuous workflow. The result is faster decisions, more coordinated execution, and clearer business outcomes—without breaking flow or context. Bringing customer experience intelligence into the flow of work Marketing teams don’t struggle because they lack data. They struggle because insights live in one place, collaboration in another, and execution somewhere else entirely. That disconnect slows teams down and creates unnecessary friction between analysis and action. Together, Adobe and Microsoft are changing that dynamic by connecting Adobe’s customer experience capabilities with Microsoft 365 Copilot and Copilot Cowork—so insight, collaboration, and next-best action can happen where work already happens: in Copilot Chat and in everyday apps like Teams, Word, and PowerPoint. Marketers can ask questions, explore insights, align with teammates, and take action without jumping between tools—turning intelligence into impact at the moment it matters. Adobe Marketing Agent for Microsoft 365 Copilot: now generally available A major milestone in this journey is the general availability of the Adobe Marketing Agent for Microsoft 365 Copilot, now available via Microsoft Commercial Marketplace. The Adobe Marketing Agent brings Adobe customer experience intelligence directly into Copilot, enabling marketing teams to: Accelerate time from insight to decision Move seamlessly from analysis to execution Keep humans firmly in control, with AI supporting—not replacing—decision‑making Importantly, the agent is enterprise-ready by design. IT administrators can deploy and manage the experience through the Microsoft 365 admin center, ensuring security, governance, and compliance at scale. Expanding executive experiences with Copilot Cowork Looking ahead, Adobe skills designed for customer experience orchestration will be accessible in Copilot Cowork—in a future release. This upcoming experience will enable customer experience leaders to engage with customer experience insights in a more direct, conversational way, bringing strategic visibility into the same Copilot environments where decisions are made and actions are coordinated. Built on Azure to scale securely and responsibly The technology foundation of this innovation is Azure. Adobe Experience Platform, Adobe Experience Platform Agent Orchestrator, and Adobe AI Agents are built on Azure and leverage Azure AI models, providing the scalability, security, and reliability enterprises require. By running on Azure, these agentic experiences benefit from Microsoft’s global infrastructure, enterprise‑grade security, and responsible AI commitments—supporting customer trust as organizations scale AI across their business. Designed for interoperability across agent ecosystems Modern enterprises don’t operate in a single ecosystem—and their agents shouldn’t either. Adobe agents are built to interoperate with agents created using Microsoft Azure AI Foundry or Copilot Studio, enabling customers to orchestrate richer, cross‑functional workflows across marketing, sales, service, and operations. This architecture is designed to enable organizations to compose agentic solutions that reflect how work actually happens—across systems, teams, and business processes. Moving from experimentation to execution This partnership reflects a broader shift in how organizations adopt AI—moving from experimentation to embedded, enterprise‑ready execution. By bringing the full power of Adobe Experience Platform together with Microsoft’s AI platform, cloud infrastructure, and Copilot experiences, we’re helping teams move faster with clarity, confidence, and control. This is how AI becomes not just powerful—but practical. Learn more Adobe + Microsoft partnership page Adobe Marketing Agent for Microsoft Copilot pageAzure Native Integrations: Public Preview of Napster Companion API on Azure
What is Napster Companion API? Napster Companion API is Napster's platform for building Omniagents: persistent, multi-channel AI agents with one identity, one memory, and one set of tools that show up across every channel an end user touches. The same Omniagent meets the customer on the website, in the mobile app, on video, and on the phone line with the same face, the same voice, and the same memory of the last conversation. The Omniagent as a digital worker The clearest way to think about an Omniagent is as a digital worker: It has a role (customer support specialist, sales advisor, internal IT assistant). It carries the memory of past shifts and prior conversations. It has the tools it needs to do the job which include APIs, knowledge bases, ticketing systems, CRMs. It shows up across every surface the end user touches, like a human worker who answers the door, the phone, and the inbox. When something is outside its scope, it hands off to a human colleague with the context already attached and picks the thread back up when the human is done. Use cases for the Companion API Teams are already exploring the Companion API across a wide range of scenarios: Agentic commerce. Agents that guide end users through discovery, recommendations, purchase, and post-sales support all in one continuous conversation across channels. Customer service. Agents that resolve issues end to end, escalate to humans with full context attached, and pick the thread back up across sessions. Internal operations and digital coworkers. Agents that orchestrate workflows, retrieve knowledge, and automate repetitive tasks for the workforce. Capabilities introduced by Napster Companion API The Companion API public preview brings the following capabilities to Azure customers: Persistent multi-channel agents that maintain identity, memory, and context across web, mobile, voice, video, and telephony. Real-time multimodal interactions across voice, video, and text for natural back-and-forth conversation. Tool and API orchestration that lets agents take real actions like opening tickets, updating records, retrieving documents, and triggering workflows. Persona-driven agents with configurable behavior, conversational style, and avatar-based interaction. Knowledge bases and deterministic question-and-answer pairs for grounded, accurate responses on topics where exactness matters. Developer SDKs and a no-code Dashboard for building, testing, deploying, and iterating on agents. Better together: Napster and Microsoft This integration is the result of a long-term Azure-native partnership between Napster and Microsoft. It is not an external service layered onto Azure infrastructure but it is a co-engineered offering designed to help enterprises operationalize persistent AI agents at scale. In practice, the Azure Native integration delivers: Benefit What it means for you Seamless development experience Provision and manage Companion API resources directly from the Azure portal, alongside your other Azure services. Build and operate Omniagents in the Napster Dashboard, reached through single sign-on. Bring your own model or use Napster Hosted Connect your Azure OpenAI realtime deployment on Microsoft Foundry so inference runs in your tenant. Or use the Napster Hosted tier where Napster manages the model for you. Simplified billing Manage Companion API spend through Azure Marketplace, on the same invoice as the rest of your Azure consumption which means no separate procurement, no separate billing relationship. Single sign-on with Microsoft Entra Switch between Azure resources and the Companion API Dashboard without re-entering credentials. Enterprise-ready foundation Built on Azure's compliance, security, and global infrastructure footprint. How it works?    If the player doesn’t load, open the video in a new window: Open video Get started in minutes Provisioning Napster Companion API on Azure takes just a few clicks: Open the Azure portal and search for *Napster Companion API*. Create a new resource and choose your subscription, resource group, region, and pricing tier. Link your Napster organization (or create one as part of resource provisioning). Launch the Companion API Dashboard from the resource overview page using single sign-on, and start building your first Omniagent in the Napster portal. Full step-by-step guidance is available in the Napster Companion API documentation on Microsoft Learn Resources Product documentation: Napster Companion API on Microsoft Learn Quickstart: Create a Napster Companion API resource Azure Marketplace listing: Napster Companion API Napster for partners: napster.com/partners Azure Native Integrations overview: Azure partner solutions What's next This public preview is the first milestone on a broader roadmap. We are eager to hear from early adopters. Try the public preview, build your first Omniagent, and let us know what you think as your feedback will shape what ships next. Get started today by searching for Napster Companion API in the Azure portal.The Cloud Foundation for Safe Agentic AI
Why enterprise agents need more than a working prototype Most AI conversations start with the model. Which model should we use? Which framework? Which agent platform? Which demo can we build quickly enough to make the idea feel real? Those questions are not wrong, but they are rarely the first questions that matter in an enterprise environment. In real projects, the hard part usually appears after the first prototype works. The demo can answer a question, call a tool, retrieve a document, or update a record. Then someone asks whether it can be connected to production data, used by more teams, or allowed to trigger real actions. That is where the conversation changes. In the first part of this series, I looked at why many companies are less ready for agentic AI than they think. The blockers were practical and familiar: unclear business problems, immature processes, weak data foundations, and no clear owner when an AI system makes a poor recommendation or takes a wrong action. The message was simple: Before a company asks what agents can do, it needs to understand what it is ready to delegate. But business readiness is only the first layer. Even when the use case is clear, the process is understood, and leadership is aligned, another question appears. Is the platform ready to support agents safely? This is where Part 2 begins. Agentic AI does not behave like a normal application workload. A traditional application usually follows predefined paths. It receives a request, processes logic, returns a response, writes to a database, or calls an API. Agents introduce a different pattern. They reason over context, retrieve information, choose tools, trigger actions, interact with other services, and sometimes operate across multiple systems at once. That makes the surrounding cloud platform much more important. There is also a shadow AI angle to this. In many organizations, agent-like capabilities are already entering through SaaS platforms, vendor copilots, browser extensions, and productivity tools. These systems may not run inside the organization’s governed Azure subscriptions, but they can still interact with enterprise data and business workflows. If the official platform is not ready, teams will often find less governed ways to experiment anyway. That is not always malicious. Sometimes it is just people trying to solve their work with the tools available to them. The marketing analyst pasting customer data into a public chatbot because the official AI platform is six months away. The support team using a browser extension that summarizes tickets, without anyone realizing those tickets are also being sent to a third-party service. From a governance point of view, the effect is the same. Cloud readiness for agentic AI is not defined by access to cloud services or model endpoints alone. The real question is whether the platform can support controlled autonomy. Before enterprises can trust agents to act, the platform must be able to identify them, observe their behavior, restrict their permissions, enforce policy, and contain failure. Without that, an organization is not really deploying an intelligent assistant in a controlled way. It is introducing a workload that can interact with enterprise systems without anyone clearly watching what it does or being able to stop it. From business readiness to cloud readiness After the business foundation is clear, the next layer is the cloud foundation. A company may have a strong use case, executive support, and even a working prototype. But that does not mean it is ready to deploy agents in production. A prototype can run with broad access, manual supervision, loose logging, and a small group of test users. Production requires more discipline. It requires clear identity, controlled access, traceable activity, enforceable policy, and operational ownership. Cloud readiness for agentic AI comes down to four pillars, in this order: Identity-first architecture Observability Policy controls Platform constraints The order matters. 1. Identity-first architecture Identity comes first because nothing can be governed properly if it cannot be identified. In traditional cloud systems, we already learned this lesson with users, applications, service principals, managed identities, and workloads. Agents add another layer of non-human actors into the enterprise environment. If an agent can retrieve data, call tools, trigger workflows, or interact with business systems, it needs a clear identity. Without that foundation, governance becomes fragile. Teams may struggle to control what the agent can access, understand what it did, or determine who is accountable when something goes wrong. I have seen agents running in production where nobody could clearly say who owned them. They worked. Until they did not. Identity-first architecture means each agent or agentic workload should have a defined identity, ownership model, permission scope, and lifecycle. It should be clear whether the agent is acting on behalf of a user, acting as a service, or operating within a delegated boundary. This matters because permissions are not an implementation detail. They define the blast radius and accountability model of the system. In Azure environments, this is where Microsoft Entra ID and newer agent identity capabilities become important. As agents become more common across Azure AI Foundry, Copilot Studio, Microsoft 365, and custom frameworks, organizations need a way to understand which agents exist, who owns them, what they can access, and how their lifecycle is managed. Identity is not only about authentication. It is also about visibility, traceability, ownership, permission boundaries, and accountability. Agents should not remain hidden inside application logic or operate through shared identities. If they can retrieve data, call tools, or trigger actions, they need to be managed with the same care as any other production workload. 2. Observability Once identity is established, observability becomes the next pillar. Knowing that an agent exists is not enough. The platform must be able to show what the agent did. For normal applications, observability often focuses on service health, latency, failures, and resource usage. For agents, those signals still matter, but they are incomplete. Agent observability also needs to capture the execution path across model calls, retrieved context, orchestration steps, tool calls, policy decisions, approvals, denials, and final actions. This changes how we think about monitoring. With agentic systems, the question is not only whether a request succeeded or failed. Teams also need to understand the path that led to the outcome, the context used, the tools called, the policies applied, and the point where behavior changed. Without that visibility, it is difficult to investigate failures and improve reliability. This is also where observability starts to support governance, not just troubleshooting. Once teams can measure how agents behave, they can move toward KPI-based governance. That may include reliability, escalation rates, policy denials, grounding quality, tool-call failures, cost per interaction, latency, and business outcome metrics. Without this measurement layer, maturity remains mostly opinion-based. With it, governance becomes evidence-based. In Azure, Azure Monitor is the obvious starting point. Together with services such as Application Insights and Log Analytics, it provides the telemetry foundation needed to understand how AI workloads behave in production. For agentic systems, this usually requires combining platform telemetry with application-level traces from orchestration, retrieval, model calls, policy decisions, and tool execution. This visibility is what makes continuous improvement possible. It is also what allows governance to mature from “we think the agent is behaving correctly” to “we can measure how the agent behaves over time.” Small difference. Large consequence. 3. Policy controls The third pillar is policy controls. This comes after identity and observability because policy needs both. Identity defines who or what the rule applies to. Observability helps teams understand whether the rule is effective, bypassed, misconfigured, or too restrictive. Policy controls define the boundaries for what agents are allowed to do. They determine how agents access data, which tools they can use, which environments are in scope, when approval is required, and when an action or response should be blocked. The key point is simple: Prompts can guide behavior, but they are not a reliable enforcement layer. For enterprise systems, policy needs to be external, testable, auditable, and enforceable. This becomes especially important because agents may operate across multiple systems. An agent may retrieve information from one source, reason over the result, call a tool, update a ticket, send a message, or trigger a workflow. Each step may appear safe in isolation, while the full chain creates risk. Policy controls provide boundaries around that chain. In Azure, this starts at the cloud governance layer. Azure landing zones, management group structures, and Azure Policy can help define where AI workloads are deployed, how environments are separated, and which rules apply consistently across subscriptions. At runtime, Azure AI Content Safety can help detect harmful content, prompt attacks, unsafe interactions, or outputs that drift away from the intended task. For tool and API access, Azure API Management can also be used as a controlled gateway between agents and downstream systems. This can support centralized authentication, throttling, mediation, logging, and policy enforcement. It is not mandatory in every design, but it is a useful option when agents need governed access to APIs instead of direct backend connectivity. The goal is not to create friction for the sake of control. The goal is to make sure the agent operates inside boundaries that are defined outside the prompt and outside the model response. 4. Platform constraints The fourth pillar is platform constraints. This area often receives less attention early in the project, but it strongly shapes whether an agentic system can operate safely and reliably in production. These constraints include network isolation, private connectivity, data residency, regional availability, quota limits, model throughput, latency, logging retention, integration boundaries, cost behavior, and operational ownership. They may seem like implementation details during early design discussions, but they often determine whether the system can actually run in production. For agentic workloads, these constraints also shape where experimentation happens. Sandboxed environments, isolated subscriptions, limited tool access, and controlled test data can help teams evaluate agent behavior before exposing it to production systems. This becomes even more important when agents are allowed to generate code, call external tools, or execute actions that may not be fully trusted at design time. Platform constraints are where the earlier pillars meet implementation reality. Identity affects how agents connect to services. Observability affects logging cost, retention, and investigation capability. Policy affects routing, network design, tool exposure, and user experience. By the time an agentic system reaches production, these constraints are no longer background details. They become design boundaries. In Azure, this is where landing zone design, private networking, regional planning, quota management, cost management, and operational runbooks matter. Azure landing zones, private endpoints, private DNS, Azure Firewall, NSGs, and controlled network paths all influence whether the agent architecture can move from prototype to production without being redesigned halfway through. And yes, that redesign usually happens at the least convenient moment. Architecture has a sense of humor. Not a kind one. From principles to Azure capabilities The four pillars are not only architectural principles. They need to be translated into platform capabilities, operating practices, and governance controls. In practice, controlled agent deployment is rarely achieved by a single product or service. It requires multiple layers working together. Identity, monitoring, policy, networking, runtime safety, API exposure, and operational controls all play a part. Azure provides several services and patterns that can help implement these controls, but there is no fixed blueprint that applies to every organization. The right combination depends on the use case, regulatory requirements, existing landing zone design, integration landscape, and the level of autonomy expected from the agent. The examples below should be seen as a practical toolset, not as a mandatory checklist. Pillar Goal Example Azure capabilities Identity-first architecture Make agents visible, owned, permissioned, and governable as enterprise workloads. Microsoft Entra ID, Microsoft Entra Agent ID, managed identities, service principals, workload identities, access reviews, Conditional Access, Privileged Identity Management Observability Understand runtime behavior, trace execution paths, investigate failures, and improve reliability. Azure Monitor, Application Insights, Log Analytics, Azure AI Foundry tracing, diagnostic settings, distributed tracing, correlation IDs, application-level telemetry Policy controls Enforce boundaries around access, actions, content safety, APIs, and governance. Azure landing zones, management groups, Azure Policy, Azure AI Content Safety, Prompt Shields, Microsoft Purview, Azure API Management, RBAC, approval flows Platform constraints Operate within real cloud boundaries such as networking, region, quota, compliance, and operations. Azure landing zones, private endpoints, private DNS, private networking, Azure Firewall, NSGs, quota planning, regional architecture, cost management The purpose of this mapping is not to suggest that Azure has one single service for each pillar. It does not. The practical goal is to combine the right services and patterns so the platform can identify agents, monitor their behavior, enforce boundaries, and operate within known cloud constraints. Conclusion Agentic AI does not become enterprise-ready simply because a model is available, a prototype works, or a business sponsor is excited. The real question is whether the surrounding cloud foundation can support agents that act within boundaries the platform actually enforces. Together, these pillars move the discussion from building an agent to preparing the environment in which the agent can operate responsibly. That distinction is important. A prototype can rely on broad access, limited logging, and close manual supervision. A production system needs clearer boundaries around ownership, access, traceability, and control. This is also where the series moves naturally into Part 3. Once the business foundation is clear and the cloud foundation is in place, the next challenge is the design of the agent itself. The cloud foundation matters here because it provides the controlled environment in which agents can be tested, limited, and observed before they are trusted with broader enterprise access. For more advanced scenarios, that also includes sandboxing patterns for generated code, tool execution, and untrusted actions. In Part 3, I will move closer to implementation and look at how to design an enterprise-ready agent. That means defining the agent’s scope, grounding it with reliable knowledge, deciding which tools it can use, designing safe execution loops, adding human oversight where it matters, and thinking carefully about when a single agent is enough versus when multi-agent coordination is justified. That is where agentic AI starts becoming more than an idea. And, as usual, that is also where the architecture starts to matter. This article is part of my Agentic AI readiness series and was also published on Medium.Agent Builder, Copilot Studio, or Azure AI Foundry: How We Decide for Every Client
Every client conversation starts the same way. Someone has seen a demo, attended an Ignite session, or read a press release. They want to build an agent. Then comes the question that derails more projects than any technical challenge: "Which tool should we use?" After deploying agents for clients across industries - insurance, professional services, manufacturing, public sector - we have developed a repeatable framework for answering that question. It is not based on which tool is newest or which has the best marketing. It is based on where projects actually succeed or fail in production. The three tools are not competitors The first mistake most teams make is treating Agent Builder, Copilot Studio, and Azure AI Foundry as a hierarchy - basic, intermediate, advanced. That framing leads to bad decisions. They are not a ladder. They are three distinct tools built for three distinct contexts. The right question is not "which tool is most powerful?" It is "which tool fits this project's constraints?" The framework: 4 questions We evaluate every project against four dimensions before recommending a tool: Who is building it? Where do users live? How complex is the logic? Who owns it after go-live? Agent Builder Copilot Studio Azure AI Foundry Builder profile Maker, no code Developer / power user Pro developer, Python User surface M365 Copilot Chat Teams, web, M365 Copilot Custom app, any surface Logic complexity Simple Q&A, task routing Multi-step flows, connectors Fully custom orchestration Post-go-live ownership Business team IT + Business joint Engineering team Governance M365 Admin Center Power Platform DLP Custom, Azure RBAC When we recommend Agent Builder Agent Builder is the right call when the business team wants to own the agent end-to-end, the use case is bounded, and the users already live inside M365 Copilot Chat. The key advantage is distribution - an Agent Builder agent surfaces natively inside Copilot Chat with zero additional deployment work. No IT ticket, no app registration, no Teams app package. The ceiling is real. Agent Builder does not support complex branching logic, external API calls, or dynamic prompt injection. The moment a client asks "can it also update a record in our CRM?" the answer is usually no. Use it when: The maker owns it, the use case is narrow, and M365 Copilot is already the user's primary surface. When we recommend Copilot Studio Copilot Studio is our default recommendation for the majority of enterprise agent projects. It covers the wide middle ground between no-code simplicity and full-code flexibility - within the Microsoft governance perimeter most enterprise IT teams already control. Power Platform connectors - 1,000+ out-of-the-box connectors means most enterprise data sources are reachable without custom API development M365 Copilot channel - surface a Copilot Studio agent directly inside M365 Copilot Chat, Agent Builder-level distribution with enterprise-grade logic underneath Topic-level governance - fallback behaviors, confidence thresholds, escalation paths configurable without code DLP policy enforcement - the agent operates within the same data loss prevention perimeter as the rest of the Power Platform tenant The most common mistake: under-investing in the knowledge layer. The agent authoring is the easy part. Getting SharePoint content structured, metadata consistent, and documents deduplicated is where most projects hit delays. Budget for it. Use it when: The use case requires connectors, dynamic responses, or M365 Copilot integration - and you want IT to own governance without requiring a developer team. When we recommend Azure AI Foundry Foundry is the right call when you need to bring your own model, build a fully custom orchestration pipeline, or integrate into a surface that has nothing to do with Microsoft 365. In practice, this means one of three scenarios: The client has a model fine-tuned on proprietary data that must be used The agent is embedded inside a custom-built web or mobile application The logic requires Python-level control - complex reasoning chains, multi-agent coordination, custom evaluation loops Foundry projects require a professional developer, take longer, and produce something the business team cannot maintain without engineering support. That is not a reason to avoid it - it is a reason to be honest with the client upfront. Use it when: You need full control of the model, the orchestration, or the surface - and you have a developer team to own it. The question that resolves most debates When a client is torn between Copilot Studio and Foundry, we ask one question: "Who is answering the 2am support call when this breaks in production?" If the answer is a developer, Foundry is viable. If the answer is the IT admin or the business owner, Copilot Studio is the right call. Not because Foundry is unreliable, but because the operational model has to match the tool. More projects fail from ownership mismatch than from technical limitations. What we see go wrong Reaching for Foundry too early. Developers often want full control and reach for Foundry before validating the use case. We have rebuilt several Foundry POCs in Copilot Studio when the production constraints called for it - faster to ship and cheaper to run. Under-scoping Agent Builder. Business teams choose Agent Builder because it looks simple, then hit the ceiling at month two. The re-platform cost is higher than building in Copilot Studio from the start. Ignoring the M365 Copilot channel. Many Copilot Studio projects are deployed as standalone Teams apps when they could surface directly inside M365 Copilot Chat. The distribution advantage is significant and underused. The short version Agent Builder - maker-owned, bounded use case, M365 Copilot surface, fast Copilot Studio - IT + business joint ownership, connectors, production governance, M365 Copilot integration Azure AI Foundry - developer-owned, custom model or surface, full control, higher cost Start with the ownership model. Everything else follows. Elliot Margot - Team Lead Jumpstart, Copilot and Agents at Witivio (Microsoft Partner). Connect on https://www.linkedin.com/in/elliot-margot-52742a156/.Three Tiers, One Platform: Building Agents Together with the Build-Along Series
The Agentic Opportunity Every partner has agent ambition, but a single workshop format cannot serve every builder. Business makers want a fast win without writing code. Citizen developers want to orchestrate real processes across enterprise systems. Pro developers want a code-first surface with evaluations, tracing, and managed identity. Run the wrong session for the wrong audience, and engagement collapses - too abstract for one group, too constrained for another. The Agent Build-Along Series solves that by meeting builders exactly where they are, across three tiers of the Microsoft platform stack. Behind the series sits a self-serve GitHub repository - a curated library of build-along sessions with easy-to-follow, step-by-step instructions, scoped to specific industry scenarios and business functions. Partners pick the scenario that fits the room, clone the assets, and run the session. No bespoke content build, no facilitator guesswork. A Self-Serve Repository for Build-Along Sessions Diagram illustrating three tiers of agent building The repo at Agent Build-Along Github is a self-serve catalog of ready-to-run workshops. Every session is curated for a specific industry and business function, with easy-to-follow instructions a facilitator can pick up and deliver. Pick the combination that matches the room and run the session - the content, scenario, and assets are already there. Sessions are organised across three axes so partners can find the right fit fast: Industry - Financial Services, Healthcare, Retail, Manufacturing, Public Sector, Energy, Professional Services Business function - Sales, Marketing, Finance, HR, Operations, IT, Customer Service Workload - Agent Builder, Copilot Studio and Azure AI Foundry Each session in the repo includes a real-world scenario, step-by-step build instructions, sample data, prompts and configuration, and a facilitator narrative. Clone, brief the room, build the agent - that is the loop. Three Tiers - Meet Builders Where They Are The pyramid is intentional. Builders start where their skills are today and move up as confidence grows. The tier defines platform, audience, duration, and approach - content stays consistent. Tier Platform Audience Duration Approach 1 - Foundation Microsoft 365 Copilot Agent Builder Business makers, end users, departmental teams 60 min No-code 2 - Extend Copilot Studio Citizen developers, power users, ops teams 90 min Low-code 3 - Pro-Code Azure AI Foundry Pro developers, architects, AI engineers 180+ min Code-first Tier 1 - M365 Copilot Agent Builder Author your first agent - no code required. Microsoft 365 Copilot Agent Builder virtual workshop overview, What your customers will build A custom agent scoped to a real workplace scenario Grounded with knowledge sources (SharePoint sites, files, web URLs) Configured with custom instructions and conversation starters Tested in the preview pane and shared with a team Session flow Define → Ground → Refine → Test & Share Prerequisites Microsoft 365 Copilot licence (or Copilot Chat free) Modern browser (Edge / Chrome) A workplace scenario in mind, or use our template Outcome Attendees leave with a working agent they can use immediately, plus a repeatable pattern for future use cases. This is the right entry point for departmental teams who want to operationalise Copilot without engineering involvement. Tier 2 - Copilot Studio Orchestrate multi-step agents across enterprise systems. Microsoft Copilot Studio virtual workshop overview What your customers will build A copilot with generative answers and authored topics Custom actions that call APIs and Power Platform connectors Knowledge sources spanning SharePoint, Dataverse, public web, and enterprise data Channel deployment to Microsoft Teams and a public web embed Session flow Design → Connect → Author → Publish Prerequisites M365 Copilot license with access to Copilot Studio Familiarity with Power Platform helpful, not required A multi-step workflow or process in mind Outcome Attendees leave with a published copilot running in Teams or on the web, plus a pattern for connecting copilots to enterprise systems. This is where citizen developers and ops teams turn manual processes into orchestrated, agent-driven workflows. Tier 3 - Azure AI Foundry Ship a code-first agent with evaluations and observability. What your customers will build A code-first agent with custom tools and function calling Grounding via Azure AI Search and the customer's own data Model selection from the Foundry catalog, with optional fine-tuning Evaluations, tracing, and managed-identity deployment Session flow Provision → Build → Evaluate → Deploy Prerequisites Azure subscription with Azure AI Foundry access VS Code, plus Python or .NET familiarity Sample data or a use case ready to ground on Outcome Attendees leave with a deployed agent - code, evaluations, and tracing in place - plus reusable SDK templates. This is the right tier for architects and AI engineers shipping agents into production with the governance bar enterprise customers expect. How the Repository Works The repo removes the heaviest lift in running these workshops: content creation. Every session is curated against the same three axes - industry, business function, tier - and shipped with step-by-step instructions a facilitator can follow with minimum prep. Industry/Business Function × Tier → Ready-to-run Build-Along Each session in the repo ships with: A real-world scenario grounded in the chosen industry and business function Step-by-step build instructions tuned to the selected tier Sample data the agent can ground against Prompts, conversation starters, and configuration snippets Facilitator narrative so anyone can run the session Need an enterprise agent that can handle integrate with CRM data? There is a curated Copilot Studio session with a deal-desk scenario and sample CRM data. Need a pro-code health care agent? Choose the Foundry session with a patient-flow scenario and a grounded dataset. Same repo, different curated paths - at the right depth for the room. What Attendees Walk Away With Agent-Builder - A working agent in Microsoft 365 Copilot, ready to share with colleagues. Copilot Studio - A published copilot running in Teams or on the web, connected to enterprise systems. Foundry - A deployed Foundry agent with evaluations, tracing, and SDK templates for the next build. In all cases attendees leave with assets - not slides - and the confidence to build the next one without facilitation. Next Steps - Host a Build-Along Pick your tier - Start where your skills are today. Move up the pyramid as confidence grows. Drive Registration – Socialise your Build-Along session to maximise attendance. Show up and build. Bring a real scenario. Customers leave with a working agent to share. Where to Next Browse the self-serve repository of Build-Along sessions - curated by industry and business function, with step-by-step instructions ready to run: Agent Build Along.Build and Deploy a Microsoft Foundry Hosted Agent: A Hands-On Workshop
Agents are easy to demo, hard to ship. Most teams can put together a convincing prototype quickly. The harder part starts afterwards: shaping deterministic tools, validating behaviour with tests, building a CI path, packaging for deployment, and proving the experience through a user-facing interface. That is where many promising projects slow down. This workshop helps you close that gap without unnecessary friction. You get a guided path from local run to deployment handoff, then complete the journey with a working chat UI that calls your deployed hosted agent through the project endpoint. What You Will Build This is a hands-on, end-to-end learning experience for building and deploying AI agents with Microsoft Foundry. The lab provides a guided and practical journey through hosted-agent development, including deterministic tool design, prompt-guided workflows, CI validation, deployment preparation, and UI integration. It’s designed to reduce setup friction with a ready-to-run experience. It is a prompt-based development lab using Copilot guidance and MCP-assisted workflow options during deployment. It’s a .NET 10 workshop that includes local development, Copilot-assisted coding, CI, secure deployment to Azure, and a working chat UI. A local hosted agent that responds on the responses contract Deterministic tool improvements in core logic with xUnit coverage A GitHub Actions CI workflow for restore, build, test, and container validation An Azure-ready deployment path using azd, ACR image publishing, and Foundry manifest apply A Blazor chat UI that calls openai/v1/responses with agent_reference A repeatable implementation shape that teams can adapt to real projects Who This Lab Is For AI developers and software engineers who prefer learning by building Motivated beginners who want a guided, step-by-step path Experienced developers who want a practical hosted-agent reference implementation Architects evaluating deployment shape, validation strategy, and operational readiness Technical decision-makers who need to see how demos become deployable systems Why Hosted Agents Hosted agents run your code in a managed environment. That matters because it reduces the amount of infrastructure plumbing you need to manage directly, while giving you a clearer path to secure, observable, team-friendly deployments. Prompt-only demos are still useful. They are quick, excellent for ideation, and often the right place to start. Hosted agents complement that approach when you need custom code, tool-backed logic, and a deployment process that can be repeated by a team. Think of this lab as the bridge: you keep the speed of prompt-based iteration, then layer in the real-world patterns needed to run reliably. What You Will Learn 1) Orchestration You will practise workflow-oriented reasoning through implementation-shape recommendations and multi-step readiness scenarios. The lab introduces orchestration concepts at a practical level, rather than as a dedicated orchestration framework deep dive. 2) Tool Integration You will connect deterministic tools and understand how tool calls fit into predictable execution paths. This is a core focus of the workshop and is backed by tests in the solution. 3) Retrieval Patterns (What This Lab Covers Today) This workshop does not include a full RAG implementation with embeddings and vector search. Instead, it focuses on deterministic local tools and hosted-agent response flow, giving you a strong foundation before adding retrieval infrastructure in a follow-on phase. 4) Observability You will see light observability foundations through OpenTelemetry usage in the host and practical verification during local and deployed checks. This is introductory coverage intended to support debugging and confidence building. 5) Responsible AI You will apply production-minded safety basics, including secure secret handling and review hygiene. A full Responsible AI policy and evaluation framework is not the primary goal of this workshop, but the workflow does encourage safe habits from the start. 6) Secure Deployment Path You will move from local implementation to Azure deployment with a secure, practical workflow: azd provisioning, ACR publishing, manifest deployment, hosted-agent start, status checks, and endpoint validation. The Learning Journey The overall flow is simple and memorable: clone, open, run, iterate, deploy, observe. clone -> open -> run -> iterate -> deploy -> observe You are not expected to memorize every command. The lab is structured to help you learn through small, meaningful wins that build confidence. Your First 15 Minutes: Quick Wins Open the repo and understand the lab structure in a few minutes Set project endpoint and model deployment environment variables Run the host locally and validate the responses endpoint Inspect the deterministic tools in WorkshopLab.Core Run tests and see how behaviour changes are verified Review the deployment path so local work maps to Azure steps Understand how the UI validates end-to-end behaviour after deployment Leave the first session with a working baseline and a clear next step That first checkpoint is important. Once you see a working loop on your own machine, the rest of the workshop becomes much easier to finish. Using Copilot and MCP in the Workflow This lab emphasises prompt-based development patterns that help you move faster while still learning the underlying architecture. You are not only writing code, you are learning to describe intent clearly, inspect generated output, and iterate with discipline. Copilot supports implementation and review in the coding labs. MCP appears as a practical deployment option for hosted-agent lifecycle actions, provided your tools are authenticated to the correct tenant and project context. Together, this creates a development rhythm that is especially useful for learning: Define intent with clear prompts Generate or adjust implementation details Validate behaviour through tests and UI checks Deploy and observe outcomes in Azure Refine based on evidence, not guesswork That same rhythm transfers well to real projects. Even if your production environment differs, the patterns from this workshop are adaptable. Production-Minded Tips As you complete the lab, keep a production mindset from day one: Reliability: keep deterministic logic small, testable, and explicit Security: Treat secrets, identity, and access boundaries as first-class concerns Observability: use telemetry and status checks to speed up debugging Governance: keep deployment steps explicit so teams can review and repeat them You do not need to solve everything in one pass. The goal is to build habits that make your agent projects safer and easier to evolve. Start Today: If you have been waiting for the right time to move from “interesting demo” to “practical implementation”, this is the moment. The workshop is structured for self-study, and the steps are designed to keep your momentum high. Start here: https://github.com/microsoft/Hosted_Agents_Workshop_Lab Want deeper documentation while you go? These official guides are great companions: Hosted agent quickstart Hosted agent deployment guide When you finish, share what you built. Post a screenshot or short write-up in a GitHub issue/discussion, on social, or in comments with one lesson learned. Your example can help the next developer get unstuck faster. Copy/Paste Progress Checklist [ ] Clone the workshop repo [ ] Complete local setup and run the agent [ ] Make one prompt-based behaviour change [ ] Validate with tests and chat UI [ ] Run CI checks [ ] Provision and deploy via Azure and Foundry workflow [ ] Review observability signals and refine [ ] Share what I built + one takeaway Common Questions How long does it take? Most developers can complete a meaningful pass in a few focused sessions of 60-75 mins. You can get the first local success quickly, then continue through deployment and refinement at your own pace. Do I need an Azure subscription? Yes, for provisioning and deployment steps. You can still begin local development and testing before completing all Azure activities. Is it beginner-friendly? Yes. The labs are written for beginners, run in sequence, and include expected outcomes for each stage. Can I adapt it beyond .NET? Yes. The implementation in this workshop is .NET 10, but the architecture and development patterns can be adapted to other stacks. What if I am evaluating for a team? This lab is a strong team evaluation asset because it demonstrates end-to-end flow: local dev, integration patterns, CI, secure deployment, and operational visibility. Closing This workshop gives you more than theory. It gives you a practical path from first local run to deployed hosted agent, backed by tests, CI, and a user-facing UI validation loop. If you want a build-first route into Microsoft Foundry hosted-agent development, this is an excellent place to start. Begin now: https://github.com/microsoft/Hosted_Agents_Workshop_LabAI Is the Headline — but Readiness Is the Real Story for MSPs
AI is everywhere right now. Customers are asking about Copilot. They’re curious about automation. They want faster, smarter ways to work. And on the surface, it all feels exciting—and urgent. But when you spend time with MSPs, a different story often emerges. Behind the AI curiosity are environments that aren’t quite ready. Devices are managed inconsistently. Identity hygiene varies by tenant. Security baselines drift over time. And for MSPs, holding all of this together manually—customer by customer—simply doesn’t scale. That gap between AI ambition and operational reality is becoming one of the most important conversations MSPs can have today. Why AI Success Still Comes Down to the Basics AI doesn’t fail because of a lack of innovation. It fails because the fundamentals aren’t in place. Without secure identities, compliant devices, and consistent policies, AI initiatives struggle to move beyond pilots—or worse, introduce new risk. That’s why so many Copilot conversations eventually circle back to the same question: Are we actually ready for this? This is where MSPs play a defining role. Not as AI hype merchants, but as partners who help customers build the foundation that makes AI practical, secure, and sustainable. At the center of that foundation sits Microsoft Intune. Microsoft Intune: Essential, but How Do You Scale? Microsoft Intune is already included in Microsoft 365 Business Premium. Many customers own it. Many MSPs support it. Yet adoption and consistency remain uneven. The challenge isn’t Intune itself—it’s the operational model. Managing Intune tenant by tenant, navigating multiple portals, and maintaining consistency across customers creates friction for MSPs. It’s time‑consuming, error‑prone, and difficult to turn into a repeatable service. And yet, Intune is critical. It’s the control plane for users, devices, access, and security—everything AI depends on to work safely at scale. Without Intune done right, AI readiness remains theoretical. Why the Partnership Matters: Microsoft Intune and AvePoint Elements This is why our partnership with Microsoft matters so much. Microsoft Intune provides the foundation. AvePoint Elements makes it scalable for MSPs. AvePoint Elements acts as the MSP operating layer on top of Intune—helping partners standardize, automate, and manage Intune across multiple customer tenants from a single platform. For MSPs, that translates into something very tangible: Less manual effort and portal hopping Consistent Intune baselines across customers Automated user and device lifecycle management Reduced drift, better efficiency, and healthier margins Instead of Intune being “work you absorb,” it becomes something you can package, repeat, and build a business around. From One‑Time Setup to Ongoing Value What we’re seeing with leading MSPs is a mindset shift. Intune is no longer treated as a one‑off deployment. It becomes a managed service—part of a broader story around security, governance, and AI readiness. That might mean standardized Intune onboarding, continuous device and identity hygiene, or positioning Copilot readiness as an ongoing engagement rather than a project. The outcome is powerful and familiar to MSPs who’ve made this transition before: Predictable recurring revenue Operational scale without linear headcount growth Stronger customer trust A clear path from security to AI enablement The Moment for MSPs Customers don’t just want access to AI. They want confidence that it’s being deployed responsibly. MSPs who can provide that confidence—by grounding AI adoption in strong Intune foundations—will stand out in the next phase of the market. That’s exactly what the partnership between Microsoft Intune and AvePoint Elements is designed to enable. A Note for MSP Partners If you’re an MSP thinking about how to: Scale Microsoft Intune delivery Reduce operational friction And turn AI readiness into a repeatable service This is a conversation worth leaning into now. Because in the age of AI, the partners who win won’t just deploy new tools—they’ll make them work in the real world. Join us for “From Copilot to Catalyst: How MSPs Turn AI Readiness Into Recurring Revenue” and explore how Microsoft Intune and AvePoint Elements work better together—helping you turn AI readiness into real, sustainable growth.Microsoft at NVIDIA GTC 2026: Powering the AI Ecosystem
This year, the Microsoft presence at GTC highlights a simple but powerful idea: AI transformation does not happen alone. It happens through ecosystems. Through a curated series of partner demonstrations and industry conversations, we will showcase how organizations are designing, building, and scaling AI solutions on Microsoft Azure accelerated by NVIDIA. The result is a connected story about how enterprise AI becomes production-ready and delivers measurable business value.Creating a Fun Multi-Agent Content Strategy System with Microsoft Agent Framework
This tutorial walks you through building a multi-agent content strategy system using Microsoft's AutoGen framework. Three specialised AI agents — a Content Creator, an Algorithm Simulator, and an Audience Persona — collaborate to help gaming content creators pressure-test their social media posts before publishing. Using live Google Trends data and platform-specific scoring rubrics for TikTok, Twitter/X, YouTube, and Instagram, the system generates content, predicts how each platform's algorithm would distribute it, and simulates authentic audience reactions. The tutorial covers core multi-agent patterns including role specialisation, structured evaluation, iterative feedback loops, and resilient tool integration — all running on GitHub Models' free tier.Microsoft Partners: Accelerate Your AI Journey at AgentCon 2026 (Free Community Event)
Recently, a customer asked me a question many Microsoft partners are hearing right now: “We have Copilot — how do we actually use AI to change the way we work?” That question captures where we are in the AI journey today. Organizations have moved past curiosity. Now they’re looking for trusted partners who can turn AI into real business outcomes. That’s why events like AgentCon 2026 matter. A free, community-led event built by practicioners AgentCon is not a traditional conference. It’s a free, community-driven global event organized by the Global AI Community together with Microsoft partners and ecosystem leaders. Simply put: it’s for the community, by the community. Across cities worldwide, developers, consultants, architects, and Microsoft partners come together to share practical experiences building with AI agents, Copilot, and the Microsoft platform. The focus isn’t theory — it’s implementation: What worked What didn’t What partners can apply immediately with customers This peer learning model reflects how many of us actually grow in the Microsoft ecosystem: by learning from other partners solving real problems. Why this matters for Microsoft partners The opportunity for partners is evolving quickly. Customers aren’t just asking about AI tools — they’re asking how to redesign processes, automate work, and unlock productivity using AI-powered solutions. The Microsoft AI Cloud Partner Program emphasizes partner skilling and helping customers realize value from AI investments. Community events like AgentCon accelerate that learning by bringing partners together to exchange proven approaches and practical insights. When partners upskill faster, customers succeed faster. Why attend AgentCon is designed to help partners move from AI awareness to AI delivery. As an attendee, you can expect: Practical sessions and demos from practitioners Real-world AI and agent scenarios Direct conversations with builders and peers New collaboration and co-sell opportunities You’ll leave with ideas and approaches you can bring directly into customer engagements. Why speak AgentCon thrives because partners share openly with one another. If you’ve implemented Copilot, explored AI agents, or learned lessons from customer deployments, your experience can help others accelerate their journey. Speaking at AgentCon allows you to: Share your expertise with the global partner community Build credibility within the Microsoft ecosystem Create new partnerships and opportunities Contribute to collective partner success You don’t need a perfect story — just an honest one others can learn from. Join the global AgentCon community AgentCon 2026 events takes place around the world including these upcoming events: March 9 - New York: https://aka.ms/AgentconNYC2026 April 11 - Hong Kong: https://aka.ms/AgentconHongKong2026 April 16 - Seoul: https://aka.ms/agentconLondon2026 April 22 - London: https://aka.ms/agentconSeoul2026 Each event is locally organized, community-led, and free to attend. Help shape the next phase of AI adoption AI transformation is happening now — and Microsoft partners play a critical role in guiding customers forward. AgentCon is an opportunity to learn together, share experiences, and strengthen the partner ecosystem driving AI innovation. 👉 Register or apply to speak: https://aka.ms/agentcon2026 We hope you’ll join us — and be part of the community helping customers turn AI potential into real impact.
