Build observability for scalable AI apps and agents selling through Microsoft Marketplace
Discover how to design observability for AI apps and agents selling through Microsoft Marketplace. This Marketplace Community article explains why visibility into execution behavior is essential for operating AI systems confidently at scale—not just keeping them running. As AI apps and agents reason, branch, retry, and exit dynamically at runtime, traditional infrastructure metrics fall short. Behavioral signals such as execution flow, token usage, latency, and failure patterns help explain what systems are doing, why outcomes occur, and how limits and safeguards shape behavior across tenants and environments. Learn how observability turns runtime telemetry into clarity that supports customer trust, usage‑based billing, and scalable operations. Read more: Design observability for AI apps and agents selling through Microsoft MarketplaceUpdates to Teamwork Deployment specialization: View new name and requirements
Starting April 29, 2026, Microsoft is renaming the Teamwork Deployment specialization as the Secure AI Productivity specialization to reflect the increased focus on the secure foundations required for successful AI adoption. Additionally, the performance, skilling, and Solutions Partner designation requirements will be updated to better align with foundational workloads from Microsoft 365 E3 and the realities of modern AI adoption. These updates expand the workloads included in the specialization and refresh requirements to reflect the skills partners need to deploy, secure, and scale AI‑powered collaboration. Additionally, partners will be required to hold both the Modern Work designation and the Security designation to earn the Secure AI Productivity specialization. Partners currently enrolled in the specialization will need to meet these updated requirements at their next renewal if it occurs after April 29, 2026. Learn moreFirm AI for professional services: governed, agentic workflows built on Microsoft Azure
In this installment of our Partner Spotlight series, we’re highlighting partners building industry-focused AI solutions and bringing them to customers through Microsoft Marketplace. I connected with Richard Baskerville from Intapp to learn how the company is delivering Firm AI—governed, agentic capabilities designed specifically for professional and financial services firms—while aligning with Microsoft Azure for security, scale, and enterprise procurement. Intapp’s approach shows what it looks like to pair deep vertical workflow expertise with a trusted cloud platform so customers can adopt AI in a way that is both practical and accountable. About Richard Baskerville Richard Baskerville is a Senior Director at Intapp, where he helps shape strategic AI alliances across the Microsoft ecosystem and beyond. _______________________________________________________________________________________________________________________________________________________________ [JR] Tell us about Intapp. What inspired the founding of the company, and what problems do your solutions help customers solve? [RB] Intapp was founded on a durable observation: professional firms—law firms, accounting practices, private capital firms, and investment banks—operate differently than general enterprises. Their workflows are shaped by client relationships, professional obligations, and regulatory requirements that generic software was never designed to handle. Our founders saw that these firms were either building bespoke systems at enormous cost or forcing themselves into enterprise tools that didn’t fit. Today, Intapp delivers Firm AI—governed AI purpose-built for professional services. Our solutions span the full firm lifecycle: business development through Intapp DealCloud, time capture and billing through Intapp Time, and risk and compliance management across Intapp Conflicts, Intake, Terms, Walls, and Employee Compliance. Underpinning it all is Intapp Celeste, our agentic AI platform, which puts AI to work on the specific workflows that drive firm performance—while keeping humans accountable and in control. For firms where every engagement carries professional liability, that governance layer isn’t a feature; it’s the foundation. [JR] What industries or types of organizations do you primarily serve today? [RB] Intapp serves professional and financial services firms exclusively. That focus is intentional—and it’s what makes us different. Our customers are law firms, accounting and consulting practices, investment banks and advisory firms, private capital managers, and real assets firms. Many are among the largest in their categories globally. These firms share characteristics that set them apart from general enterprises: partnership structures, billable-hour economics, client conflict management, regulatory oversight, and relationship networks spanning decades. Generic CRM or ERP tools aren’t built for these dynamics. Intapp is. That vertical depth—built over more than 20 years—is what Firm AI means in practice: AI that understands the context of a law firm partner’s client obligations or a dealmaker’s fund-level requirements, not just the general shape of business software. [JR] What were your initial expectations for Microsoft Marketplace when you first started your journey? [RB] Our initial expectation was straightforward: Marketplace would give us a cleaner path to transact with customers already operating inside the Microsoft ecosystem. Many of our customers—large law firms and financial services firms—had already committed significant Azure spend through enterprise agreements. Marketplace offered a way to meet them commercially where they already were. What we underestimated was how much Marketplace would shape the broader partnership. We went in expecting a distribution channel. What we found was a framework that connected co-sell, Azure consumption alignment, and joint go-to-market in ways that changed how our teams engaged. The commercial mechanics—particularly MACC drawdown eligibility—became a real conversation-opener with procurement and finance stakeholders, not just a contract path. [JR] What applications do you have available in Microsoft Marketplace, and how do they help customers? [RB] Intapp has 12 SaaS solutions available in Microsoft Marketplace today, transacted via private offers. They span the full professional services firm lifecycle—from relationship intelligence and deal management with Intapp DealCloud, to time capture with Intapp Time, to risk and compliance management across Intapp Conflicts, Intake, Terms, Walls, and Employee Compliance. Because we focus exclusively on professional and financial services, customers aren’t buying horizontal software adapted for their industry; they’re buying solutions designed for their workflows, compliance obligations, and client structures. Looking ahead, Intapp Celeste—our agentic AI platform—will be available in Marketplace via a consumption-based, metered model. That structure matches how agentic AI gets used: variably, tied to real firm activity, and governed end-to-end. [JR] What were the biggest lessons you learned early on when selling through Marketplace? [RB] Three lessons stood out early: Listing is the beginning, not the end. Initial traction required deliberate investment in co-sell enablement—ensuring Microsoft field teams could position Intapp clearly, not just point to a catalog entry. Specificity wins. Our customers are sophisticated buyers. What worked was leading with vertical relevance—speaking directly to the compliance requirements of a law firm or the relationship-data challenges of a private capital manager. Private offers require commercial fluency. Helping customers understand how Intapp maps to Azure commitments—and helping Microsoft sellers tell that story—made a material difference in deal velocity. [JR] How has your business changed with a transactable offer on the Marketplace? [RB] Transactable offers have changed how deals close. Customers with existing Azure commitments can apply Intapp spend against their MACC, removing a procurement obstacle that previously added months to cycles. Finance and procurement can work within familiar Microsoft frameworks rather than running separate vendor onboarding. Marketplace has also expanded our reach. Microsoft’s field organization has relationships we can’t replicate at scale, and co-sell has helped translate that reach into qualified pipeline—especially in segments where we previously had limited coverage. And the signal matters: being transactable in Marketplace reinforces that Intapp is an enterprise-grade partner, not a niche point solution. [JR] How has collaborating with Microsoft sellers impacted your Marketplace growth? [RB] Microsoft sellers are the activation mechanism for our Marketplace offers. Without field alignment, a listing is a catalog entry. With it, it becomes a joint pipeline motion. We’ve invested in enablement—giving sellers the vertical context to position Intapp credibly in front of legal and financial services CIOs, and making it easy to bring us into deals where Azure capabilities are already in the conversation. That alignment shows up in specific segments. In private capital and investment banking, Microsoft enterprise relationships often predate ours—co-sell provides warm introductions backed by a trusted infrastructure partner. In legal, where Microsoft 365 is near-universal, that adjacency and deep interoperability creates natural entry points. Co-sell turns those adjacencies into active pipeline rather than theoretical opportunity. [JR] What has made the co-sell relationship with Microsoft particularly valuable for Intapp? [RB] Co-sell works because it’s structurally aligned, not just commercially convenient. Microsoft’s investment in these verticals—through industry clouds, compliance frameworks, and dedicated field teams—maps directly onto Intapp’s customer base. We’re selling into the same firms, with the same platform expectations underpinning both offerings. What makes it particularly valuable is the mutual trust transfer. Firms hold Microsoft to a high standard for security, data governance, and regulatory compliance. When Microsoft sellers bring Intapp into the conversation, that credibility extends to us and compresses the trust-building phase of an enterprise cycle—especially in regulated industries. [JR] How does Microsoft Marketplace fit into Intapp’s long-term growth strategy? [RB] Marketplace is central to how we scale Firm AI globally. Our ambition is to be the governed AI platform of record for professional firms across legal, private capital, accounting, and advisory. Helping customers decrement MACC through Marketplace purchases is a clear win-win because it aligns platform investment with workflow outcomes. The upcoming Marketplace availability of Intapp Celeste which will offer different commercial models for customers (e.g. consumption based) marks the next phase. As Celeste deepens integration with Microsoft 365, Teams, and Azure AI services, the commercial and technical stories converge—customers can both buy and operate within an architecture where Firm AI and Microsoft’s platform reinforce each other. [JR] What advice would you give other SDCs who are just starting their Microsoft Marketplace journey? [RB] Three things matter most early on: Earn the co-sell relationship before you need it. Invest in enablement early so Microsoft sellers have enough vertical context to represent your value clearly. Get your commercial model right for the channel. Understand how private offers interact with Azure commitments, and plan for consumption-based pricing where it fits AI usage. Lead with a sharp point of view. The partners who gain traction fastest are the obvious choice for a specific industry workflow or problem—know what that is and communicate it consistently. _______________________________________________________________________________________________________________________________________________________________ Closing reflection Intapp’s Marketplace journey shows that industry-specific, governed AI wins when it’s paired with an enterprise platform customers already trust. By making solutions transactable—especially through private offers that align to customer’s existing Azure commitments—Intapp reduces procurement friction and accelerates adoption. And like many successful partners, their growth ultimately comes down to enablement: clear vertical messaging and tight co-sell alignment that turns Marketplace presence into a real, qualified pipeline.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. 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. 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. 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 operate with 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. 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 SuccessAPI resilience and reliability patterns for AI apps and agents selling through Microsoft Marketplace
Why API resilience is a Marketplace readiness requirement The previous post Design Predictable AI Performance for Apps Selling Through Microsoft Marketplace showed how to design systems that behave predictably when things go right. This post focuses on what happens when they do not. Imagine an enterprise customer launching a trial of your AI agent from Microsoft Marketplace. The first few interactions work beautifully. Then a more complex request triggers a multi‑step agent workflow: retrieval, enrichment, validation, approval. One downstream API stalls for just long enough to push the workflow beyond its timeout. The agent retries. The retry fans out into additional calls. Tokens burn. Costs rise. Eventually the entire interaction fails ambiguously. From the customer’s perspective, the trial just “didn’t work” with no explanation or architecture diagram. Just a stalled agent and decreased confidence. AI apps and agents treat APIs as their execution backbone. Every model invocation, tool call, retrieval query, and workflow step depends on APIs behaving within expected bounds. Solutions with a single unstable dependency can affect many tenants simultaneously. 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. How AI and agentic workloads stress APIs differently Traditional API platforms often assume linear, predictable request patterns. One request in, one response out. AI apps produce bursty, non‑linear traffic shaped by user behavior, token budgets, and inference variability. Agents amplify this further. A single user request may trigger planning, branching logic, parallel tool calls, and dynamic retries—all before returning a result. Single‑turn inference calls tend to be synchronous and bounded. Agent workflows may run for minutes, traverse multiple services, and consume tokens unpredictably depending on intermediate outcomes. Happy‑path assumptions break down quickly. Reliability also compounds mathematically. If you chain five APIs, each with 99.9% availability, the composite reliability drops to roughly 99.5%. Add retries without bounds, and the system can degrade traffic rather than absorb failure. For AI systems, reliability must be defined across multiple dimensions: Availability: Are dependencies reachable? Timeout behavior: How long will the system wait? Error propagation: What information crosses boundaries? Recovery safety: Can operations be retried without harm? Data access and integrity: Is contextual data available, relevant, and trustworthy? Defining reliability for AI systems Reliability becomes the mechanism that preserves trust when uncertainty appears. Reliability in AI systems is more than “the model didn’t fail.” That framing is incomplete. True reliability means providing predictable behavior under partial failure, bounding execution when dependencies degrade, and failing clearly, safely, and consistently instead of unpredictably. For publishers providing AI solutions on Marketplace, this includes protecting customers from ambiguous states—workflows that half‑complete, retries that silently multiply costs, or agents that continue planning after their assumptions are no longer valid. Designing resilient API boundaries The shift toward reliable AI systems starts with how you think about API boundaries. In this context, an API boundary is the line where responsibility changes—between your app and a dependency, between orchestration and execution, or between your system and a customer‑ or partner‑owned service. These boundaries are deliberate points of control. You must decide: how long is a call allowed to run? What happens if it fails? Is a retry safe, and if so, how many times? When agents assume that APIs will be reliable, fast, or always available, failure starts becoming systemic. Well‑designed API boundaries stop execution early when reliability assumptions break. Explicit timeouts keep your system from waiting indefinitely when a dependency slows or an API call hangs. Bounded retries allow brief recovery without inflating cost, load, or complexity. Together, these constraints help your system behave predictably, even under stress. This is where your enforcement layers come into focus. For many Marketplace solutions, Azure API Management is where you turn design intent into predictable behavior. At this boundary, you define how your system responds under pressure—how much traffic is allowed, how tokens are budgeted, and how long requests are permitted to run. These policies give you a steady way to shape execution across tenants, even when the systems behind the boundary behave unpredictably. As workflows grow more complex, orchestration layers such as Azure Durable Functions or Logic Apps carry that intent forward. They give you a way to manage long‑running or multi‑step operations explicitly, with clear execution limits, defined retry behavior, and compensating actions when steps fail so you can keep control over how work progresses and how it concludes. Core API resilience patterns for AI apps and agents Several foundational patterns appear repeatedly in resilient AI solutions published on Marketplace. Timeouts and deadline propagation ensure no call waits indefinitely. For AI workloads, these limits should be token‑aware—longer prompts or higher‑cost models require proportional constraints. Deadlines should propagate across calls so upstream services remain informed. Bounded retries protect against transient failures but with pre-defined limits and quotas. In agent workflows, retries should be explicit, counted, and observable. Retrying API calls that execute actions, attempt and fail authentications, or create updates that exceed quotas can lead to runaway failures. Circuit breakers prevent cascading failure by opening when error rates exceed thresholds. Unlike guardrails—which enforce policy by intent—circuit breakers react to system state by pausing execution paths that are no longer reliable. Azure API Management and resilience libraries such as Polly in .NET provide practical implementations. Bulkheads isolate high‑risk or high‑cost operations. Separate concurrency pools, queues, or compute tiers prevent one tenant or workflow from consuming disproportionate resources. This is especially critical for expensive reasoning paths or third‑party dependencies. Idempotency keeps retries safe by ensuring that repeating the same request produces the same result. Agents that take real‑world actions—creating records, approving workflows, triggering payments—must attach idempotency keys so repeat attempts do not multiply side effects. Together, these patterns do not eliminate failure. They contain it. Agent‑specific reliability risks and mitigations Agent autonomy shifts how reliability behaves in practice. Agents change the shape of failure. Because they plan, reason, and act across multiple steps, a single issue rarely stays isolated. When autonomy increases, failures affect more of the workflow and do so faster. Most agent failures fall into two categories and treating them the same way creates instability. Tool failures occur when an external dependency slows, times out, or becomes unavailable. An API may reject a request, enforce a quota, or fail temporarily. These failures require containment. Your system should pause execution, apply fallback behavior, or exit cleanly once limits are reached. Allowing the agent to keep calling tools under these conditions increases cost and load without improving results. Planning failures occur when the agent’s reasoning breaks down. The plan itself is flawed, incomplete, or loops without converging on an outcome. These failures require correction. Step limits, loop detection, and execution caps keep planning from expanding indefinitely and signal when the system should stop and reassess. Making this distinction explicit is what keeps agent behavior predictable. You define how far execution can go—how many steps are allowed, how long a request may run end‑to‑end, and when the system should pause or conclude. By enforcing these limits outside the model, you give agents room to reason while your system provides the structure that contains failure and keeps execution steady as conditions change. As explored in Designing AI Guardrails for Apps and Agents in Microsoft Marketplace, guardrails define what an agent is allowed to do. Resilience patterns determine how your system holds up when dependencies degrade. Together, they enable agents that feel capable and autonomous while remaining stable, bounded, and ready for Marketplace scale. Reliability across external and third‑party APIs Marketplace AI apps rarely operate in isolation. They depend on customer‑owned systems, partner services, SaaS platforms, and external LLM APIs—each with different SLAs and failure modes. Publishers must absorb this variability rather than pass it directly to customers. That means handling throttling gracefully, surfacing authentication failures clearly, and isolating quota exhaustion. Token‑based rate limiting via Azure API Management is especially important for downstream LLM calls, where cost and availability intersect. Remember the SLA math: your effective reliability is the product of every dependency. Designing for the weakest link protects customer perception—and your own margins. Environment‑aware reliability validation As outlined in Designing a reliable environment strategy for Microsoft Marketplace, environment strategy underpins reliable promotion and confident scaling. Reliability cannot be tested only in production. Before Marketplace submission, failure behavior should be validated in staging. Timeouts should trigger as expected. Retries should stop when designed to stop. Circuit breakers should open—and close—predictably. Equally important is environment consistency. Dev, Stage, and Prod environments should enforce the same resilience policies, even if scale differs. Otherwise, failures will appear only when customers are watching. Azure Chaos Studio provides controlled fault injection to test these scenarios intentionally. The goal is to confirm that systems behave consistently under stress. Reliability, ownership, and Marketplace readiness As a publisher, you are responsible for resilient defaults, protection against cascading failures, predictable failure modes, and documented service expectations. Customers, in turn, remain responsible for the reliability of their downstream systems, environment‑level scaling, and internal monitoring. When this boundary is explicit, teams know where responsibility sits and how to respond when conditions change. When ownership is unclear, support escalations increase, accountability blurs, and confidence drops on both sides. Marketplace customers expect clarity about what your solution controls, what it depends on, and how issues are handled when they arise. That clarity directly shapes Marketplace readiness. Reliable execution paths influence certification reviews, determine whether enterprise pilots progress, and establish long‑term operational confidence. During trials, predictable behavior feels professional. It reduces surprise costs, shortens evaluation cycles, and makes adoption decisions easier. In this way, reliability acts as a trust signal and a sales enabler. When customers see that ownership is well-defined and failure is handled intentionally, AI adoption through Marketplace feels safe, bounded, and ready to scale. What’s next in the journey Once execution paths are resilient, your solution’s behavior becomes visible. Circuit breaker transitions, retry frequency, timeout events, and error propagation turn into operational signals that show how your AI app or agent behaves under real load and across customer tenants. This foundation enables the next layer of operational maturity—observability, safe deployment practices, CI/CD for agents, and ongoing evaluation—so you can understand behavior end‑to‑end and operate confidently as usage grows. Reliability makes AI adoption safe; observability makes it sustainable. 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 SuccessDesign predictable AI performance to scale selling through Microsoft Marketplace
Trade-offs in AI performance: latency, quality and cost Imagine a software company launches a customer trial for its new AI assistant through Microsoft Marketplace. The trial begins smoothly — until more complex queries take longer than a few seconds to return a response. The cause isn’t model failure. It’s an unbounded Retrieval‑Augmented Generation (RAG) pipeline retrieving 50 documents per query before synthesizing an answer. Latency increases. Runtime token usage expands. Trial‑stage infrastructure cost rises immediately. This exposes the core runtime tradeoff in enterprise AI systems: Latency ↔ Quality ↔ Cost Improving response quality often increases retrieval depth. Increasing retrieval depth expands token usage. Expanded token usage drives both cost and latency upward. 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. You can always get curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. How traditional cost model assumptions break down for AI In classic software models, you expect predictable runtime costs such as license allocations, storage, compute time, bandwidth consumption, etc. But in AI-powered systems, that stability gives way to new complexities driven by token-based cost structures. These costs scale in unexpected ways, depending on the length of generated outputs, the depth of information retrieval, the number of reasoning steps an agent performs, and how often external tools are invoked. Consider the RAG pipeline scenario: retrieving five documents for a single query might create a 3,000-token prompt. If the pipeline instead pulls 50 documents, that prompt balloons to 15,000 tokens—before the AI even begins to infer an answer. And the unpredictability doesn’t stop there. Agent orchestration can introduce even more variability. Planning steps may stretch or shrink depending on the query, tool-calling systems might retry failed executions multiple times, and multi-branch workflows can run in parallel, all amplifying token consumption and cost. Keep costs bounded without sacrificing quality While unpredictable token usage and orchestration steps can quickly escalate infrastructure costs in AI-powered systems, design choices can prevent runaway expenses without compromising the quality of responses. To achieve this, engineers must balance procurement expectations set by pricing with real-time operational controls. For instance, use a multi-model tiered routing strategy to allow less complex queries to be handled by lightweight models, reserving advanced reasoning models for more demanding tasks. Combining this with token budgeting strategies—such as per-session caps and API Management token-limit policies—ensures that each interaction remains within defined boundaries. Cost-aware orchestration paths become essential when running AI workloads across multiple tenants, especially when retries and multi-branch workflows threaten to multiply inference consumption. By calibrating runtime guardrails to performance and cost signals, AI systems can be designed to fail gracefully and predictably, preventing ambiguous and expensive failures. Ultimately, the goal is to deliver high-quality results at scale, maintaining control over both costs and performance as usage grows. Achieving predictable latency: Business best practices across each layer For enterprise AI systems, ensuring fast and consistent response times—while balancing quality and cost—is a top priority. Predictable latency requires intentional design at every layer of your architecture. Interaction Layer: Set clear boundaries for incoming requests using Azure API Management rate‑limit and quota policies, such as rate-limit-by-key, scoped per subscription or tenant. These controls cap request throughput and request volume over time, preventing traffic spikes from overwhelming downstream AI services and ensuring consistent, predictable response behavior across tenants. Orchestration Layer: Define and restrict system execution paths. Limit reasoning depth in workflows so complex operations don’t unexpectedly slow things down. This keeps your business processes running smoothly and predictably. At the API boundary, Azure API Management can enforce deterministic routing, retry limits, and timeout policies, while backend orchestration services such as Azure Durable Functions or Logic Apps manage multi‑step workflows with explicit bounds on execution depth and retries. Model Layer: Choose models based on expected concurrency needs. Use fallback routing to redirect traffic during busy periods—so users don’t experience delays. Rely on Azure OpenAI Provisioned Throughput Units (PTUs) for steady baseline performance and enable PAYG overflow to handle temporary surges without sacrificing speed. Microsoft AI Foundry can be used to centrally manage model selection and routing policies, enabling consistent fallback strategies and governed use of multiple models across agents and workloads. Retrieval Layer: Optimize your document indexing and narrow the scope of data being searched. This means users get relevant information faster, and your system avoids unnecessary slowdowns. Services such as Azure AI Search enable scoped, indexed retrieval over structured and unstructured content, while integrating with Azure Blob Storage or Azure Cosmos DB as source data stores to support predictable, low‑latency access for RAG‑based AI workflows. Data Layer: Keep your compute and storage resources close together and aligned regionally. By minimizing cross-region data transfers, you reduce latency and boost reliability—critical for enterprise-grade AI. Across every layer, publishers are responsible for designing bounded, predictable defaults, while customers govern configuration, scale, and operational posture—a clear separation that reduces friction, improves trial outcomes, and accelerates Marketplace adoption. By applying these best practices decisively at every layer, software development companies can move beyond isolated optimizations and design AI solutions that behave predictably under real customer load. This approach enables customers to run meaningful trials, validate performance and cost assumptions early, and scale with confidence as demand grows. More importantly, it establishes a repeatable engineering foundation—one that supports faster iteration, clearer operational ownership, and successful commercialization through Microsoft Marketplace. Design caching into your architecture from the start Predictable AI performance relies on caching that’s intentionally designed into the architecture—not added after systems are already under load. In agent‑driven and retrieval‑augmented workflows, caching is foundational to controlling latency, stabilizing runtime costs, and keeping execution behavior consistent as usage scales. Effective designs cache work wherever outcomes are deterministic. Request‑level and semantic caching reduce redundant inference when users submit identical or meaning‑equivalent queries, while Azure API Management paired with Azure Managed Redis enables governed reuse at the intent level. Retrieval pipelines benefit from embedding and retrieval caching, which avoids repeated vectorization and unnecessary search overhead. Within orchestration flows, tool‑level caching ensures stable responses for deterministic calls such as policy checks or configuration lookups, and agent plan caching allows reasoning paths to be reused without re‑incurring planning cost. Caching must be paired with clear invalidation strategies—time‑based expiration, context‑aware refresh, and event‑driven updates—to preserve correctness and trust. In Marketplace deployments, multi‑tenant cache isolation and observability are essential. When caching is visible, governed, and intentional, it becomes a powerful enabler of predictable scale. What’s next in the journey With performance and cost under control, the next question is how your system behaves when something goes wrong. The next post explores API resilience and reliability patterns—because predictable performance only matters if your AI system continues to function through the inevitable failures that occur at 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 SuccessDesign predictable usage-based billing for AI apps and agents selling in Microsoft Marketplace
Design predictable usage‑based billing for AI apps and agents selling on Microsoft Marketplace Compared to traditional software, pricing and billing feel harder because of the range of AI functionality. They reason, they infer, call tools, process data, all, to complete tasks on the customer’s behalf. If you’re building an AI app or agent to sell in Microsoft Marketplace, usage‑based billing needs to be designed with care, instrumented with intention, and explained in a way customers can trust. This post, along with App Advisor’s curated step-by-step guidance through building, publishing and selling apps for Marketplace, walks through how to do exactly that—without over‑engineering or surprising your customers later. 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 billing for AI systems is different Traditional software pricing is usually tied to static entitlements, such as licenses, seats, fixed feature sets and/or a predictable runtime footprint. AI apps and agents don’t work that way. Their cost and value are driven by runtime behavior, such as: How often a model is invoked How many tokens are processed per request How deep reasoning chains go How frequently tools or APIs are called How much data is accessed, transformed, or embedded AI behaviors are subject to change based on the interpretation of prompts and subsequent outputs processed by agents and models. That variability is why pricing AI like traditional software often creates friction—margins erode and customers may lose trust. Pricing decisions should start with business value in mind, not the meter level. Start with plan design before you define meters Plans explain pricing. Meters enforce pricing. Your Marketplace plan is where customers learn what they are buying and how it works. Before you design a single metered dimension, your plan should clearly answer: What AI behaviors are allowed What usage is included What usage becomes billable What limits apply How customers upgrade as they grow An effective plan design typically considers several key factors, such as the distinction between public and private plans, the allocation of included usage versus charges for overages, the balance of base fees against variable consumption, and the provision of clear upgrade paths across different tiers. For instance, if you’re creating an AI support agent, a well-structured plan might offer up to 1,000 resolved conversations each month for a set monthly fee, with additional charges for any conversations beyond that limit and a higher tier that grants access to increased usage allowances. When customers can easily understand what is included, what triggers extra costs, and how they can upgrade as their needs grow, metering feels straightforward and fair. Conversely, when plan details are ambiguous, even accurately measured charges can seem arbitrary, leading to uncomfortable billing discussions. Choose a billing model that matches how your AI behaves When structuring your AI solution’s pricing, begin by evaluating the expected usage patterns and the business value your AI delivers. Actively consider the nature of your agent’s workloads, the variability of customer interactions, and the predictability of operating costs. Flat Fee: Weigh the benefits of flat rate or subscription pricing. Opt for fixed monthly or annual fees when your AI solution operates within defined limits and usage remains consistent. This approach simplifies billing for customers and provides them with clear expectations. Subscription pricing works best for AI agents whose engagement is steady and whose costs don’t fluctuate dramatically. Usage-based (metered): If your AI’s usage varies widely or scales rapidly, usage-based (metered) pricing is often preferable. This model aligns charges with actual consumption, ensuring customers pay only for what they use. To implement it, leverage Marketplace metering APIs to track and bill usage accurately. Consider usage-based pricing when customer demand is unpredictable or your AI’s operational costs increase with higher workloads. Hybrid: For AI solutions that deliver ongoing baseline value but occasionally handle intensive tasks, hybrid models combine the strengths of both approaches. Offer a base subscription for predictable service, then layer in usage charges for overages. This structure is common for agents serving regular needs with intermittent spikes, enabling you to manage cost recovery while giving customers cost certainty. Metering looks different depending on your offer type As you move forward with your plan design and billing model, it’s important to recognize that metering varies significantly based on how your solution is delivered. SaaS offers: Usage tracking is accomplished through Marketplace Metering APIs, allowing you to capture AI-driven activities such as agent task executions, workflow runs, document analysis, or token processing. Your metering should align closely with the customer’s subscription lifecycle, plan tiers, and the included usage, ensuring transparency and consistency as customers progress through different service levels. Container-based offers: You might meter resources like nodes, cores, pods, or clusters—or even application-specific AI dimensions. Accurate attribution across tenants and deployments is crucial, so customers are billed reliably according to their actual consumption. Virtual machine offers: Metering is generally linked to VM runtime or license usage. Although the granularity is often lower than SaaS solutions, billing remains contractually enforced, and publishers must ensure that measurements are dependable and align with customer agreements. Azure Managed Applications: Metering should reflect solution management exclusively, while the underlying infrastructure costs are handled separately through Azure’s billing system. For more about offer types, visit Marketplace Offer Types for AI Apps and agents: SaaS vs Managed App vs Containers. Design metered dimensions customers can actually explain As you refine your billing model for Marketplace offers, it’s vital to consider how your metered dimensions will be perceived and understood by your customers. The most effective dimensions reflect clear, customer-visible value rather than abstract internal system mechanics. For AI-driven solutions, this often means tracking tangible outcomes such as agent tasks executed, successful workflows completed, data objects processed, or AI-assisted actions performed. Choosing these straightforward metrics not only makes invoices easier for customers to interpret but also strengthens your position during billing reviews by tying charges directly to business outcomes. For example, “documents analyzed” is a much clearer and more defensible metric than “token batches processed,” and “resolved workflows” resonates more with customers than “model invocations.” Ultimately, a strong metered dimension is one that a customer can easily explain to their finance or procurement teams. If the charge isn’t readily understandable, it’s a signal to revisit and refine your measurement approach. Track and plan metrics using the Microsoft Marketplace metering service APIs Under‑reporting impacts revenue. Marketplace enforces billing based on what you report. Once you've determined how your solution will be delivered and understood how metering varies by offer type, the next step is to ensure your billing model is both transparent and robust. This is accomplished by tracking your plan and meter metrics through the Microsoft Marketplace Metering Service APIs —a process that not only supports accurate billing but also builds customer trust. Instrumenting usage at runtime is essential: you must reliably capture and report consumption, making sure each event is precisely recorded and associated with the correct subscription and plan. Aggregating this usage and sending it to the marketplace—whether hourly or daily, covering the previous 24 hours—ensures billing remains consistent and defensible. Add metering guardrails to avoid cost surprises As you implement usage-based metering for your Marketplace offers, it’s essential to build guardrails that protect both your business and your customers from unexpected costs. Metering is a critical component of your service reliability, directly influencing customer trust and the overall transparency of your billing model. Ensuring your metering remains both dependable and customer-focused is crucial for maintaining trust and transparency. As you instrument your solution, take care to attribute usage precisely across multiple tenants, so every charge is accurately mapped to the correct customer and subscription. Additionally, aggregating usage on a consistent schedule—such as hourly or daily—not only supports predictable reporting but also helps customers better understand their consumption patterns. These practices lay a solid foundation for metering that supports both your business objectives and your customers’ needs, creating a seamless experience that aligns with the overall goals of your Marketplace offering. Marketplace-ready offerings typically feature: Usage caps that set clear maximums, limiting exposure to unforeseen charges. Soft limits with proactive alerts as customers approach their thresholds. Hard limits to enforce plan boundaries and prevent overages beyond agreed levels. Transparent usage dashboards, giving customers real-time visibility into their consumption. For example, when a customer reaches 80% of their allotted usage, they receive an alert and can decide whether to upgrade their plan, pause usage, or proceed into overage with full awareness—eliminating surprise invoices at month’s end. What’s Next in the Journey After establishing robust billing and metering, the next step is to enhance your AI solution’s performance, optimize API workloads, and improve production observability—laying the groundwork for scalable, efficient, and reliable operations. These capabilities help keep AI systems cost‑effective and reliable as usage grows. 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 SuccessIntegrate Marketplace commerce signals to enforce entitlements in AI apps
How fulfillment and entitlement models differ by Microsoft Marketplace offer type AI apps and agents increasingly operate with runtime autonomy, dynamic capability exposure, and on‑demand access to tools and resources. That flexibility creates a new challenge for software companies: enforcing commercial entitlements (what a customer is allowed to access or use at runtime) correctly after a customer purchase through Microsoft Marketplace. Marketplace is the system of record for commercial truth, but enforcement always lives in your application, agent, or deployed resources. This post explains how Marketplace fulfillment and entitlement models differ by offer type—and what that means when you’re designing AI apps and agents that must respond correctly to subscription state, plan changes, and cancellations. 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 AI apps and agents must integrate with Marketplace commerce signals Microsoft Marketplace is the commercial system of record for: Tracking purchase and subscription state Managing plan selection and plan changes Signaling cancellation and suspension AI apps and agents, by contrast, operate in environments where decisions are made continuously at runtime. They expose capabilities dynamically, invoke tools conditionally, and often operate without a human in the loop. That mismatch makes static enforcement insufficient, including: UI‑only checks Configuration‑time gating Prompt‑based constraints Marketplace communicates commercial truth, but it does not enforce value. That responsibility always belongs to the publisher’s application, agent, or deployed resources. Correct integration starts with understanding what Marketplace provides—and what your software must implement. What Marketplace provides—and what publishers must implement Before diving into APIs or offer types, it’s important to separate responsibilities clearly. Marketplace provides authoritative commercial signals, including: Subscription existence and current state Plan and entitlement context Licensing or usage boundaries associated with the offer Marketplace does not: Enforce your business logic Control runtime behavior Automatically limit feature or resource access Publishers are responsible for translating Marketplace signals into: Application behavior Agent capabilities Resource access boundaries That enforcement must be deterministic, auditable, and aligned with what the customer actually purchased. How those signals surface—through APIs, deployment constructs, licensing context, or metering—depends entirely on the fulfillment and entitlement model of the offer. How fulfillment and entitlement models differ by offer type Microsoft Marketplace supports multiple offer and fulfillment models, including: SaaS subscriptions Azure Managed Applications Container offers Virtual machine offers Other specialized Marketplace offer types Each model determines: How a customer receives value Where commercial signals appear Which integration mechanisms apply Where entitlement enforcement must occur Some offers rely on Marketplace APIs. Others rely on deployment‑time enforcement, resource scoping, or usage constraints. There is no single integration pattern that applies to every offer. Understanding this distinction is essential before designing entitlement enforcement for AI apps and agents. Marketplace integration responsibilities by offer type This section is the technical anchor of the post. Marketplace APIs are not universal; they apply differently depending on the offer model. SaaS offers SaaS offers integrate directly with Microsoft Marketplace through the SaaS Fulfillment APIs. These APIs are used to: Activate subscriptions Track plan changes Enforce suspension and cancellation In this model, Marketplace communicates subscription lifecycle events, but it does not enforce access. The publisher must: Map Marketplace subscriptions to internal tenants Maintain a durable subscription record Enforce entitlements at runtime For AI apps and agents, that enforcement typically happens in orchestration logic or tool‑invocation boundaries—not in the UI or prompts. SaaS Fulfillment APIs are the primary mechanism for receiving commercial truth, but the application remains responsible for acting on it. Container offers Container offers deliver value as container images and associated artifacts, such as Helm charts. In this model, the publisher is shipping a deployable artifact—not an application endpoint or API managed by Marketplace. Marketplace provides: Entitlement to deploy the container image Optional usage‑based billing and metering Ability to deploy to an existing AKS cluster or to a publisher configure one Enforcement occurs at: Deployment time, by controlling access to images Runtime usage, through configuration and limits Metered dimensions, when usage‑based billing applies For AI workloads packaged as containers, entitlement enforcement is typically embedded in the runtime configuration, resource limits, or metering logic—not in Marketplace APIs. Virtual machine offers Virtual machine offers are fulfilled through VM image deployment. In this model: Fulfillment is based on VM deployment Licensing and usage are enforced through the VM lifecycle Subscription state is less event‑driven but still contractually binding While there is no SaaS‑style fulfillment callback, publishers must still ensure that deployed workloads align with the purchased offer. For AI solutions delivered via VM images, enforcement is tied to licensing, configuration, and operational controls inside the VM. Azure Managed Applications For Azure Managed Applications, fulfillment is enforced through the Azure Resource Manager (ARM) deployment lifecycle. In this model: A Marketplace purchase establishes deployment rights Resources are deployed into a managed resource group Operational boundaries are defined by ARM and Azure role assignments Publishers enforce value through: Deployment behavior Resource configuration Lifecycle management and updates For AI solutions delivered as managed applications, entitlement enforcement is tied to what is deployed and how it is operated—not to an external subscription API. Marketplace establishes the contract, and Azure enforces access through infrastructure boundaries. Other offer types Other Marketplace offer types follow similar patterns, with varying degrees of API involvement and deployment‑time enforcement. The key principle holds: Marketplace establishes commercial rights, but enforcement is always implemented by the publisher, using the mechanisms appropriate to the offer model. Designing entitlement enforcement into AI apps and agents Entitlements must be enforced outside the model. Large language models should never be responsible for deciding what a customer is allowed to do. Effective enforcement belongs in: The interaction layer The orchestration layer Tool invocation boundaries Avoid: UI‑only enforcement Prompt‑based entitlement logic Soft limits without auditability AI agents should request capabilities from deterministic services that already understand subscription state and plan entitlements. This ensures enforcement is consistent, testable, and resilient. Handling plan changes, upgrades, and feature tiers Plan changes are common in Microsoft Marketplace. AI capability must align continuously with: The active subscription tier Purchased dimensions or limits Common examples include: Agent autonomy limits Tool or connector access Rate limits Data scope Feature gating must be deterministic and testable. When a plan changes, your application or agent should respond predictably—without manual intervention or redeployment. Failure, retry, and reconciliation patterns Marketplace events are not guaranteed to be: Ordered Delivered once Immediately available AI apps must handle: Duplicate events Missed callbacks Temporary Marketplace or network failures Reconciliation processes protect customers, publishers, and Marketplace trust. Periodic verification of subscription state ensures that runtime enforcement remains aligned with commercial reality. How Marketplace API integration affects readiness and review Marketplace reviewers look for: Clear enforcement of subscription state Clean suspension and revocation paths Strong integration leads to: Faster certification Fewer conditional approvals Lower support burden after launch Correct enforcement is not just a technical requirement—it’s a Marketplace readiness signal. What’s next in the journey Once entitlement enforcement is solid, the next layer of operational maturity includes: Usage‑based billing and metering architecture Performance, caching, and cost optimization Observability and operational health for AI apps and agents 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 SuccessDesign 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 SuccessAI apps and agents: choosing your Marketplace offer type
Choosing your Marketplace offer type is one of the earliest—and most consequential—decisions you’ll make when preparing an AI app for Microsoft Marketplace. It’s also one of the hardest to change later. This post is the second in our Marketplace‑ready AI app series. Its goal is not to push you toward a specific option, but to help you understand how Marketplace offer types map to different AI delivery models—so you can make an informed decision before architecture, security, and publishing work begins. 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 offer type is an important Marketplace decision Offer type is more than a packaging choice. It defines the operating model of your AI app on Marketplace: How customers acquire your solution Where the AI runtime executes Determining the right security and business boundaries for the AI solution and associated contextual data Who operates and updates the system How transactions and billing are handled Once an offer type is selected, it cannot be changed without creating a new offer. Teams that choose too quickly often discover later that the decision creates friction across architecture, security boundaries, or publishing requirements. Microsoft’s Publishing guide by offer type explains the structural differences between offer types and why this decision must be made up front. How Marketplace offer types map to AI delivery models AI apps differ from traditional software in a few critical ways: Contextual data may need to remain in a specific tenant or geography Agents may operate autonomously and continuously Control over infrastructure often determines trust and compliance How the solution is charged and monetized, including whether pricing is usage‑based, metered, or subscription‑driven (for example, billing per inference, per workflow execution, or as a flat monthly fee) The buyer’s technical capability, including the level of engineering expertise required to deploy and operate the solution (for example, SaaS is generally easier to consume, while container‑based and managed application offers often require stronger cloud engineering and DevOps skills) Marketplace offer types don’t describe features. They define responsibility boundaries—who controls the AI runtime, who owns the infrastructure, and where customer data is processed. At a high level, Marketplace supports four primary delivery models for AI solutions: SaaS Azure Managed Application Azure Container Virtual Machine Each represents a different balance between publisher control and customer control. The sections below explain what each model means in practice. Check out the interactive offer selection wizard in App Advisor for decision support. Below, we unpack each of the offer types. SaaS offers for AI apps SaaS is the most common model for AI apps and agents on Marketplace—and often the default starting point. With a SaaS offer, the AI service runs in the publisher’s Azure environment and is accessed by customers through a centralized endpoint. This model works well for: Multi‑tenant AI platforms and agents Continuous model and prompt updates Rapid experimentation and iteration Usage‑based or subscription billing Because the service is centrally hosted, publishers retain full control over deployment, updates, and operational behavior. For multi-tenant AI apps, this also means making early decisions about Microsoft Entra ID configuration—such as how customers are onboarded, whether access is granted through tenant-level consent or external identities, and how user identities, roles, and data are isolated across tenants to prevent cross-tenant access or data leakage. For official guidance, see the SaaS section of the Marketplace publishing guide and the AI agent overview, which describes SaaS‑based agent deployments. Plan a SaaS offer for Microsoft Marketplace. Azure Managed Applications for AI solutions In this model, the solution is deployed into the customer’s Azure subscription, not the publisher’s. There are two variants: Managed applications, where the publisher retains permissions to operate and update the deployed resources Solution templates, where the customer fully manages the deployment after installation This model is a strong fit when AI workloads must run inside customer‑controlled environments, such as: Regulated or sensitive data scenarios Customer‑owned networking and identity boundaries Infrastructure‑heavy AI solutions that can’t be centralized Willingness or need on part of the customer or IT team to tailor the app to the needs of the end customer specific environment Managed Applications sit between SaaS and fully customer‑run deployments. They offer more customer control than SaaS, while still allowing publishers to manage lifecycle aspects when appropriate. Marketplace guidance for Azure Applications is covered in the publishing guide. For more information, see the following links: Plan an Azure managed application for an Azure application offer. Azure Container offers for AI workloads Container offer AI workloads—typically on AKS—using container images supplied by the publisher. This model is best suited for scenarios that require: Strict data residency Air‑gapped or tightly controlled environments Customer‑managed Kubernetes infrastructure The publisher delivers the container artifacts, but deployment, scaling, and runtime operations occur in the customer’s environment. This shifts operational responsibility, risk and compute costs away from the publisher and toward the customer. Container offer requirements are covered in the Marketplace publishing guide. Plan a Microsoft Marketplace Container offer. Virtual Machine offers for AI solutions Virtual Machine offers still play a role, particularly for specialized or legacy AI solutions. VM offers package a pre‑configured AI environment that customers deploy into their Azure subscription. Compared to other models, they offer: Updates and scaling are more tightly scoped Iteration cycles tend to be longer The solution is more closely aligned with specific OS or hardware requirements They are most commonly used for: Legacy AI stacks Fixed‑function AI appliances Solutions with specialized hardware or driver dependencies VM publishing requirements are also documented in the Marketplace publishing guide. Plan a virtual machine offer for Microsoft Marketplace. Comparing offer types across AI‑specific decision dimensions Rather than asking “which offer type is best,” it’s more useful to ask what trade‑offs you’re making in an AI app delivery model comparison. Key lenses to consider include: Who operates the AI runtime day‑to‑day Where customer data and AI prompts inputs and outputs are processed and stored Example: When evaluating Saas vs managed apps for AI, check industry specific compliance requirements to evaluate whether the data has to remain in the customer’s tenant or it can be sent to the publisher’s tenant. How quickly models, prompts, and logic can evolve The balance between publisher control and customer control How Marketplace transactions and billing align with runtime behavior SaaS Container (AKS / ACI) Virtual Machine (VM) Azure Managed Application What it is Fully managed, externally hosted app integrated with Marketplace for billing and entitlement Containerized app deployed into customer-managed Azure container environments VM image deployed directly into the customer’s Azure subscription Azure native solution deployed into the customer’s subscription, managed by the publisher Control plane Publisher‑owned Customer owned Customer owned Customer owned (with publisher access) Operational model Centralized operations, updates, and scaling Customer operates infra; publisher provides containers Customer operates infra; publisher provides VM image Per customer deployment and lifecycle Good fit scenarios • Multi‑tenant AI apps serving many customers • Fast onboarding and trials • Frequent model or feature updates • Publisher has full runtime control • AI apps or agents built as microservices • Legacy or lift-and-shift AI workloads • Enterprise AI solutions requiring customer owned infrastructure Avoid when • Customers require deployment into their own subscription • Strict data residency mandates customer control • Offline or air‑gapped environments are required • Customers standardize on Kubernetes • Custom OS or driver dependencies • Tight integration with customer Azure resources Typical AI usage pattern Centralized inference and orchestration across tenants • Portability across environments is important • Specialized runtime requirements • Strong compliance and governance needs Different AI solutions land in different places across these dimensions. The right choice is the one that matches your operational reality—not just your product vision. Note: If your solution primarily delivers virtual machines or containerized workloads, use a Virtual Machine or Container offer instead of an Azure Managed Application. Supported sales models and pricing options by Marketplace offer type Marketplace offer types don’t just define how an AI app and agent is deployed — they also determine how it can be sold, transacted, and expanded through Microsoft Marketplace. Understanding the supported sales models early helps avoid misalignment between architecture, pricing, and go‑to‑market strategy. Supported sales models Offer type Transactable listing Public listing Private offers Resale enabled Multiparty private offers Azure IP Co‑sell eligible SaaS Yes Yes Yes Yes Yes Yes Container Yes Yes Yes No Yes Yes Virtual Machine Yes Yes Yes Yes Yes Yes Azure Managed Application Yes Yes Yes No Yes Yes What these sales models mean Transactable listing A Marketplace listing that allows customers to purchase the solution directly through Microsoft Marketplace, with billing handled through Microsoft. Public listing A listing that is discoverable by any customer browsing Microsoft Marketplace and available for self‑service acquisition. Private offers Customer‑specific offers created by the publisher with negotiated pricing, terms, or configurations, purchased through Marketplace. Resale enabled Using resale enabled offers, software companies can authorize their channel partners to sell their existing Marketplace offers on their behalf. After authorization, channel partners can independently create and sell private offers without direct involvement from the software company. Multiparty private offers Private offers that involve one or more Microsoft partners (such as resellers or system integrators) as part of the transaction. Azure IP Co‑sell eligible When all requirements are met this allows your offers to contribute toward customers' Microsoft Azure Consumption Commitments (MACC). Pricing section Marketplace offer types determine the AI pricing models available. Make sure you build towards a marketplace offer type that aligns with how you want to deploy and price your solution. SaaS – Subscription or flat‑rate pricing, per‑user pricing, and usage‑based (metered) pricing. Container – Kubernetes‑based offers support multiple Marketplace‑transactable pricing models aligned to how the workload runs in the customer’s environment, including per core, per core in cluster, per node, per node in cluster, per pod, or per cluster pricing, all billed on a usage basis. Container offers can also support custom metered dimensions for application‑specific usage. Alternatively, publishers may offer Bring Your Own License (BYOL) plans, where customers deploy through Marketplace but bring an existing software license. Virtual Machine – Usage-based hourly pricing (flat rate, per vCPU, or per vCPU size), with optional 1-year or 3-year reservation discounts. Publishers may also offer Bring Your Own License (BYOL) plans, where customers bring an existing software license and are billed only for Azure infrastructure. Azure Managed Application – A monthly management or service fee charged by the publisher; Azure infrastructure consumption is billed separately to the customer. Note: Azure Managed Applications are designed to charge for management and operational services, not for SaaS‑style application usage or underlying infrastructure consumption. Buyer‑side assumptions to be aware of For customers to purchase AI apps and agents through these sales models: The customer must be able to purchase through Microsoft Marketplace using their existing Microsoft procurement setup Marketplace purchases align with enterprise buying and governance controls, rather than ad‑hoc vendor contracts For private and multiparty private offers, the customer must be willing to engage in a negotiated Marketplace transaction, rather than pure self‑service checkout Important clarification Supported sales models are consistent across Marketplace offer types. What varies by offer type is how the solution is provisioned, billed, operated, and updated. Sales flexibility alone should not drive offer‑type selection — it must align with the architecture and operating model of the AI app and agent. How this decision impacts everything that follows Offer type selection for AI apps and agents ripples through the rest of the Marketplace journey. They directly shape: Architecture design choices Security and compliance boundaries Fulfillment APIs and billing integration Publishing and certification requirements Cost, scalability, and operational responsibility Follow the series for updates on new posts. What’s next in the journey With the offer type decision in place, the focus shifts to turning that choice into a production‑ready solution. This includes designing an architecture that aligns with your delivery model, establishing clear security and compliance boundaries, and preparing the operational foundations required to run, update, and scale your AI app or agent confidently in customer environments. Getting these elements right early reduces rework and sets the stage for a smoother Marketplace journey. See the next post in the series: Designing Production‑Ready AI App and Agent Architectures for Microsoft Marketplace. 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
