isv success
257 TopicsBuild your SaaS offer with the modernized SaaS Accelerator to sell on Marketplace
Build your SaaS offer for Microsoft Marketplace with coding agent guidance and the modernized SaaS Accelerator. Explore resources that help simplify Marketplace integration and move from development to publishing faster.137Views4likes0CommentsHow software companies can reach more SMB customers through Microsoft Marketplace in the age of AI
Publishing an offer on Microsoft Marketplace creates a starting point for reaching more customers and scaling growth; the opportunity goes well beyond getting listed. For software companies, Marketplace can create a path to reach more customers and scale revenue, particularly in the SMB market. Micro, small, and medium enterprises (MSMEs) account for 90% of companies globally and 70% of the world’s employment, according to World Bank Group and International Finance Corporation (IFC) data. 1 For software companies, this creates a significant opportunity to serve small and medium businesses with solutions that fit how they operate. These businesses often have lean teams, limited procurement resources, and a preference for self-service experiences that help them evaluate, purchase, and deploy technology efficiently. The age of AI is accelerating the opportunity for software companies to reach and serve SMBs. Software companies are moving beyond a simple Marketplace listing, building AI-powered products designed for how SMBs buy, deploy, and scale today. Founded in 2002, Ntegral was a traditional systems integrator, deploying client technology solutions one contract at a time. In 2021, the company began shifting its business model from primarily delivering services to bringing its own software solutions to market through Microsoft Marketplace. At UP LIVE Reston, Ntegral’s President and CTO, Dexter Hardy, will share more about what that shift meant in practice, including how Ntegral adapted its approach to products, sales, and growth. The change expanded Ntegral’s reach. Dexter has called Microsoft Marketplace "a real game changer" for the company, which now offers 300+ enterprise solutions with deployments in more than 150 countries. 2 Dexter described Marketplace as an important part of Ntegral’s growth strategy, helping the company expand its reach while, in his words, allowing Ntegral “to stay lean, focus on our expertise,” as it entered new markets. 🎯A session worth your time Scaling reach and opportunity for SMBs Ntegral Inc.’s President and CTO, Dexter Hardy, will be onstage at Ultimate Partner LIVE Reston. The session will explore practical ways SMBs can build on their Marketplace presence to support customer reach and revenue growth. Hardy will share Ntegral’s journey from a regional systems integrator to a software company focused on developing its own solutions and reaching customers globally through Marketplace. 💡Ntegral's point of view: Marketplace adoption in the age of AI Ntegral sees Marketplace as an important part of scaling its business, alongside a product strategy designed around the needs of SMB customers. Ntegral recently introduced Akili, its AI-powered platform designed for SMBs and consultants. Akili brings access to AI models and agent capabilities into one workspace, giving small teams and solo operators a way to use these capabilities without managing separate subscriptions. For Ntegral, that product strategy is closely connected to how the company approaches Microsoft Marketplace. Ntegral sees AI adoption and Marketplace as complementary parts of its growth strategy: developing products around the needs of small businesses while using Marketplace to reach customers and support transactions at scale. For Ntegral, Marketplace is part of a broader commercial strategy that connects product innovation with customer reach and scalable sales. At UP LIVE Reston, Dexter brings that same directness to the stage. The focus is on practical mechanics: how software companies can build on their Marketplace presence to reach more customers and develop more pipeline, how AI fits into that strategy, and what Ntegral changed operationally as its business evolved. Learn more about Akili. __________________________________________________________________________________________________________________________________________________________________ 📅 Attend UP LIVE Reston · October 26–28, 2026 Carahsoft Conference & Collaboration Center, Reston, VA 👉 Register for UP LIVE Reston 1 World Bank Group / IFC MSME Finance Factsheet 2 Ntegral | Empowering Digital and Cloud Transformations | Ntegral153Views1like0CommentsGetting first customers after publishing what actually worked for you?
I published two transactable SaaS offers earlier this month (Microsoft 365 security and compliance assessment). The technical side went fine, with good support from the ISV team. Getting the offers in front of customers is where I'm stuck. So far I've reached Rewards Tier 3 and activated the listing optimisation benefit. I understand customer references are the gate to co-sell readiness, which feels like a chicken-and-egg problem when you have none yet. For publishers further along than me: what actually produced your first few customers? Was it private offers to targeted tenants, co-sell once you had references, the Marketplace Rewards activities, or something outside the marketplace entirely? I'd rather spend my limited time on what works than keep guessing.102Views0likes0CommentsAre Shopify merchants using Dynamics 365 and Microsoft 365 Copilot a meaningful market segment?
Hi Marketplace community, We are testing a market assumption before investing further in a Microsoft 365 Copilot solution for retail loyalty operations. The solution, Loyalty Manager Copilot AI, helps teams review loyalty-program health and take bounded, reviewable actions, such as approving a win-back reward, from within a Copilot conversation. Some merchants we encounter use Shopify or Shopify Plus for the storefront, while Microsoft systems support parts of the back office. Readers who want to understand or try the current app can https://marketplace.microsoft.com/en-us/product/WA200010024. We know the technical pattern exists: Shopify at the storefront, with Dynamics 365 Business Central or other Microsoft business applications behind it. What We are trying to understand is whether the user and buying pattern is large enough to matter. For retailers using Shopify together with Dynamics 365 and Microsoft 365: Are loyalty, CRM, or marketing users working in Teams and Microsoft 365 Copilot regularly? Is Copilot adoption reaching these business roles, or is it still concentrated in IT, finance, and administration? Who usually evaluates or sponsors a cross-platform loyalty solution: the merchant, a Microsoft partner, a Shopify partner, or another stakeholder? Would an AppSource solution connecting loyalty operations to Copilot fit an established workflow, or would it require creating a new behavior? We would especially value firsthand observations from merchants, ISVs, system integrators, and Microsoft partners. We are not looking for a product pitch. We are trying to determine whether this represents a meaningful audience or a narrow edge case.Microsoft Marketplace Partner Digest - September 2026
Marketplace innovations are simplifying every stage of the customer journey. Microsoft Marketplace continues to make it easier for customers to discover, purchase, and manage the solutions that power their businesses. This month, we're highlighting new AI-powered discovery experiences that help customers find and evaluate solutions faster, innovative healthcare opportunities through Dragon Copilot Physician apps and agents, and new capabilities that support procurement, billing, and subscription management at scale. Together, these investments help reduce friction across the customer journey while creating new opportunities for partners to grow through Marketplace. ✨ Find the right solutions faster with intelligent discovery What's new Microsoft Marketplace now includes intelligent discovery, an AI-powered experience that helps customers discover, compare, and evaluate solutions using natural language rather than traditional keyword searches. Customers can describe their business needs in everyday language and receive tailored recommendations, side-by-side product comparisons, and deeper product analysis to support purchasing decisions. Key capabilities include: Use natural language to describe requirements and business goals Automatically identify relevant filters and narrow results Compare solutions side-by-side based on Marketplace metadata Explore solution details using AI-assisted product analysis Move from discovery to evaluation with greater confidence Why it matters Customers increasingly expect AI-assisted buying experiences. Intelligent discovery helps buyers navigate a growing Marketplace catalog more efficiently, reducing the time required to find relevant solutions and evaluate alternatives. This can help partners improve visibility, attract more qualified prospects, and create stronger pathways from discovery to purchase. Marketplace AI offerings continue to grow rapidly, with more than 6,500 AI apps and agents now available in the catalog. Recommended action Review your Marketplace listings to ensure product descriptions, categories, industries, use cases, and solution metadata accurately reflect the problems your solution solves. High-quality Marketplace content helps intelligent discovery surface your offerings to the right customers. 🔎 Learn more about searching and comparing products with intelligent discovery in Microsoft Marketplace ⚡ Help customers align Marketplace purchases of your products with their internal procurement and financial processes What’s new Purchase order management and spend mapping capabilities are now generally available in Microsoft Marketplace, helping organizations associate Marketplace purchases with internal procurement identifiers and financial reporting requirements. These capabilities help customers connect Marketplace transactions to purchase orders, cost centers, departments, business units, and other financial controls. Key capabilities include: Associate Marketplace purchases with purchase orders Map Marketplace spend to internal financial identifiers Improve chargeback and allocation reporting Support invoice reconciliation and procurement processes Increase visibility into Marketplace spending against budgets Why it matters Customers consistently identify invoicing, procurement integration, spend visibility, and financial governance as important considerations when scaling Marketplace purchasing. Helping customers align Marketplace transactions with existing procurement workflows can reduce operational friction and support broader Marketplace adoption. Recommended action Review customer-facing sales materials and deployment discussions to understand how purchase orders, spend mapping, and financial governance capabilities may support procurement, finance, and FinOps stakeholders during the buying process. 📍Learn more about purchase orders and allocating Marketplace spend in Azure portal 🐉Reach healthcare customers through Dragon Copilot What's new Microsoft Marketplace now supports Dragon Copilot Physician Apps and Agents, the first offer type in a planned family of Dragon Copilot offers. Available in the United States, these partner solutions can be discovered and purchased through Microsoft Marketplace, configured through the Dragon Admin Center, and surfaced directly within physician workflows in Dragon Copilot. Key capabilities include: Publish healthcare-focused apps and agents through a dedicated Marketplace offer type Reach healthcare organizations adopting Dragon Copilot and deliver capabilities directly within clinician workflows Utilize Microsoft Marketplace for commerce, discovery, and fulfillment Why it matters Healthcare organizations are looking for AI solutions that fit naturally into existing clinical workflows. Dragon Copilot Physician apps and agents give partners a scalable route to market: solutions can be purchased through Microsoft Marketplace, configured through the Dragon Admin Center, and made available directly within clinical workflows. Recommended action Evaluate whether your healthcare solution could benefit from integration with Dragon Copilot and explore the new Marketplace offer type for physician apps and agents. Learn more about Dragon Copilot Physician apps and agents Events Recent events Announcing Frontier Accelerate for Marketplace Frontier Accelerate for Marketplace is an upcoming Microsoft AI Cloud Partner Program offering that guides software development companies to build AI-powered solutions, monetize through Microsoft Marketplace, and scale revenue through Microsoft expertise, skilling, and investments. 📺 Watch the briefing now 🔗 Learn more: aka.ms/FA-for-Marketplace How leading partners drive co-sell success with Marketplace Learn how successful software companies use Microsoft Marketplace to expand reach, strengthen co-sell relationships, and drive repeatable revenue growth. Join Reis Barrie of Carve Partners for insights into building Marketplace momentum and creating co-sell opportunities across the Microsoft partner ecosystem. Watch on-demand Evaluate and buy solutions with Microsoft Marketplace Help customers evaluate and buy solutions with greater confidence. This Microsoft Marketplace session explores intelligent discovery, free trials, private offer requests, flexible contract durations, and practical ways partners and sellers can create purchasing arrangements aligned to customer priorities. Watch on-demand Upcoming events New monthly partner skilling series 📆Beginning Sept. 23, 2026, 8:00 AM and 5:00 PM PDT Microsoft is launching Partnering for Success Together, a new monthly partner skilling series designed to help partners stay up to date on Microsoft's latest investments, go-to-market priorities, and customer opportunities. Hosted through the Microsoft Partner Skilling Hub, each session provides guidance and updates across Microsoft's commercial solution areas, helping partners understand what's new and how to translate announcements into customer impact. Two live sessions will be provided at different times to accommodate global audiences. Register for the first event scheduled September 23 and add future monthly skilling events to your development plan. Register now on the Microsoft Partner Skilling Hub Microsoft co-sell playbook: From co-sell ready to close-won 📆 Wednesday, Oct 07, 2026, 8:30 AM PDT Join this partner-focused session to learn how successful organizations turn co-sell opportunities into closed-won business. Kevin Flitcroft of Spektra Systems shares proven strategies for stakeholder alignment, commercial readiness, Microsoft Marketplace positioning, and customer-focused sales execution. Get the details and add to your calendar Next steps Position your solution for AI-powered discovery The Marketplace experience continues to evolve to help customers discover, evaluate, and purchase solutions more efficiently. By improving how your solution is represented in Marketplace and taking advantage of new Marketplace capabilities, you can increase visibility, engage more qualified buyers, and accelerate growth through Microsoft's commercial ecosystem. Not sure where to start? Get guidance and recommendations through App Advisor.457Views1like0CommentsMarketplace Publishing - Email with the Certification Team
Greetings partners, fellows, and friends, Standards Core is a 2nd year ISV - we currently have 1 SaaS and 2 Office add-in listings, now working on our first Apps and agents for Microsoft 365 and Copilot ... we have submitted our first publish, can currently working to address certification details. Why am I posting this? Well, after the 1st submission, in addition to the certification report on Marketplace, we also received an email - thereafter questions/iterations were immediately interactive with very quick and clearly attentive responses. So I wanted to mention that we really appreciate that!! Previous submissions that I have experienced were through the submissions portal only - the personalized email interaction was a pleasant surprise, and made the process feel much warmer than the previous "formal" portal-only interaction. Thank you [certification team], and looking forward to re-submit shortly. Thanks again, Leon, CTO/Standards Core LLCAuto Activation for SaaS Private Offers is a Game Changer!
Shout out to Microsoft Marketplace for launching AUTO ACTIVATION for SaaS private offers. This has simplified our sales operations for Microsoft Marketplace private offers, as well as dramatically improved our seller and customer experience with by eliminating the #1 reason we've historically seen block customers from completing Marketplace SaaS private offer procurement. Auto activation for private offers allows customers to skip the step of going to our SaaS landing page and activate Marketplace SaaS billing by having to SSO with their AAD. The problem with this step is that most of our customers are in regulated industries, and their AAD admins do not allow SSO on SaaS landing pages without enabling profile sharing, which requires a Global Admin to enable. We've encountered far too many times where our customer is scrambling to find their Global Admin so that they can complete the final steps to finish the steps to activate Marketplace SaaS billing. This also puts our sellers in the awkward position of having to help customers diagnose and troubleshoot the situation, which as a rule they are not equipped to, or find a Microsoft resource to help. Now, with this new feature the whole SSO to our SaaS landing page and associated problems are eliminated. Ever since we started using it our customers' procurement experience has been faster and smoother. I'm looking forward to more improvements to the Marketplace experience! Here is the feature: https://learn.microsoft.com/en-us/partner-center/marketplace-offers/create-new-saas-offer-plans#configure-auto-activationDesign CI/CD for AI apps and agents selling through Microsoft Marketplace
In the previous post, Design observability for AI apps and agents selling through Microsoft Marketplace, we focused on observability—making AI app and agent behavior visible and explainable. Execution paths, retries, degradation patterns, and agent decisions can now be observed across environments and tenants. With that visibility in place, a new challenge emerges: how do you safely modify an AI system whose behavior you can now observe? 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. Using continuous integration/continuous delivery (CI/CD) to control AI system evolution AI apps and agents introduce numerous novel ways that production behavior can change. In addition to application code, updates to configuration, prompts, models, and guardrails, agent logic can alter execution, cost, and outcomes—often immediately and across tenants. CI/CD defines how these changes reach production. Without a structured delivery path, behavior‑shaping updates risk entering runtime without validation or recovery paths, making system behavior difficult to explain or reverse once customers encounter it. AI solutions are typically built and operated as cloud applications. Software delivery of cloud services, and the supporting components that enable it, remains part of the CI/CD pipeline, and any instability in these foundational components directly propagates into AI behavior. AI systems add two additional sources of change that require explicit control. MLOps governs model evolution. Agents introduce further variability, as agent logic and configuration evolve. CI/CD is what prevents these change vectors from interacting unpredictably across both publisher and customer environments. Core CI/CD requirements for AI apps and agents For AI apps and agents, CI/CD determines whether deployment strategies can be applied safely. Progressive rollouts, ring deployments, feature flags, and kill switches all rely on pipelines that isolate change, validate behavior, and support rollback. Observability provides insight into behavior; CI/CD controls when and how that behavior is allowed to change. CI/CD must reliably provision, configure, and promote cloud native infrastructure, including but not limited to front-end services, APIs, storage, identity, and networking across environments. Agent behavior depends directly on the stability of the platform it runs on. AI systems introduce additional CI/CD requirements through MLOps and agents. Model versions, routing logic, and evaluation configurations must move through pipelines as deployable artifacts, with isolation, validation, and rollback built in. Changes to models affect latency, cost, and outcomes even when application code remains unchanged, making promotion controls necessary at the model layer. A well-run CI/CD pipeline should positively impact AI models and agents in the following ways: Change isolation ensures code, prompts, models, and configuration evolve independently. Artifact versioning beyond code treats prompts, policies, tools, and models as release assets. Behavioral validation evaluates outcomes, constraints, and patterns rather than single responses. Safe promotion controls gate model and agent releases based on observed behavior. Rollback readiness allows fast reversion when model or agent behavior degrades. Building behavioral baselines for AI solutions using CI/CD Before an AI system is built by a pipeline, it is built by a team. CI/CD build pipelines are where these contributions are stitched together. Product managers define scope and constraints. UX designers shape how behavior is experienced. Full‑stack engineers assemble application logic. AI engineers wire reasoning and tools. Data engineers and data scientists curate data and models. In AI systems, a build does more than compile code. It captures a shared agreement across roles about what the system is expected to do. Application code, orchestration logic, prompts, configuration, guardrails, routing rules, and trained or fine‑tuned models are assembled into a single versioned artifact. That artifact represents a coordinated snapshot of intent, behavior, and constraints. This coordination must declare which models, prompts, policies, and tool definitions are included. Implicit dependencies—such as dynamically changing prompts or unpinned models—break shared understanding across teams and introduce behavior changes without acknowledgement. A successful build confirms that contributions from multiple roles are compatible and executable together. It does not decide when customers see the change. That decision belongs later, where behavior can be evaluated deliberately, enforced by build pipelines that are separating assembly from release. Testing AI solutions with CI/CD pipelines When an agent is updated, the first task is straightforward: the agent’s code changes. Logic is refined, tools are added, limits are adjusted. That change moves through the CI/CD pipeline, where it is built, packaged, and validated in isolation. At this point, the focus is narrow—does this agent compile, configure, and execute as expected? The second step widens the lens. The update now moves through testing aligned to the layers beneath it. For cloud solutions, tests confirm the platform still behaves as assumed: infrastructure provisions correctly, APIs and identity boundaries remain intact, and dependencies remain reachable. These tests ensure the environment can support execution before behavior is evaluated. Next, MLOps tests assess whether model behavior still aligns with system expectations. New model versions, routing logic, or provider changes are evaluated for cost, latency, and outcome consistency. The goal is not identical responses, but bounded behavior within known limits. Finally, testing shifts to the agentic system as a whole. Other agents need to be made aware of the new capabilities. When you go to update the agent the first job you have to do is update the agent code. The second job you have to do is to use your CI/CD pipeline to build, test and release that code. The third job is to test that the entire agentic system is running smoothly together. At this stage, testing answers a different question: not does the agent work, but does the system still work together. CI/CD release management as team coordination Once testing confirms that behavior remains within expected bounds, release management determines how changes are introduced and observed under real conditions. In AI systems, release management must reflect where change originates and how risk propagates across layers. Within the cloud services that support the AI solution, release management focuses on scope and blast‑radius control. Examples include staged rollout of infrastructure updates, controlled exposure of new API versions, and limiting configuration changes to specific environments or tenants before going global. These steps allow both publisher and customer teams to observe stability and dependency behavior under load. For MLOps, release management governs behavioral shifts introduced by model changes. Common patterns include routing a small percentage of requests to a new model version, limiting exposure to specific customer segments, or restricting usage to defined request types. This allows teams to compare cost, latency, and outcome patterns before expanding exposure. For agents, release management controls how new behaviors surface. Prompt updates, tool access changes, or guardrail adjustments may be released to specific workflows, tenants, or traffic slices. This makes it possible to observe planning depth, retry behavior, and termination patterns without affecting all users simultaneously. Rollback readiness remains essential. Release paths must allow fast reversion using version pinning or traffic shifting rather than full redeployment. Release management creates space to observe, adjust, and respond before changes reach full Marketplace scale. Deployment as a shared boundary Effective deployment pipelines ensure that software, models, and agent behavior enter production together, with changes explicitly acknowledged and observable. Versioning and rollback remain available, but deployment defines the moment when coordinated decisions become customer‑visible. Cloud service—For the software, deployment governs application code and supporting platform changes. These remain necessary foundations. Application binaries, infrastructure templates, runtime configuration, and orchestration must enter production in a known, versioned state so operational behavior can be correlated with specific changes. MLOps—Model version updates, routing rules, provider switches, and evaluation configurations can change system behavior without modifying application code. Deployment pipelines must therefore treat these artifacts as deployable units, subject to the same versioning, promotion, and rollback mechanics as software releases. Agent—Deployment includes behavior‑defining inputs such as prompts and system messages, tool definitions and permissions, guardrails, and execution limits. Changes directly affect how agents plan, execute, and terminate work. Allowing these inputs to change outside deployment pipelines breaks traceability and weakens accountability across teams. How CI/CD best practices positively impact marketplace readiness Customers expect updates to arrive in predictable ways. They expect that behavior changes can be explained, that issues can be reversed without prolonged disruption, and that outcomes remain consistent across trials and production use. CI/CD pipelines make these expectations achievable by ensuring changes are versioned, staged, and observable as they move through environments. Reliability depends on limiting how far unstable behavior propagates. Billing accuracy depends on knowing when changes alter execution paths, token usage, or metering logic. Compliance depends on being able to identify which versions of software, models, and agent configurations were active at a given time. Offer type shapes how CI/CD is applied. For transactable SaaS offers, CI/CD operates entirely within the publisher’s environment. For container offers and Azure Managed Applications, deployment boundaries extend to customer environments requiring a CI/CD hand-off between publisher and customer pipelines. Publisher CI/CD responsibilities for AI solutions Publishers must define what constitutes a deployable change. Updates to software, models, prompts, agent configuration, guardrails, or limits should not enter customer environments or generally available code implicitly. Each change that can influence behavior must flow through the publisher’s CI/CD pipelines so it can be versioned, observed, and reversed if necessary. Additionally, CI/CD pipelines require validation and approval before promotion, ensuring that behavior‑altering updates do not reach customers without visibility or control. Publishers are also responsible for communicating behavior changes. Customers should be able to understand when updates affect outcomes, performance, or cost profiles. Customers should never experience silent behavior shifts, undocumented updates, or releases that cannot be recovered cleanly. When those occur, trust erodes quickly. In this context, CI/CD is part of how publishers establish reliability, accountability, and trust with Marketplace customers. Customer’s responsibility: CI/CD across environments (Dev / Stage / Prod) While publishers own CI/CD pipelines, customers play an important role in how AI systems are evaluated and adopted across environments. AI behavior often manifests differently across Dev, Stage, and Prod because operating conditions change as systems move toward real usage. As environments scale, dependency interactions increase, traffic patterns diversify, and tenant behavior becomes less predictable—revealing execution paths and constraints that are not exercised earlier. These differences affect how behavior appears during evaluation and rollout. To keep behavior interpretable across environments, pipeline structure matters. CI/CD pipelines, validation steps, and promotion criteria should operate consistently so signals observed earlier can be understood later. When these mechanics diverge between environments, it becomes difficult to attribute changes in behavior to specific updates or conditions. Staging environments serve as a behavioral proving ground. They allow customers to observe retries, limits, degradation paths, and cost behavior under conditions that more closely resemble production. Trials often run against production‑like configurations, which means CI/CD gaps surface early. When behavior differs from expectations, the consistency of pipelines determines how quickly teams can diagnose and respond. What’s next in the journey With CI/CD establishing control over how AI systems change, the next focus is how those changes are introduced safely at runtime. The following posts cover deployment strategies, progressive rollouts, and operational patterns that allow AI apps and agents to evolve while remaining stable, observable, and ready for Marketplace scale. 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 Success300Views0likes0CommentsDesign 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 Success369Views1like0CommentsHow 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.240Views1like3Comments