From co-sell ready to closed-won: A practical playbook for your Microsoft co-sell motion
Achieving co-sell ready status is an important milestone. It means the offer is on Microsoft Marketplace, Partner Center is set up, sales collateral and contacts are on file, and the solution is exposed to Microsoft sales teams for co-sell opportunities. None of that, on its own, brings deals into the pipeline or moves them to closed-won. The operational work between status activation and revenue includes: Getting a Microsoft seller's attention for a specific opportunity, or making it easier for a seller to bring one in Engaging the Microsoft seller as soon as a co-sell opportunity is created or received Running joint discovery and technical validation with the customer Structuring the private offer at the right point in the deal cycle Closing through Microsoft Marketplace where a customer's Microsoft Azure Consumption Commitment (MACC) is in play Two common paths into the co-sell motion Deals reach Partner Center through two common paths once the solution achieves co-sell ready status. The early operating approach is different for each. The middle and close of the deal look similar. Partner-led co-sell: The software company originates and manages the opportunity from its own pipeline, creates the co-sell opportunity in Partner Center, and makes the deal visible to Microsoft sales teams. Microsoft sellers can be invited to participate when appropriate. Inbound referrals from Microsoft: A Microsoft seller identifies a fit in one of their accounts and sends the referral to the software company through Partner Center's Inbound tab. The main differences show up early on: Stage Partner-led Inbound from Microsoft Discovery Software company has already qualified the opportunity Software company gets up to speed on Microsoft’s account context Initial priority Give the Microsoft seller a clear reason to engage Qualify the referral and respond quickly Keep momentum Bring a qualified opportunity with a specific ask Confirm fit, ownership, and next steps Keeping deals moving after co-sell ready A few operational practices help turn co-sell ready status into an active, repeatable sales motion: Activate the co-sell motion consistently: Co-sell ready creates access to the motion, but momentum comes from actively engaging sellers, keeping positioning current, and continuously creating and responding to co-sell opportunities. Keep every registered opportunity moving: Clear ownership, visible next steps, and regular follow-through help move opportunities beyond the initial seller connection. Platforms such as SaaSify can help software companies manage co-sell opportunity information, ownership, and next actions. Prepare the private offer early: Bringing marketplace offer preparation into the deal cycle earlier gives teams enough time to align pricing, approvals, terms, and customer requirements before the opportunity reaches procurement. Align ownership across the deal: Giving account executives and partner teams shared visibility into customer conversations, Partner Development Manager (PDM) engagement, and next steps helps both sides coordinate around the same opportunity and move the deal forward. Positioning co-sell opportunities with Microsoft The approach is different for the two flows. Partner-led opportunities need the software company to position a specific deal for the Microsoft seller. Inbound referrals need preparation ahead of time and disciplined handling once a referral arrives. For partner-led opportunities A few practices can make a partner-led opportunity easier for Microsoft sellers to engage with. Map the opportunity to relevant Microsoft solution areas and sales plays: Microsoft's solution areas and sales plays change. Positioning the offer against the most relevant current areas helps make the opportunity easier for the seller to understand and position. Bring warm, qualified opportunities: An opportunity handed to a Microsoft seller with a defined buying committee, a known budget, and clear technical fit invites investment. An opportunity that still needs basic discovery asks the seller to do the software company’s qualification work. Make a specific, actionable request: "Please introduce us to the account executive at [customer]" with a clear deadline is a clear request. Generic invitations to collaborate on joint pipeline typically remain unactioned. Provide collateral written for the seller, not the buyer: Seller-facing collateral should make the elevator pitch, workload alignment, Marketplace path, and relevant commercial context immediately clear. For inbound referrals from Microsoft Being effective on inbound referrals means being easy for Microsoft teams to consider in the first place and handling each referral effectively when it arrives. A complete, current business profile in Partner Center: Keep the software company’s Partner Center information complete and current including solution categorization, industry expertise, customer proof points, relevant Azure workloads and sales plays. Qualify inbound referrals quickly, before mobilizing the full team: Not every inbound referral is a fit. Some fall outside the software company’s target profile, workload, or timing. A fast qualification step, handled by a named account owner before wider team mobilization, protects response quality on the referrals that do fit and directs the team's effort where it can contribute. A transactable Marketplace presence: A transactable offer gives customers a clear procurement path through Microsoft Marketplace and can support MACC-aligned purchasing. Active relationships with PDMs and specialist teams: Being known to Microsoft's PDMs, industry teams, and technical specialists creates additional pathways for the software company to be considered when the right opportunity appears. Running the co-sell opportunity through active pipeline Once a Microsoft seller is engaged, the middle of the deal is joint sales work. The joint pieces below are the ones that most consistently move the deal forward. Joint account planning at the start: Early in active pipeline, the software company and the Microsoft seller should align on the stakeholder map, Microsoft's context on the account (existing Azure spend, MACC status, previous partner engagements), the software company’s view of the opportunity, the commercial path, and named next steps with owners and dates. Aligning at the outset helps prevent a co-sell opportunity from going quiet in its early stages. Joint technical validation: For Azure workload solutions, the software company should bring a Microsoft solution architect or specialist into the architecture conversation with the customer. Microsoft technical specialists can add Azure platform context, address architecture questions, and help the customer evaluate fit across its broader Microsoft environment. Joint customer meetings with clear role definition: In a co-sell customer meeting, the software company leads on solution, use case, and business value. The Microsoft seller leads on Azure context, commercial path, and alignment with the customer’s Microsoft environment. Roles should be agreed before the meeting. Technical and commercial workstreams in parallel: Technical objections need Microsoft's specialist teams and the software company’s engineering. Commercial objections need finance on both sides and clarity on the marketplace path. Sequencing these badly, by completing all technical work before starting commercial, is where the private offer scramble at close typically originates. Underneath the joint work, three lightweight disciplines keep the deal visible and moving: Keep the Partner Center record current. Update it after stage changes, close-date shifts, competitive events, or stakeholder changes. Share regular updates with the Microsoft seller. Keep them short and focused on what changed and what is needed next. Use the PDM deliberately for escalations. Bring them in when their role or internal network can help move the opportunity forward. Advancing and closing deals through Microsoft Marketplace For customers with an active MACC, purchases of MACC-eligible offers through Microsoft Marketplace can contribute toward fulfillment of that commitment. Azure IP co-sell eligibility is a prerequisite for MACC eligibility, and MACC eligibility is determined at the offer level. A common operational issue is being unprepared to close on Marketplace when the customer is ready to buy. Being commercially ready in time means: A Marketplace listing that is fully transactable, with billing enabled. A private offer template with pre-approved pricing tiers, term options, and standard legal language. A sales team that can generate a customer-specific private offer without escalating each one to operations or finance. Finance visibility into pending marketplace transactions ahead of quarter close. Moving the private offer conversation into the discovery phase of the deal removes the closing-week scramble and keeps the deal moving smoothly toward close. Running co-sell at scale A handful of co-sell deals can be worked well through individual attention. Once co-sell becomes a meaningful percentage of pipeline, operational consistency becomes more important as volume grows: Deal data drifts between Partner Center, the software company’s customer relationship management (CRM) system, and internal reporting. Private offer creation often remains a deal-by-deal manual workflow, increasing operational effort as co-sell volume grows. No single view exists of where each co-sell deal stands across systems, whether it started partner-led or arrived as an inbound referral. A purpose-built cloud go-to-market platform can help software companies manage the operational side of selling across cloud marketplaces. SaaSify, for instance, helps software companies manage co-sell workflows and marketplace operations across Microsoft Marketplace and other hyperscaler ecosystems. Platforms of this kind help in multiple practical ways: Supporting co-sell workflows within the CRM and helping to keep deal information aligned between Partner Center and the software company’s CRM. Automating private offer creation and management within the software company’s CRM, helping reduce the manual effort required to create and manage private offers. Providing workflow visibility across marketplace transactions, private offer approvals, and payout reconciliation. Reducing operational load on the sales and partnership teams so senior time goes to seller relationships and deal strategy. A 90-day framework to move from co-sell ready to closed-won deals Days 1–30: Audit Review the current state honestly against a short set of questions covering both flows: Are co-sell opportunities updated in Partner Center consistently across the team? What is the response time to inbound referrals from Microsoft, from receipt to named account owner to first customer conversation? Is the Partner Center business profile complete, current, and mapped to relevant Microsoft solution areas and sales plays? Is the offer fully transactable on Microsoft Marketplace, or listed but not yet transactable? Are private offer workflows documented and templated, or reinvented for each deal? The output should be a short list of specific gaps, each with a named owner. Days 31–60: Activate For partner-led opportunities: engage the Microsoft sellers who cover the accounts and industries where the solution is strongest, and standardize the activation ask so every co-sell opportunity comes with a specific next step and date. For inbound referrals: implement an internal SLA for qualification and response and refresh the Partner Center business profile against relevant Microsoft solution areas and sales plays. Identify pipeline opportunities where Microsoft Marketplace can support the co-sell and commercial motion and structure the private offers early in the deal cycle. Days 61–90: Measure Track conversion at each stage, split by partner-led versus inbound origin: co-sell ready to opportunity created or received, to active pipeline, to Marketplace transaction, to closed-won. Refine private offer workflows based on identified bottlenecks. Run a postmortem on one deal that closed cleanly and one that required several interventions. Measuring co-sell performance Five indicators provide a practical view of whether the co-sell motion is producing pipeline and converting opportunities into revenue: Inbound referral volume and value from Microsoft: Track referral volume, potential value, and progression to active pipeline and closed-won. Response time to first customer conversation: Track time from opportunity creation or receipt to the first substantive customer interaction. Co-sell opportunity-to-closed-won conversion: Measure conversion by stage and separately for partner-led and inbound opportunities. Share of enterprise deals closing through Microsoft Marketplace: Track the percentage and value of co-sell deals transacted through Marketplace when it aligns with customers’ purchasing needs. Private offer creation and approval cycle time: Track request-to-acceptance time to assess whether private offer operations are keeping pace with co-sell volume. Supporting metric: Partner Center data completeness and consistency. Bringing it together Microsoft co-sell gives software companies opportunities to expand their reach and work jointly with Microsoft sellers on relevant customer opportunities, with Microsoft Marketplace supporting the commercial path when it aligns to the customer’s purchasing needs. Making that motion work consistently comes down to practical disciplines: keeping Partner Center data current, responding promptly to inbound referrals, and preparing private offer workflows early. The value builds when those practices work together consistently across opportunities.Microsoft Marketplace Partner Digest
What's new in Marketplace Convert more buyers into customers Microsoft recently expanded Marketplace listing capabilities with enhancements to free trials and the introduction of an option to request private offers, giving partners more ways to engage buyers at different stages of the purchasing journey. Customers can now discover and evaluate solutions through expanded trial experiences and transition more easily into paid subscription discussions by requesting custom pricing and terms directly from your Marketplace listings. ✨ Help customers evaluate your solution with free trials What's new On July 23 we announced the release of Marketplace enhanced trial capabilities. Customers can try solutions with confidence with the free trials in Microsoft Marketplace. Trials are available for multiple offer types, including SaaS, Azure virtual machines, Dynamics 365, and Power BI offers. New capabilities include: Custom meter trials: Partners can configure trials for SaaS solutions with metered pricing. Flexible trial durations: Partners can now configure SaaS trial durations from 1 to 180 days. Partner analytics: Partners can access SaaS trial analytics - including free trials initiated, active free trials, free trials converted, free trials not converted, and average trial duration - all within Partner Center Insights workspace. Customer discovery and management: Customers can better discover and manage trials. Upgrade to paid subscription during trial: Customers can upgrade to paid subscription at public pricing any time during a SaaS trial. Why it matters With enhanced trial capabilities in Microsoft Marketplace, partners can run self-service trials that make it easier for customers to try before they buy — whether for metered, per-user, or flat-rate pricing offers. Marketplace gives partners one place to manage trials end to end — from provisioning and mid-trial changes to insights — while improving offer discoverability through improved search, filters, and dedicated trial badges. Recommended action Review your Marketplace offers and trial strategy. For eligible SaaS offers, evaluate whether free trials can help you engage with more qualified buyers, faster. 📖 Learn more about free trials for SaaS ⚡ Customers can now request a private offer on Marketplace What’s new As of July 20, you can add a private offer request option directly on your Marketplace product pages. Customer requests are captured as Marketplace leads in referrals workspace and connected customer relationship management (CRM) integrations you’ve setup. This setting is disabled by default. You can easily activate it for applicable public offers. Why it matters More and more customers are seeking customized contracts and subscription pricing and terms tailored to their individual needs. This simple call to action reduces friction and helps you start the conversation with prospective buyers. Recommended action In the Marketplace offers workspace of Partner Center, update each of your offers for which you provide customers private offers. Enable the Request Private Offer setting and republish the offer. Events Recent events Multiparty private offers expand channel growth opportunities in Australia, Japan and South Africa Multiparty private offers continue to help software companies accelerate channel-led sales through Microsoft Marketplace. This past month, we hosted two region-focused Marketplace office hours sessions designed to help partners better understand local market opportunities, engage distributors and resellers, and scale Marketplace transactions through channel ecosystems in Australia and Japan. Whether you're looking to expand an existing Marketplace motion or explore new geographic opportunities, these sessions will provide practical guidance and market-specific insights to help you grow. See a list of currently supported countries/regions. Check out the recorded sessions: • Channel growth in Australia (English) • Channel growth in Japan (Japanese) Helping developers build, monetize, and scale AI solutions with Marketplace Discover how Microsoft Marketplace helps software companies access AI models and developer tools, accelerate application development, and reach customers through Microsoft's global commercial ecosystem. Learn how to monetize applications and agents without building and maintaining your own commerce and distribution infrastructure. Watch the recording Upcoming events Build AI-powered solutions, monetize through Microsoft Marketplace, and scale revenue through Microsoft expertise, skilling, and investments. Frontier Accelerate for Marketplace is an upcoming unified offering for software development companies to bring AI-powered solutions to market, drive customer acquisition and revenue growth, and scale through Microsoft Marketplace with technical guidance, skilling, and investments aligned to every stage of growth. 📆 Join us on August 26th before general availability to learn about the new offering, benefit alignment, migration guidance, and enrollment requirements. Next steps Turn insights into FY27 success — starting today. Ready to carry the momentum forward from MCAPS Start for Partners? Get everything you need to refine and execute your FY27 strategy in the Partner Activation Zone, including session recordings, ready-to-use playbooks, and tools to start building pipeline. Leverage your Marketplace Rewards benefits Discover use cases and how to leverage your Azure sponsorship. With Marketplace Rewards Azure sponsorships, eligible software development companies can increase sales through Microsoft Marketplace by using the sponsorships for customer deployments tied to Marketplace deals—and to offset infrastructure costs from eligible free trial offers. 📍Review the Marketplace Rewards Azure sponsorship policy guide for the latestMicrosoft Marketplace Partner Digest
In this edition of the Microsoft Marketplace Partner Digest, you'll find essential announcements, events, and key updates designed to drive your business forward, accelerate deal closures, and maximize your Marketplace success. Partner Center announcements As we kick off the new fiscal year, we're building upon a quarter that delivered valuable enhancements for both Marketplace partners and customers. We’ve focused on expanding partner-led growth across regions, simplifying SaaS transactions, and helping you improve co-sell outcomes. 🌍 Multiparty private offers expand across EMEA and APAC On May 27, Microsoft Marketplace expanded multiparty private offers to 30 countries in Europe, with availability in Australia, Japan, and South Africa coming July 15. Read the blog to discover how we are enabling new opportunities for channel-led growth through Marketplace. Why it matters Software companies gain more opportunities to reach new customers and drive growth without adding operational complexity. Channel partners differentiate their offerings with vetted software solutions while maintaining customer relationships. Recommended action Microsoft’s Jason Rook breaks down six practical steps to activate your channel strategy through Microsoft Marketplace, helping software companies recruit, enable, and scale partner-led growth. 📗Get the playbook 🌏 Resale enabled offers support expands to New Zealand Microsoft continues expanding channel-led sales opportunities by making resale enabled offers available through Microsoft Marketplace to customers in New Zealand as of May 26. Why it matters Channel partners can create and manage offers directly, without relying on software companies to build bespoke private offers. For software companies, resale enabled offers provide a scalable way to grow through trusted channel partners and expand into new markets. 👉 Learn more 📆 Custom contract lengths As of July 6, custom contract lengths for private offers are generally available. Partners can now create private offers with custom contract lengths of up to 10 years in Microsoft Marketplace. Why it matters Flexibility to better meet customer requirements Ability to configure contract durations from 1 to 120 months Define non-standard contract lengths, like 18 months or 45 months Support for both SaaS and professional services transactions 👉 Read the announcement ⚡ Auto activation for SaaS offers On May 18, Microsoft released the optional auto activation for SaaS offers, streamlining customer's Marketplace purchase and onboarding experience. What’s new Billing and subscription activation can now begin immediately when a customer completes a purchase Partners receive a real-time webhook signal to trigger onboarding Available for both public and private offers Default behavior For existing plans auto activation is off, unless you enable it When creating new plans auto activation is on, by default, unless you disable it Why it matters Reduces friction between purchase and onboarding Improves revenue predictability with immediate billing Enables a faster, more seamless customer experience Recommended action Evaluate your SaaS offers and enable auto activation where it aligns with your onboarding model. Make sure your sales and customer guidance reflect the updated experience. 👉 Learn more 🔔 Improve referral quality to accelerate co-sell deals Microsoft has updated how inbound co-sell referrals are reviewed and processed to improve speed and alignment with Microsoft account teams. What’s changing All referrals are now automatically checked for completeness and quality at submission. To avoid delays, ensure every referral includes: Solution area / play Estimated deal value Estimated close date (valid future date) Clear customer need and business context Customer contact (or consent to share later) Why it matters Submitting complete referrals helps you: Get faster seller engagement Reduce rework and follow-ups Improve acceptance rates Move deals forward more predictably Recommended action Audit your referral submission process and ensure these five fields are consistently included across all deals. 👉 Learn more about managing co-sell opportunities ⚠️ Review: Ensure the right contacts receive important partner communications Now is a great time to take care of digital housekeeping. Microsoft is reminding partners to review assigned Partner Center roles and email configurations to avoid missing critical notifications and account updates. Why it matters Having assigned roles like global admin or billing admin does not guarantee email delivery. If accounts aren’t configured correctly, you and your team may miss time-sensitive notifications. Missing communications can result in missed compliance deadlines or delayed actions that may impact your business. Recommended actions Verify your primary contact email is up to date Ensure role-based accounts can receive emails Add Microsoft system emails as safe senders Review role guidance on Microsoft Learn ✨ Bonus: Sign up for the monthly Microsoft AI Cloud Partner Program newsletter to stay informed of updates, incentives, and partner opportunities. It’s an easy way to get partner news delivered directly to your inbox. Events Recent events Marketplace as a FinOps platform Explore how Microsoft Marketplace helps simplify purchasing, centralize billing, and better align software investments to optimize cloud spending. As organizations scale cloud and AI investments, managing spend across tools and vendors becomes more complex. Tune in to learn practical ways to better understand the ROI of your organization’s cloud and AI investments. You will walk away with actionable insights to use Microsoft Marketplace as part of your FinOps strategy 📽️ Watch the recording The Marketplace playbook for channel-led sales Get step-by-step guidance and go-to-market resources to help you recruit and activate partners for channel-led sales through Microsoft Marketplace. Through resale enabled offers and multiparty private offers, software companies can empower partners to sell on their behalf to drive scale, reach new markets, and unlock new co-sell opportunities. In markets where both resale enabled offers and multiparty private offers are available, software companies can also scale through distributors, who can activate their broader channel networks. 📽️ Watch the recording Multicurrency transactions explained As Marketplace adoption continues to grow more partners are navigating sales that involve multiple currencies, local customer invoicing, and evolving seller of record responsibilities. Understanding how currency exchanges impact private offers, partner payments, and customer billing is critical to successfully managing Marketplace transactions across global geographies. 📽️ Watch the recording Upcoming events Channel growth in Australia ⌚Wednesday, July 15 at 9:30 AEST Microsoft Marketplace provides several ways for partners to collaborate and grow through the channel. With multiparty private offers launching in Australia on July 16, alongside resale enabled offers, this expansion helps partners strengthen customer relationships, fuel more partner-to-partner opportunities, simplify transactions, and find new growth opportunities. Leave with practical guidance on how these capabilities work together and how to put them into action. 📆 Save to your calendar MCAPS Start for Partners 📆 Wednesday, July 22 from 7:00 – 11:00 am PDT MCAPS Start for Partners gives software companies an early look at Microsoft’s FY27 priorities, investments, and growth opportunities. Learn how AI innovation and agentic applications are creating new customer demand, discover marketplace and co-sell opportunities to expand reach, and explore strategies to modernize, differentiate, and grow your business in the year ahead. 👉 Learn more and register today 🚀 Closing thoughts The last quarter delivered meaningful platform enhancements to make Microsoft Marketplace easier to scale, faster for customers to discover solutions and transact, and more effective for partners to manage business. 👍 Take the next step Explore new regions for multiparty private offers and resale enabled offers Review your strategy for activation of customer SaaS subscriptions Improve your co-sell submission quality Small changes in these areas can have a big impact on your pipeline, conversion, and overall Marketplace success.Design observability for AI apps and agents selling through Microsoft Marketplace
In the last post, API resilience and reliability patterns for AI apps and agents, we focused on what happens when AI systems encounter failure—and how resilient execution paths keep that failure contained. Timeouts fire with intent. Retries stay bounded. Circuit breakers provide overload protection. When resilience is designed well, your system continues to function even as conditions change, forming the foundation of AI reliability engineering. You can always get curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. Observability for AI systems AI apps and agents are shifting traditional observability, which was designed for systems based on simple assumptions, where requests followed linear paths and workloads behaved predictably. Execution in AI systems consumes tokens at a highly variable rate rather than fixed compute units. Requests unfold across multiple reasoning steps. Agents perform work that spans APIs, models, retrieval layers, and applications. A single interaction may pause, branch, retry, or exit early depending on inferred intent, context, and constraints. Instead of asking whether services are running, observability for AI systems asks: what is the system doing right now—and why? Is an agent spending its time reasoning, waiting on dependencies, retrying tool calls, or exiting early due to enforced limits? Is cost increasing because value is increasing, or because execution paths are expanding without progress? AI observability requirements shift the focus in the following subtle, but critical ways: From resource availability to workflow state From performance metrics to signals From incidents to patterns Core observability dimensions for AI apps and agents Once observability shifts toward understanding behavior, clarity comes from tracking state across the agents in the workflow. For AI apps and agents, observable indicators, such as those detailed below, show how work unfolds and changes during real usage—especially in trials and early adoption: Execution flow shows how a request moves through agents, tools, and workflows. This highlights where execution progresses smoothly, where it slows, and where it concludes early. This makes agent outcomes explainable and keeps behavior consistent across tenants. Cost and token behavior reveals how execution translates into consumption. Token usage per request, per agent step, and per retry shows where value is being delivered and where execution paths expand without proportional benefit. This insight connects runtime behavior directly to Marketplace billing expectations and evaluations. Latency and wait states distinguish active processing from time spent waiting on dependencies. Seeing where time is consumed helps explain slow experiences and guides decisions about optimization, caching, or resilience improvements. Failure classification provides structure when systems degrade and supports effective AI incident management. Separating tool failures from planning failures, and transient issues from terminal exits, keeps investigations focused and prevents protective behavior from being misread as instability. Tenant‑level patterns surface how behavior repeats at scale. Uneven load, and recurring degradation often appear first during trials and shape the customer's perception. Together, these dimensions turn telemetry into understanding—supporting clearer conversations, faster triage, and predictable execution as usage grows. Why observability matters By this point in the journey, your AI app or agent has implemented bounded execution paths, cost controls, and quality of service safeguards. As a result, failure degrades gracefully instead of spreading. These resilience techniques determine how your solution behaves under pressure. The data gathered from observability platforms like Application Insights and Azure Monitor explains why it behaves that way. For AI and agentic systems, infrastructure health alone rarely answers the questions that matter. Services can be up, CPUs can be idle, and queues can look healthy while agents loop inefficiently, retries quietly expand cost, or workflows exit early without delivering value. From the customer’s perspective, the experience feels inconsistent even though the platform appears stable. AI app observability closes this gap by revealing system behavior rather than system status. It shows how requests move, where work concentrates, and how constraints shape outcomes. At Marketplace scale, these patterns repeat across tenants and trials. What appears once during an evaluation often appears again as adoption grows. Observability connects runtime behavior back to the design choices introduced in earlier posts: Usage‑based billing introduced variability in consumption Performance optimization introduced tradeoffs among latency, quality, and cost Resilience patterns introduced controlled failure and bounded execution Observability allows you to explain outcomes during trials, validate assumptions as usage grows, and support post-launch AI operations confidence across customers and environments. Without this visibility, teams react to symptoms. With it, they recognize patterns. From execution paths to behavioral signals Observability begins at the same place resilience begins—API boundaries. These boundaries define where responsibility shifts and where behavior becomes visible. Observability focuses on signals that explain decisions made by the system as it executes instead of relying on raw logs that describe isolated events. Every resilience mechanism emits behavioral signals. Viewed together, these signals provide far more value than logs alone. Logs answer whether something happened. Behavioral signals explain why it happened and how the system responded. Circuit breakers change state as load builds and recedes. Retry loops show whether failures resolve quickly or exhaust their limits. Timeout enforcement reveals where dependencies slow execution. Fallback paths and early terminations show how the system protects itself while preserving outcomes for customers. This perspective matters most for agents. Agent execution unfolds as a series of choices—plan, call a tool, retry, exit early—rather than a single request‑response cycle, which requires monitoring AI agent behavior to remain understandable and consistent at scale. Observability that tracks these decisions makes agent behavior understandable, consistent, and defensible as usage grows across customer tenants. Observability at the agent layer As AI systems become more agent‑driven, observability needs to move closer to where decisions are made. Agents introduce variability by design. They plan, adapt, and choose workflow paths dynamically. Without first‑class visibility into that behavior, execution can appear unpredictable even when the underlying system is healthy. Observability at the agent layer acts as the feedback loop that keeps execution safely bounded. It shows how agents use the freedom you give them—and where that freedom begins to stretch into inefficiency. Observability follows how the agent did its job instead of treating the agent’s interaction as a single outcome. Several indicators help make agent behavior understandable. Step count per request reveals how much reasoning effort a prompt requires. Planning iterations show whether an agent converges quickly or cycles through alternatives. Tool invocation frequency highlights when agents rely heavily on external systems. Early exits compared to full completion explain whether limits and fallbacks activate as designed. Taken together, these indicators help distinguish healthy exploration from inefficient reasoning and degraded execution. An agent exploring briefly before converging adds value. An agent looping through tools without progress signals pressure, uncertainty, or dependency issues. This distinction reinforces a core principle of agentic systems: models reason probabilistically, adapting to context as it changes. Your system observes deterministically—measuring execution, enforcing boundaries, and clarifying outcomes. When those roles stay separate and well‑instrumented, agent behavior becomes transparent, predictable, and ready for Marketplace scale. Observability across environments The type of Marketplace offer you choose shapes what observability customers expect and how responsibility is shared. For SaaS offers, publishers typically own end‑to‑end execution. Observability centers on agent behavior, workflow completion, token usage, latency, and dependency impact across tenants. Publishers rely on consistent signals—often surfaced through tools like Azure Monitor, Application Insights, and Microsoft AI Foundry—to explain how requests behave as scale and load increase. For container‑based offers and Azure Managed Applications, observability expectations are more distributed. Publishers expose clear execution outcomes, limits, and failure signals at application boundaries. Customers, in turn, observe infrastructure health, scaling behavior, and downstream systems within their own environments. This separation ensures each party has visibility into what they control without creating ambiguity. Learn more about Choosing your marketplace offer type for AI Apps and agents. Execution behavior differs across environments for predictable reasons. Scale increases, tenant mix broadens, and external dependencies behave differently under real load. What must stay consistent is how behavior is interpreted. Signal definitions, thresholds, and failure classification should mean the same thing in Dev, Stage, and Prod. Learn more about designing a reliable environment strategy for Microsoft Marketplace AI apps and agents. Staging environments are where this consistency is validated. Observing retries, timeouts, and graceful degradation before production prepares you for Marketplace evaluations, which often resemble production conditions. Observability gaps tend to appear first during customer evaluation—when clarity matters most. Publisher and customer visibility boundaries Purpose: Parallel Post #13 responsibility clarity, now for observability As observability matures across environments, clarity around responsibility becomes essential. For Marketplace solutions, trust grows when publishers and customers each see what they own—and understand where that visibility ends. Publishers are responsible for instrumenting execution paths end to end. That means making workflows traceable, limits visible, and failure modes explainable. Observability should surface behavior—how requests progressed, where execution concluded, and why—rather than exposing raw internal errors that require insider knowledge to interpret. Customers focus their observability on what they control. This includes monitoring downstream systems, infrastructure behavior, and environment‑level alerts within their own estate. When visibility aligns with ownership, teams can act quickly and decisively. Exposing too much internal detail can overwhelm customers and blur accountability. Observing too little behavior creates friction, especially when issues cross boundaries and lack context. Clear visibility enables faster triage, sharper ownership boundaries, and fewer escalations rooted in ambiguity. Observability as an enabler for scale, billing, and trust From a customer’s perspective, observability answers two fundamental questions: Can I understand what happened? and Can I trust this at scale? When the answer to both is clear, observability becomes part of the value your Marketplace offering delivers. When system behavior is visible and explainable, customers gain confidence that adoption and growth will remain predictable. Observability directly supports usage‑based billing by tying execution behavior to measured consumption. Clear visibility into token usage, retries, and execution paths helps validate how usage is calculated and supports transparent billing conversations. It also enables ongoing performance tuning and caching strategies by showing where latency accumulates, where work repeats, and where optimization delivers measurable impact. Observability reinforces confidence in resilience mechanisms, confirming that limits, fallbacks, and degradation paths activate as designed under real‑world conditions. Beyond validation, observability creates a continuous feedback loop. Execution data informs pricing adjustments, guides changes to limits, and helps refine default configurations as customer behavior evolves. What’s next in the journey With execution behavior observable and explainable, the focus shifts to how AI systems are operated safely as change accelerates. The upcoming posts will discuss deployment strategies, CI/CD pipelines for agents, and progressive rollouts build on this foundation—ensuring AI apps evolve confidently as usage and expectations grow. Key Resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessHow to get heard by Microsoft and win more together
At Ultimate Partner LIVE Bellevue, May 11-13, some of the sharpest practitioners in the Microsoft ecosystem are coming together to share what works. These are candid, practitioner-led sessions built for senior leaders who need to walk away with something they can use, not a framework to revisit in six months. 🏛️ Sessions Worth Your Time 💰 Marketplace Meets AI: The New Route to Partner Revenue Cyril Belikoff, VP Microsoft Azure · Jon Yoo, CEO Suger Cyril Belikoff helped architect the unified Microsoft Marketplace and launched the resale enabled offer, which lets channel partners bundle software development company solutions and transact against Azure commit. Within the 1st week of GA, partners were already processing deals at scale. Cyril joins Vince Menzione and Jon Yoo, CEO of Suger, on Day 1 to cover where the AI-driven marketplace motion is heading and what partners need to do now to capture their share of the revenue flowing through it. Cyril’s advice for the partner still on the sideline is direct: do not try to boil the ocean. Get listed. Create offerings. Figure out 1 or 2 deals, transact them, and see the opportunity. This session gives you the map. 🎯 From Attention to Trust: The New Rules of Hyperscaler Go-To-Market Ashleigh Vogstad, CEO Transcends · Leigh Ann Campbell, Principal REV Alliances We are no longer in an attention economy. You are not competing to be seen. You are competing to be trusted, and the shift has a specific mechanism. AI agents are already making procurement decisions using verified signals: co-sell track records, Partner Center data, marketplace history, certifications. The partners building that record now are building an advantage that compounds quickly and is difficult to replicate later. Leigh Ann Campbell has driven over $200 million in influenced and net-new revenue through the Microsoft partner ecosystem. She knows what happens to a referral the moment it lands in Partner Center and what you need to do to make sure it does not die there. Ashleigh Vogstad, CEO of Transcends, brings the broader GTM lens on how the trust economy is changing what buyers respond to and where most partner marketing misses the mark. 🚀 Partner to Pipeline: Activating your GTM Strategy Reis Barrie, CEO Carve Partners · Greg Goldkamp, Sr. Director Microsoft This is the rare combination of a partner who has built real pipeline through Microsoft’s co-sell motion and a Microsoft leader who can tell you directly what gets field attention and what gets ignored. Most software companies approach co-sell as a relationship exercise. The ones generating real pipeline treat it as a system. They know which solution plays are active in the current fiscal year. They show up in seller conversations before a deal is open. They make it easy for a Microsoft seller to bring them in because the pitch is already mapped to what that seller is measured on. This session covers how to build that system, from first registration in Partner Center through closed pipeline. 🔗 From Connector to Catalyst: Today’s Alliance Manager Erin Figer, Founder CORE Consulting · Christine Bongard, CEO The WIT Network · Steven Karachinsky, CEO ZIRO Erin Figer helped build the co-sell practices at Microsoft, AWS, and Google Cloud when those programs were still being designed. She brings a reframe that changes how the best alliance teams operate: before you can market with a hyperscaler, you have to market to them. Treat Microsoft like a customer. Understand their priorities, their fiscal calendar, their field incentives. Build the internal credibility that gets you pulled into deals instead of chasing them. Joined by Christine Bongard and Steven Karachinsky, this session covers what the transition from connector to catalyst looks like in practice and what separates the alliance managers who generate revenue from those who manage relationships. 💡 Why the practitioner track matters These are not panel discussions with safe answers. This audience asks direct questions, and the speakers in these sessions are prepared to give direct answers. These sessions run across both days alongside 2 full tracks of mainstage content covering marketplace, distribution, AI strategy, and Microsoft’s channel priorities heading into FY27. 📅 UP LIVE Bellevue · May 11–13, 2026 InterContinental Hotel, Bellevue, WA 🌟 Exclusive discount for Microsoft partners Use code ULTIMATEVIP50 at checkout for a special discount reserved for Microsoft partners. 👉 Register for UP LIVE Bellevue Ultimate Partner® is the premier independent platform for technology partnership leaders, uniting the hyperscaler ecosystem to achieve their greatest results through partnering. An official Microsoft GPS recognized community.Design tenant linking to scale selling on Microsoft Marketplace
Designing tenant linking and Open Authorization (OAuth) directly shapes how customers onboard, grant trust, and operate your AI app or agent through Microsoft Marketplace. This post explains how to design scalable, review‑ready identity patterns that support secure activation, clear authorization boundaries, and enterprise trust from day one. Guidance for multi‑tenant AI apps Identity decisions are rarely visible in architecture diagrams, but they are immediately visible to customers. In Microsoft Marketplace, tenant linking and OAuth consent are not background implementation details. They shape activation, onboarding, certification, and long‑term trust with enterprise buyers. When identity decisions are made late, the impact is predictable. Onboarding breaks. Permissions feel misaligned. Reviews stall. Customers hesitate. When identity is designed intentionally from the start, Marketplace experiences feel coherent, secure, and enterprise‑ready. This post focuses on how software development companies (like ISVs) can design tenant linking and consent patterns that scale across customers, offer types, and Marketplace review—without rework later. You can always get curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series that focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. Why identity across tenants is a first‑class design decision Designing identity is not just about authentication. It is about how trust is established between your solution and a customer tenant, and how that trust evolves over time. When identity decisions are deferred, failure modes surface quickly: Activation flows that cannot complete cleanly Consent requests that do not match declared functionality Over‑privileged apps that fail security review Customers who cannot confidently revoke access These are not edge cases. They are some of the most common reasons Marketplace onboarding slows or certifications are delayed. A good identity and access management design ensures that trust, consent, provisioning, and operation follow a predictable and reviewable path—one that customers understand and administrators can approve. Marketplace tenant linking requirements A key mental model simplifies everything that follows: separate trust establishment from authorization. Tenant linking and OAuth consent solve different problems. Tenant linking establishes trust between tenants OAuth consent grants permission within that trust Tenant linking answers: Which customer tenant does this solution trust? OAuth consent answers: What is this solution allowed to do once trusted? AI solutions published in Microsoft Marketplace should enforce this separation intentionally. Trust must be established before meaningful permissions are granted, and permission scope must align to declared functionality. Making this distinction explicit early prevents architectural shortcuts that later block certification. Throughout the rest of this post, tenant linking refers to trust establishment, not permission scope. Microsoft Entra ID as the identity foundation Microsoft Entra ID provides the primitives for identity-based access control, but the concepts only become useful when translated into publisher decisions. Each core concept maps to a choice you make early: Home tenant vs resource tenant Determines where operational control lives and how cross‑tenant trust is anchored. App registrations Define the maximum permission boundary your solution can ever request. Service principals Determine how your app appears, is governed, and is managed inside customer tenants. Managed identities Reduce long‑term credential risk and operational overhead. Understanding these decisions early prevents redesigning consent flows, re‑certifying offers, or re‑provisioning customers later. Marketplace policies reinforce this by allowing only limited consent during activation, with broader permissions granted incrementally after onboarding. Importantly, activation consent is not operational consent. Activation establishes the commercial and identity relationship. Operational permissions come later, when customers understand what your solution will actually do. OAuth consent patterns for multi‑tenant AI apps OAuth consent is not an implementation detail in Marketplace. It directly determines whether your AI app can be certified, deployed smoothly, and governed by enterprise customers. Common consent patterns map closely to AI behavior: User consent Supports read‑only or user‑initiated interactions with no autonomous actions. Admin consent Enables agents, background jobs, cross‑user access, and cross‑resource operations. Pre‑authorized consent Enables predictable, enterprise‑grade onboarding with known and approved scopes. While some AI experiences begin with user‑driven interactions, most AI solutions in Marketplace ultimately require admin consent. They operate asynchronously, act across resources, or persist beyond a single user session. Aligning expectations early avoids friction during review and deployment. Designing consent flows customers trust Consent dialogs are part of your product experience. They are not just Microsoft‑provided UI. Marketplace reviewers evaluate whether requested permissions are proportional to declared functionality. Over‑scoped consent remains one of the most common causes of delayed or failed certification. Strong consent design: Requests only what is necessary for declared behavior Explains why permissions are needed in plain language Aligns timing with customer understanding Poor explanations increase admin rejection rates, even when permissions are technically valid. Clear consent copy builds trust and accelerates approvals. Tenant linking across offer types Identity design must align with offer type; a helpful framing is ownership: SaaS offers The publisher owns identity orchestration and tenant linking. Microsoft Marketplace reviewers expect this alignment, and mismatches surface quickly during certification. Containers and virtual machines The customer owns runtime identity; the publisher integrates with it. Managed applications Responsibility is shared, but the publisher defines the trust boundary. Each model carries different expectations for control, consent, and revocation. Designing tenant linking that matches the offer type reduces customer confusion. When consent actually happens in Marketplace lifecycle Many identity issues stem from unclear timing. A simple lifecycle helps anchor expectations: Buy – The customer purchases the offer Activate – Tenant trust is established Consent – Limited activation consent is granted Provision – Resources and configurations are created Operate – Incremental operational consent may be requested Revoke – Access and trust can be cleanly removed Making this sequence explicit in your design—and in your documentation—dramatically reduces confusion for customers and reviewers alike. How tenant linking shapes Marketplace readiness Identity tends to leave a lasting impression as it is one of the first architectural design choices encountered by customers. Strong tenant linking and consent design leads to: Faster certification (applies to SaaS offer only) Fewer conditional approvals Lower onboarding drop‑off Easier enterprise security reviews These outcomes are not accidental. They reflect intentional design choices made early. What’s next in the journey Tenant identity sets the foundation, but it is only one part of Marketplace readiness. In upcoming guidance, we’ll connect identity decisions to commerce, SaaS Fulfillment APIs, and operational lifecycle management—so buy, activate, provision, operate, and revoke work together as a single, coherent system. Key Resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessDesigning a reliable environment strategy for Microsoft Marketplace AI apps and agents
Technical guidance for software companies Delivering an AI app or agent through Microsoft Marketplace requires more than strong model performance or a well‑designed user flow. Once your solution is published, both you and your customers must be able to update, test, validate, and promote changes without compromising production stability. A structured environment strategy—Dev, Stage, and Production—is the architectural mechanism that makes this possible. This post provides a technical blueprint for how software companies and Microsoft Marketplace customers should design, operate, and maintain environment separation for AI apps and agents. It focuses on safe iteration, version control, quality gates, reproducible deployments, and the shared responsibility model that spans publisher and customer tenants. You can always get a curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. Why environment strategy is a core architectural requirement Environment separation is not just a DevOps workflow. It is an architectural control that ensures your AI system evolves safely, predictably, and traceably across its lifecycle. This is particularly important for Marketplace solutions because your changes impact not just your own environment, but every tenant where the solution runs. AI‑driven systems behave differently from traditional software: Prompts evolve and drift through iterative improvements. Model versions shift, sometimes silently, affecting output behavior. Tools and external dependencies introduce new boundary conditions. Retrieval sources change over time, producing different Retrieval Augmented Generation (RAG) contexts. Agent reasoning is probabilistic and can vary across environments. Without explicit boundaries, an update that behaves as expected in Dev may regress in Stage or introduce unpredictable behavior in Production. Marketplace elevates these risks because customers rely on your solution to operate within enterprise constraints and support AI scalability for enterprise. A well‑designed environment strategy answers the fundamental operational question: How does this solution change safely over time? Publisher-managed environment (tenant) Software companies publishing to Marketplace must maintain a clear three‑tier environment strategy. Each environment serves a distinct purpose and enforces different controls. Development environment: Iterate freely, without customer impact In Dev, engineers modify prompts, adjust orchestration logic, integrate new tools, and test updated model versions. This environment must support: Rapid prompt iteration with strict versioning, never editing in place. Model pinning, ensuring inference uses a declared version. Isolated test data, preventing contamination of production RAG contexts. Feature‑flag‑driven experimentation, enabling controlled testing. Staging environment: Validate behavior before promotion Stage is where quality gates activate. All changes—including prompt updates, model upgrades, new tools, and logic changes—must pass structured validation before they can be promoted. This environment enforces: Integration testing that supports AI app performance optimization Acceptance criteria Consistency and performance baselines Safety evaluation and limits enforcement Production environment: Serve customers with reliability and rollback readiness Solutions running in production environments, regardless of whether they are publisher hosted or deployed into a customer's tenant must provide: Stable, predictable behavior, supported by deliberate AI workload capacity planning Strict separation from test data sources Clearly defined rollback paths Auditability for all environment‑specific configurations This model highlights the core environments required for Marketplace readiness; in practice, publishers may introduce additional environments such as integration, testing, or preproduction depending on their delivery pipeline. The customer tenant deployment model: Deploying safely across customer environments Once a Marketplace customer purchases and deploys your AI app or agent, they must be able to deploy and maintain your solution across all their environments without reverse engineering your architecture. A strong offer must provide: Repeatable deployments across all heterogeneous environments. Predictable configuration separation, including identity, data sources, and policy boundaries. Customer‑controlled promotion workflows—updates should never be forced. No required re‑creation of environments for each new version. Publishers should design deployment artifacts such that customers do not have to manually re‑establish trust boundaries, identity settings, or configuration details each time the publisher releases a solution update. Plan for AI‑specific environment challenges AI systems introduce behavioral variances that traditional microservices do not. Your environment strategy must explicitly account for them. Prompt drift Prompts that behave well in one environment may respond differently in another due to: Different user inputs, where production prompts encounter broader and less predictable queries than test environments Variation in RAG contexts, driven by differences in indexed content, freshness, and data access Model behavior shifts under scale, including concurrency effects and token pressure, which also affects cost and requires attention to cost optimization for AI apps Tool availability differences, where agents may have access to different tools or permissions across environments This requires explicit prompt versioning and environment-based promotion. Model version mismatches If one environment uses a different model version or even a different checkpoint, behavior divergence will appear immediately. Publishers should account for the following model management best practices: Model version pinning per environment Clear promotion paths for model updates RAG context variation Different environments may retrieve different documents unless seeded on purpose. Publishers should ensure their solutions avoid: Test data appearing in production environments Production data leaking into non-production environments Cross contamination of customer data in multi-tenant SaaS solutions Make sure your solution accounts for stale-data and real-time data. Agent variability Agents exhibit stochastic reasoning paths, which becomes more pronounced when scaling AI agents. Environments must enforce: Controlled tool access Reasoning step boundaries Consistent evaluation against expected patterns Publisher–customer boundary: Shared responsibilities Marketplace AI solutions span publisher and customer tenants, which means environment strategy is jointly owned. Each side has well-defined responsibilities. Publisher responsibilities Publishers should: Design an environment model that is reproducible inside customer tenants. Provide clear documentation for environment-specific configuration. Ensure updates are promotable, not disruptive, by default. Capture environment‑specific logs, traces, and evaluation signals to support debugging, audits, and incident response. Customer responsibilities Customers should: Maintain environment separation using their governance practices. Validate updates in staging before deploying them in production. Treat environment strategy as part of their operational contract with the publisher. Environment strategies support Marketplace readiness A well‑defined environment model is a Marketplace accelerator. It improves: Onboarding Customers adopt faster when: Deployments are predictable Configurations are well scoped Updates have controlled impact Long-term operations Strong environment strategy reduces: Regression risk Customer support escalations Operational instability Solutions that support clear environment promotion paths have higher retention and fewer incidents. What’s next in the journey The next architectural decision after environment separation is identity flow across these environments and across tenant boundaries, especially for AI agents acting on behalf of users. The follow‑up post will explore tenant linking, OAuth consent patterns, and identity‑plane boundaries in Marketplace AI architectures. See the next post in the series: Designing Tenant Linking to Scale Microsoft Marketplace AI Apps. Key Resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessQuality and evaluation framework for successful AI apps and agents in Microsoft Marketplace
Why quality in AI is different — and why it matters for Marketplace Traditional software quality spans many dimensions — from performance and reliability to correctness and fault tolerance — but once those characteristics are specified and validated, system behavior is generally stable and repeatable. Quality is assessed through correctness, reliability, performance, and adherence to specifications. AI apps and agents change this equation. Their behavior is inherently non-deterministic and context‑dependent. The same prompt can produce different responses depending on model version, retrieval context, prior interactions, or environmental conditions, which is why non-deterministic AI testing is required to evaluate it reliably. For agentic systems, quality also depends on reasoning paths, tool selection, and how decisions unfold across multiple steps — not just on the final output. This means an AI app can appear functional while still falling short on quality: producing responses that are inconsistent, misleading, misaligned with intent, or unsafe in edge cases. Without a structured evaluation framework, these gaps often surface only in production — in customer environments, after trust has already been extended. For Microsoft Marketplace, this distinction matters. Buyers expect AI apps and agents to behave predictably, operate within clear boundaries, and remain fit for purpose as they scale. AI quality evaluation turns those expectations into something observable — and that visibility is what determines Marketplace readiness. You can always get a curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. How quality measurement shapes Marketplace readiness AI apps and agents that can demonstrate quality — with documented evaluation frameworks, defined release criteria, and evidence of ongoing measurement — are easier to evaluate, trust, and adopt. Quality evidence reduces friction during Marketplace review, clarifies expectations during customer onboarding, and supports long-term confidence in production. When quality is visible and traceable, the conversation shifts from "does this work?" to "how do we scale it?" — which is exactly where publishers want to be. Publishers who treat quality as a first-class discipline build the foundation for safe iteration, customer retention, and sustainable growth through Microsoft Marketplace. That foundation is built through the decisions, frameworks, and evaluation practices established long before a solution reaches review. What "quality" means for AI apps and agents Quality for AI apps and agents is not a single metric — it spans interconnected dimensions that together define whether a system is doing what it was built to do, for the people it was built to serve. The HAX Design Library — Microsoft's collection of human-AI interaction design patterns — offers practical guidance for each one. These dimensions must be defined before evaluation begins. You can only measure what you have first described. Accuracy and relevance — does the output reflect the right answer, grounded in the right context? HAX patterns Make clear what the system can do (G1) and notify users when the AI is uncertain (G10) help publishers design systems where accuracy is visible and outputs are understood in the right context — not treated as universally authoritative. Safety and alignment — does the output stay within intended use, without harmful, biased, or policy-violating content? HAX patterns Mitigate social biases (G6) and Support efficient correction (G9) help ensure outputs stay within acceptable boundaries — and that users can identify and address issues before they cause downstream harm. Consistency and reliability — does the system behave predictably across users, sessions, and environments? HAX patterns Remember recent interactions (G12) and notify users about changes (G18) keep behavior coherent within sessions and ensure updates to the model or prompts are never silently introduced. Fitness for purpose — does the system do what it was designed to do, for the people it was designed to serve, in the conditions it will actually operate in? HAX patterns make clear how well the system can do what it does (G2) and Act on the user's context and goals (G4) ensure the system responds to what users actually need — not just what they literally typed. These dimensions work together — and gaps in any one of them will surface in production, often in ways that are difficult to trace without a deliberate evaluation framework. Designing an evaluation framework before you ship Evaluation frameworks should be built alongside the solution. At the end, gaps are harder and costlier to close. The discipline mirrors the design-in approach that applies to security and governance: decisions made early shape what is measurable, what is improvable, and what is ready to ship. A well-structured evaluation framework defines five things: What to measure — the quality dimensions that matter most for this solution and its intended use cases. For AI apps and agents, this typically includes task adherence, response coherence, groundedness, and safety — alongside the fitness-for-purpose dimensions defined in the previous section. How to measure it — the methods, tools, and benchmarks used to assess quality consistently. Effective evaluation combines AI-assisted evaluators (which use a model as a judge to score outputs), rule-based evaluators (which apply deterministic logic), and human review for edge cases and safety-relevant responses that automated methods cannot fully capture. Who evaluates — the right combination of automated metrics, human review, and structured customer feedback. No single method is sufficient; the framework defines how each is applied and when human judgment takes precedence. When to evaluate — at defined milestones: during development to establish a baseline, pre-release to validate against acceptance thresholds, at rollout to catch regression, and continuously in production to detect drift as models, prompts, and data evolve. What triggers re-evaluation — model updates, prompt changes, new data sources, tool additions, or meaningful shifts in customer usage patterns. Re-evaluation should be a scheduled and triggered discipline, not an ad hoc response to visible failures. The framework becomes a shared artifact — used by the publisher to release safely, and by customers to understand what quality commitments they are adopting when they deploy the solution in their environment. Evaluate your AI agents - Microsoft Foundry | Microsoft Learn Evaluation methods for AI apps and agents Quality must be assessed across complementary AI evaluation methods — each designed to surface a different category of risk, at a different stage of the solution lifecycle. Automated metric evaluation — evaluators assess agent responses against defined criteria at scale. Some use AI models as judges to score outputs like task adherence, coherence, and groundedness; others apply deterministic rules or text similarity algorithms. Automated evaluation is most effective when acceptance thresholds are defined upfront — for example, a minimum task adherence pass rate before a release proceeds. Safety evaluation — a dedicated evaluation category that identifies potential content risks, policy violations, and harmful outputs in generated responses. Safety evaluators should run alongside quality evaluators, not as a separate afterthought. Human-in-the-loop evaluation — structured expert review of edge cases, borderline outputs, and safety-relevant responses that automated metrics cannot fully capture. Human judgment remains essential for interpreting context, intent, and impact. AI agent red-teaming and adversarial testing — probing the system with challenging, unexpected, or intentionally misused inputs (including prompt injection attempts and tool misuse) to surface failure modes before customers encounter them. Microsoft provides dedicated AI red teaming guidance for agent-based systems. Customer feedback loops — structured collection of real-world signals from users interacting with the system in production. Production feedback closes the gap between what was tested and what customers actually experience. Each method has a distinct role. The evaluation framework defines when and how each is applied — and which results are required before a release proceeds, a change is accepted, or a capability is expanded. Defining release criteria and ongoing quality gates Quality evaluation only drives improvement when it is connected to clear release criteria, often enforced through an LLMOps quality gate. In an LLMOps model, those criteria are automated gates embedded directly into the CI/CD pipeline, applied consistently at every stage of the release cycle. In continuous integration (CI), automated evaluations run with every change — whether that change is a prompt update, a model version, a new tool, or a data source modification. CI gates catch regressions early, before they reach customers, by validating outputs against predefined quality thresholds for task adherence, coherence, groundedness, and safety. In continuous deployment (CD), quality gates determine whether a build is eligible to proceed. Release criteria should define: Minimum acceptable thresholds for each quality dimension — a release does not proceed until those thresholds are met Known failure modes that block release outright versus those that are tracked, monitored, and accepted within defined risk tolerances Deployment constraints — conditions under which a release is paused, rolled back, or progressively expanded to a subset of users before full rollout Ongoing evaluation must be scheduled and triggered. As models, prompts, tools, and customer usage patterns evolve, the baseline shifts. LLMOps treats re-evaluation as a continuous discipline: run evaluations, identify weak areas, adjust, and re-evaluate before changes propagate. This connects directly to governance. Quality evidence — the record of what was measured, when, and against what criteria — is part of the audit trail that makes AI behavior accountable, explainable, and trustworthy over time. For more on the governance foundation this builds on, see Governing AI apps and agents for Marketplace readiness. Quality across the publisher-customer boundary Clear quality ownership reduces friction at onboarding, builds confidence during operation, and protects both parties when behavior deviates. In the Marketplace context, quality is a shared responsibility — but the boundaries are distinct. Publishers are responsible for: Designing and running the evaluation framework during development and release Defining quality dimensions and thresholds that reflect the solution's intended use Providing customers with transparency into what quality means for this solution — without exposing proprietary prompts or internal logic Customers are responsible for: Validating that the solution performs appropriately in their specific environment, with their data and their users Configuring feedback and monitoring mechanisms that surface quality signals in their tenant Treating quality evaluation as a shared ongoing responsibility, not a one-time publisher guarantee When both sides understand their role, quality stops being a handoff and becomes a foundation — one that supports adoption, sustains trust, and enables both parties to respond confidently when behavior shifts. What's next in the journey A strong quality framework sets the baseline — but keeping that quality visible as solutions scale is its own discipline. The next posts in this series explore what comes after the framework is in place: API resilience, performance optimization, and operational observability for AI apps and agents running in production environments. See the next post in the series: Designing a reliable environment strategy for Microsoft Marketplace AI apps and agents | Microsoft Community Hub. Key resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessMicrosoft Marketplace Partner Digest
April kickstarts a face-paced quarter of accelerated opportunity as partners line up new co‑sell motions and expand channel‑led sales—including resale‑enabled offers—to reach more customers across global markets, all while rapidly building and publishing transactable AI apps and agents to Microsoft Marketplace to meet growing customer demand. ✨ Microsoft Cloud AI Partner Program This month brings several important updates to Specializations and Solutions Partner designations, including revised performance criteria for the Small and Midsize Business Management specialization and new skilling options across Modern Work, Teams, and Digital & App Innovation. Microsoft is also evolving specializations to better reflect the shift toward AI—introducing the Secure AI Productivity specialization, retiring the Adoption and Change Management specialization, and preparing to merge several existing specializations into streamlined, solution‑aligned offerings. Learn more 🆕 What’s new in Partner Center MFA enforcement for Partner Center APIs Partner Center is now enforcing multifactor authentication (MFA) for all app + user API calls, with full enforcement as of April 1, 2026. Any requests made without a valid MFA token will be blocked with a 401 response and error code 900421. All APIs already support MFA, so update your systems now to avoid disruptions, strengthen security, and align with Partner Center requirements. Learn more 📈 Go-to-market with Microsoft Marketplace Microsoft has released a new collection of Azure go‑to‑market assets built specifically for SMB audiences, giving partners step‑by‑step guidance, tailored messaging, and ready‑to‑use materials to drive demand in a rapidly expanding market projected to surpass $1 trillion by 2030. This content library equips distributors, resellers, and service providers with everything needed to engage SMB customers at scale—from solution plays and sales resources to campaign‑ready materials—helping partners build pipeline, deepen customer conversations, and grow recurring cloud revenue. Partners can explore the full Azure SMB content collection to activate these assets in upcoming campaigns and accelerate their cloud practice growth. Explore resources to engage Azure SMB customers Reduced Microsoft Dragon Copilot pricing Partners can now access a full library of Dragon Copilot training and go‑to‑market resources, including sales pitch decks, messaging and positioning guides, demo materials, FAQs, data sheets, infographics, and more—each with detailed descriptions to help teams understand how and when to use them. These materials are designed to help Dragon Copilot partners confidently market, sell, and support the solution with consistent, enterprise‑ready content. Access Dragon Copilot partner assets Plus, new Microsoft Dragon Copilot partner resources Additionally, Microsoft has announced a reduced list price for the Dragon Copilot per‑user license, effective May 1, 2026, across all current geographies. This update simplifies pricing, expands competitiveness, and retires the separate Physician Practice offer, consolidating all capabilities into the standard license. A new per‑encounter consumption model for ambient and generative AI capabilities will also launch on May 1, making usage easier to understand and manage. Together, these changes create a more streamlined, cost‑effective path for partners to drive Dragon Copilot adoption and growth. Read the announcement Marketplace offer optimization recommendations in App Advisor Microsoft has introduced a new AI‑powered Marketplace listing optimization capability in App Advisor, giving partners instant, personalized recommendations to improve the clarity, quality, and discoverability of their public Marketplace listings. The tool evaluates listings across six key categories—from value proposition to grammar—and provides targeted guidance aligned with Marketplace best practices, helping partners iterate faster without manual review cycles. Available free and on demand in the US, this capability enables continuous optimization so partners can strengthen engagement, improve search visibility, and stand out in an increasingly competitive catalog. Get recommendations for your Marketplace offer 💡Stay up to date with regular Partner Center announcements 📅 Marketplace events The Marketplace trainings and events calendar is updated with new trainings, live demos, and partner‑focused sessions designed to help software companies and channel partners accelerate co‑sell, private offers, and Marketplace‑first sales growth. Catch up on recent webinars and register for upcoming events that break down proven strategies, best practices, and highlight tools and resources to strengthen your Marketplace motions. Recent events Why Azure belongs in your multi-cloud strategy April 2, 2026 This event helps Marketplace‑aligned software companies understand why incorporating Azure into their multi-cloud strategy can boost customer acquisition, deal velocity, and co‑sell success. Partners will hear how to replicate solutions for Azure, tap into Microsoft funding programs, leverage tools that speed time‑to‑market, and convert modernization efforts into sustained Marketplace growth 🎥 Watch the recording Upcoming events Seamless private offers: From creation to purchase and activation April 15, 2026 (8:30 AM PDT) Next week’s session with Stephanie_Brice and Chr_Brown will provide partners an end‑to‑end look at how to execute seamless private offers—from creating them in Partner Center to extending them across channel‑led sales motions such as multiparty private offers, CSP private offers, all the way through customer purchase and activation. With a live demo, guidance on resale enabled offers and flexible billing schedules, and time for Q&A, attendees will see exactly how private offers work in practice to streamline deal execution and accelerate Marketplace business growth. Register to attend Maximize selling with Microsoft and Marketplace ROI April 28, 2026 (8:30 AM PDT) Partners will learn how to simplify their Microsoft co‑sell motions, unlock underutilized incentives, and automate manual Partner Center tasks using WorkSpan. Drawing on workflows that have powered more than $5B in co‑sell revenue, this session covers how to apply for Azure sponsorship, earn and activate Marketplace Rewards benefits, and use WorkSpan’s AI‑powered platform to drive earlier seller actions and stronger partnership execution. It’s a practical guide to capturing more value from the Microsoft ecosystem. Register to attend Revisit past sessions and see the full calendar of Marketplace community events for partners and customers. Whether you’re expanding co‑sell motions, publishing new AI‑powered solutions, optimizing private‑offer execution, or tapping into updated programs like Dragon Copilot, the opportunities to reach more customers and accelerate growth continue to expand. As always, we welcome your insights and feedback—let us know what topics you’d like to see covered in a future post so we can continue shaping this digest around what matters most to you.Governing AI apps and agents for Marketplace
Governing AI apps and agents Governance is what turns powerful AI functionality into a solution that enterprises can confidently adopt, operate, and scale—an essential part of AI governance for agents. It establishes clear responsibility for actions taken by the system, defines explicit boundaries for acceptable behavior, and creates mechanisms to review, explain, and correct outcomes over time. Without this structure, AI systems can become difficult to manage as they grow more connected and autonomous. For publishers, governance is how trust is earned—and sustained—in enterprise environments, enabling responsible AI operations. It signals that AI behavior is intentional, accountable, and aligned with customer expectations, not left to inference or assumption. As AI apps and agents operate across users, data, and systems, risk shifts away from what a model can generate and toward how its behavior is governed in real‑world conditions. Marketplace readiness reflects this shift, defined less by raw capability and more by control, accountability, trust, and adherence to AI compliance standards for publishing. You can always get a curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. What governance means for AI apps and agents Governance in AI systems is operational and continuous. It is not limited to documentation, checklists, or periodic reviews — it shapes how an AI app or agent behaves while it is running in real customer environments. For AI apps and agents, governance spans three closely connected dimensions: Policy What the system is allowed to do, what data it is allowed to access, what is restricted, and what is explicitly prohibited. Enforcement How those policies are applied consistently in production, even as context, inputs, and conditions change. Evidence How decisions and actions are traced, reviewed, and audited over time. Governance works when intent, behavior, and proof move together — turning expectations into outcomes that can be trusted and examined. These dimensions are interdependent. Policy without enforcement is aspiration. Enforcement without evidence is unverifiable. Governance in action Governance becomes real when responsibility is explicit. For AI apps and agents, this starts with clarity around who is responsible for what: Who the agent acts for — and how its use protects business value Ensuring the agent is used for its intended purpose, produces measurable value, and is not misused, over‑extended, or operating outside approved business contexts. Who owns data access and data quality decisions Governing how the agent consumes and produces data, whether access is appropriate, and whether the data used or generated is reliable, accurate, and aligned with business and integrity expectations. Who is accountable for outcomes when behavior deviates Defining responsibility when the agent’s behavior creates risk, degrades value, or produces unexpected outcomes — so corrective action is timely, intentional, and owned. When governance is left vague or undefined, accountability gaps surface and agent actions become difficult to justify and explain across the publisher, the customer, and the solution itself. In this model, responsibility is shared but distinct. The publisher is responsible for designing and implementing the governance capabilities within the solution — defining boundaries, enforcement points, and evidence mechanisms that protect business value by default. Marketplace customers expect to understand who is accountable before they adopt an AI solution, not after an incident forces the question. The customer is responsible for configuring, operating, and applying those capabilities within their own environment, aligning them to internal policies, risk tolerance, and day‑to‑day use. Governance works when both roles are clear: the publisher provides the structure, and the customer brings it to life in practice. Data governance for AI: beyond storage and access For Marketplace‑ready AI apps and agents, data governance must account for where data moves, not just where it resides. Understanding how data flows across systems, tools, and tenants is essential to maintaining trust as solutions scale. Data governance for AI apps and agents extends beyond where data is stored. These systems introduce new artifacts that influence behavior and outcomes, including prompts and responses, retrieval context and embeddings, and agent‑initiated actions and tool outputs. Each of these elements can carry sensitive information and shape downstream decisions. Effective data governance for AI apps and agents requires clear structure: Explicit data ownership — defining who owns the data and under what conditions it can be accessed or used Access boundaries and context‑aware authorization — ensuring access decisions reflect identity, intent, and environment, not just static permissions Retention, auditability, and deletion strategies — so data use remains traceable and aligned with customer expectations over time Relying on prompts or inferred intent to determine access is a governance gap, not a shortcut. Without explicit controls, data exposure becomes difficult to predict or explain. Runtime policy enforcement in production Policies are stress tested when the agent is responding to real prompts, touching real data, and taking actions that carry real consequences. For software companies building AI apps and agents for Microsoft Marketplace, runtime policy enforcement is also how you keep the system fit for purpose: aligned to its intended use, supported by evidence, and constrained when conditions change. At runtime, governance becomes enforceable through three clear lanes of behavior: Decisions that require human approval Use approval gates for higher‑impact steps (for example: executing a write operation, sending an external request, or performing an irreversible workflow). This protects the business value of the agent by preventing “helpful” behavior from turning into misuse. Actions that can proceed automatically — within defined limits Automation is earned through clarity: define the agent’s intended uses and keep tool access, data access, and action scope anchored to those uses. Fit‑for‑purpose isn’t a feeling — it’s something you support with defined performance metrics, known error types, and release criteria that you measure and re‑measure as the system runs. Behaviors that are never permitted — regardless of context or intent Block classes of behavior that violate policy (including jailbreak attempts that try to override instructions, expand tool scope, or access disallowed data). When an intended use is not supported by evidence — or new evidence shows it no longer holds — treat that as a governance trigger: remove or revise the intended use in customer‑facing materials, notify customers as appropriate, and close the gap or discontinue the capability. To keep runtime enforcement meaningful over time, pair it with ongoing evaluation: document how you’ll measure performance and error patterns, run those evaluations pre‑release and continuously, and decide how often re‑evaluation is needed as models, prompts, tools, and data shift. This is what keeps autonomy intentional. It allows AI apps and agents to operate usefully and confidently, while ensuring behavior remains aligned with defined expectations — and backed by evidence — as systems evolve and scale. Auditability, explainability, and evidence Guardrails are the points in the system where governance becomes observable: where decisions are evaluated, actions are constrained, and outcomes are recorded. As described in Designing AI guardrails for apps and agents in Marketplace, guardrails shape how AI systems reason, access data, and take action — consistently and by default. Guardrails may be embedded within the agent itself or implemented as a separate supervisory layer — another agent or policy service — that evaluates actions before they proceed. Guardrail responses exist on a spectrum. Some enforce in the moment — blocking an action or requiring approval before it proceeds — while others generate evidence for post‑hoc review, supported by audit logging for AI agents. Marketplace‑ready AI apps and agents could implement both, with the response mode matched to the severity, reversibility, and business impact of the action in question. These expectations align with the governance and evidence requirements outlined in the Microsoft Responsible AI Standard v2 General Requirements. In practice, guardrails support auditability and explainability by: Constraining behavior at design time Establishing clear defaults around what the system can and cannot do, so intended use is enforced before the system ever reaches production. Evaluating actions at runtime Making decisions visible as they happen — which tools were invoked, which data was accessed, and why an action was allowed to proceed or blocked. When governance is unclear, even strong guardrails lose their effectiveness. Controls may exist, but without clear intent they become difficult to justify, unevenly applied across environments, or disconnected from customer expectations. Over time, teams lose confidence not because the system failed, but because they can’t clearly explain why it behaved the way it did. When governance and guardrails are aligned, the result is different. Behavior is intentional. Decisions are traceable. Outcomes can be explained without guesswork. Auditability stops being a reporting exercise and becomes a natural byproduct of how the system operates day to day. Aligning governance with Marketplace expectations Governance for AI apps and agents must operate continuously, across all in‑scope environments — in both the publisher’s and the customer’s tenants. Marketplace solutions don’t live in a single boundary, and governance cannot stop at deployment or certification. Runtime enforcement is what keeps governance active as systems run and evolve. In practice, this means: Blocking or constraining actions that violate policy — such as stopping jailbreak attempts that try to override system instructions, escalate tool access, or bypass safety constraints through crafted prompts Adapting controls based on identity, environment, and risk — applying stricter limits when an agent acts across tenants, accesses sensitive data, or operates with elevated permissions Aligning agent behavior with enterprise expectations in real time — ensuring actions taken on behalf of users remain within approved roles, scopes, and approval paths These controls matter because AI behavior is dynamic. The same agent may behave differently depending on context, inputs, and downstream integrations. Governance must be able to respond to those shifts as they happen. Runtime enforcement is distinct from monitoring. Enforcement determines what is allowed to continue. Monitoring explains what happened once it’s already done. Marketplace‑ready AI solutions need both, but governance depends on enforcement to keep behavior aligned while it matters most. Operational health through auditability and traceability Operational health is the combination of traceability (what happened) and intelligibility (how to use it responsibly). When both are present, governance becomes a quality signal customers can feel day to day — not because you promised it, but because the system consistently behaves in ways they can understand and trust. Healthy AI apps and agents are not only traceable — they are intelligible in the moments that matter. For Marketplace customers, operational trust comes from being able to understand what the system is intended to do, interpret its behavior well enough to make decisions, and avoid over‑relying on outputs simply because they are produced confidently. A practical way to ground this is to be explicit about who needs to understand the system: Decision makers — the people using agent outputs to choose an action or approve a step Impacted users — the people or teams affected by decisions informed by the system’s outputs Once those stakeholders are clear, governance shows up as three operational promises you can actually support: Clarity of intended use Customers can see what the agent is designed to do (and what it is not designed to do), so outputs are used in the right contexts. Interpretability of behavior When an agent produces an output or recommendation, stakeholders can interpret it effectively — not perfectly, but reasonably well — with the context they need to make informed decisions. Protection against automation bias Your UX, guidance, and operational cues help customers stay aware of the natural tendency to over‑trust AI output, especially in high‑tempo workflows. This is where auditability and traceability become more than logs. Well governed AI systems should still answer: Who initiated an action — a user, an agent acting on their behalf, or an automated workflow What data was accessed — under which identity, scope, and context What decision was made, and why — especially when downstream systems or people are affected The logs should show evidence that stakeholders can interpret those outputs in realistic conditions — and there is a method to evaluate this, with clear criteria for release and ongoing evaluation as the solution evolves. Explainability still needs balance. Customers deserve transparency into intended use, behavior boundaries, and how to interpret outcomes — without requiring you to expose proprietary prompts, internal logic, or implementation details. For more information on securing your AI apps and agents, visit Securing AI apps and agents on Microsoft Marketplace | Microsoft Community Hub. What's next in the journey Governance creates the conditions for AI apps and agents to operate with confidence over time. With clear policies, enforcement, and evidence in place, publishers are better prepared to focus on operational maturity — how solutions are observed, maintained, and evolved safely in production. The next post explores what it takes to keep AI apps and agents healthy as they run, change, and scale in real customer environments. See the next post in the series: Quality and evaluation framework for successful AI apps and agents in Microsoft Marketplace | Microsoft Community Hub. Key resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV Success
