DEV Community: Alex Pechenizkiy

Stop Vibe-Coding Power Platform: Turn ADO Work Items Into Specs Any AI Agent Can Build From

Alex Pechenizkiy — Thu, 02 Jul 2026 00:35:14 +0000

The agent brand is irrelevant; the work item is everything.

I have watched teams argue about Copilot Studio versus Claude Code versus Codex as if the model decides whether their build succeeds. It does not. Your agentic development power platform effort lives or dies on one thing: whether the Azure DevOps work item you hand the agent is a machine-readable spec or a vaguely worded wish. Swap the agent all you want. If the requirement is unstructured, every agent guesses, and every guess is a different guess.

This article is opinionated on exactly one point and neutral on everything else. Neutral on the tool. Ruthless about the spec.

Why "AI-assisted" Power Platform dev stalls on real teams

The agent guesses intent because the acceptance criteria live in a stale wiki, a Teams thread, or someone's head. That is the whole failure. Switching from one agent to another does not close the gap. The missing spec does.

Prompt-by-prompt building has a second problem that shows up later and hurts more. One maker gets a working flow out of a chat session, but nobody else can reproduce it and no one can audit it. You have a solution that exists and a rationale that evaporated. For teams doing serious dynamics 365 ai development, that is not acceleration. That is a single point of failure wearing a productivity costume.

Frame the cost honestly. Say a rework cycle caught in UAT runs roughly 5x the cost of the same fix at design time. Illustrative; calibrate against your own data, actuals vary. Under that assumption, the line item bleeding your budget is the improvised requirement, not the agent license. You are paying to rediscover intent three environments too late.

Takeaway: if your requirement is not structured, your agent is improvising, and the brand of agent does not matter.

Make the ADO work item the single source of truth

An agent reads fields. It does not read the room. So the work item has to carry everything the agent needs in a shape a parser can trust every single time.

Define the structure once and apply it to every Feature and User Story:

Acceptance criteria as Given/When/Then (Gherkin), one scenario per behavior.
Entity and table definitions as fenced YAML: logical name, columns, types, relationships.
Business rules stated as conditions and outcomes, not prose.
Security roles the artifact assumes, named explicitly.

Use a consistent work item template so the same machine-readable blocks appear in the same headings every time. The whole point of azure devops power platform ai work is that the agent finds the schema block under the same H3 in every item, not that it hunts for intent in freeform text.

Here is the practitioner caveat. The Azure DevOps work item field reference treats Description and acceptance criteria as rich-text fields. That is fine for humans and lousy for parsers. In production you want a fenced, structured block inside those fields (YAML for schema, fixed markdown for behavior) so parsing stays deterministic no matter which model you point at it. Free text drifts. A fenced block does not.

Takeaway: an agent reads fields, not vibes. Write the work item for the parser, not just the standup.

The spec-to-build loop (tool-agnostic)

Pull the work item programmatically. Two paths both work: the Azure DevOps REST API for a direct fetch, or a Model Context Protocol server that exposes the same items as a tool the agent calls. Either path feeds Copilot Studio, Claude Code, OpenAI Codex, or a homegrown agent equally. The spec is the input contract. The consumer is swappable.

Feed the structured spec in and generate the components that map 1:1 to the fields: Dataverse tables from the YAML schema, model-driven components, Power Automate flows from the trigger/action pairs, plugin code where the business rules demand it. One block in, one reviewable artifact out.

This is spec driven development ai in practice. The spec is portable. The agent is a detail.

Caveat, and it applies to every vendor equally: agents drift on multi-entity relationships. Generate the schema first, validate it, commit it, then generate logic against the committed schema. Do not ask one prompt to invent five related tables and the plugins that traverse them in a single shot. It will hallucinate a lookup that does not exist. For deeper patterns on wiring the consumer side, see our notes on Copilot Studio agent patterns.

Takeaway: one work item in, one reviewable component out, and you can swap the agent without rewriting the spec.

Closing the traceability gap

Auto-link every generated artifact back to its work item ID. In Azure DevOps that is the AB#<id> syntax in commit messages, which creates a real link between the commit and the item. Map each table, flow, and PCF control to the originating requirement so your ALM stops being theater and starts being evidence.

The mature half of traceability is solid today: AB# commit linking and a branch policy that requires a linked work item on every PR are native and enforceable. Turn them on.

Caveat. Solution component descriptions inside Dataverse are not reliably searchable, and they do not survive round-trips cleanly. So anchor traceability in the Git commit and the PR, not inside the solution metadata. The commit is the durable record; the solution description is a nice-to-have.

Takeaway: if an artifact cannot name its requirement, it does not ship.

The no-go list: what the agent must never touch

This is the section with teeth. The cheapest guardrail is an identity that physically cannot reach production.

Draw the boundary before any agent runs. Agents generate into a dev environment and a feature branch. Full stop. They never publish to production, never touch managed solutions in higher tiers, never edit security roles or field-level security, never read environment variables holding secrets, never rebind connection references to live credentials. And they never edit the spec they were handed. This rule holds for a CLI agent with shell access exactly as much as it holds for Copilot Studio.

Green zone (agent may generate)	Red zone (off-limits to any agent)
Unmanaged solution in a dev environment	Production environments, any operation
Dataverse tables and columns from the YAML schema	Managed solutions in test/UAT/prod tiers
Power Automate flows in a feature branch	Security roles and field-level security
Plugin/PCF source code in Git	Environment variables holding secrets
Draft commits linked with `AB#`	Connection references bound to live credentials
Proposed test scenarios from Given/When/Then	The work item spec itself

Here is the caveat that makes this urgent. The platform will happily let a broadly scoped service principal push straight to production, and a terminal agent runs whatever command you authorize. Prompt wording does not stop this. You stop it by scoping the app registration and application user to dev only, giving it a custom security role instead of System Administrator, and configuring a DLP policy that blocks production connectors for that identity. Permissions are the guardrail. The prompt is not.

Governance for ai governance power platform is not a paragraph you add to the system message. It is an identity that cannot do the dangerous thing even when instructed to.

Takeaway: the cheapest governance control is an identity that physically cannot reach production.

The governance checklist you run before the agent does

Tick all seven before authorizing any run. If you cannot, the agent waits.

The work item carries the fenced spec block with Given/When/Then behavior and YAML schema under the standard headings.
The agent app registration is scoped to the dev environment only, with a custom security role, never System Administrator.
A DLP policy blocks production connectors for that identity.
The target is a feature branch, never main.
A CI validation gate is wired to the acceptance criteria. Be honest: this is a pattern you assemble, not a Microsoft reference architecture you flip on. More on how to build it below.
A human PR approver is assigned and knows they are checking the mapping, not the syntax.
The commit template enforces the AB# work item ID link.

Caveat: teams treat this as one-time setup, then scope and DLP quietly drift as environments get added and new connectors ship. Re-verify items 2 and 3 every sprint. Environment sprawl is how a dev-only identity ends up with a path to prod nobody remembers granting.

Takeaway: if you cannot tick all seven, the agent does not run yet.

Guardrails that keep AI honest

Use the acceptance criteria as the test oracle. Given/When/Then is already a behavior specification; validate the generated solution against it before anything touches a pipeline. Run that validation in CI so drift fails the build instead of surfacing in UAT. The gate is agent-neutral by design, because it checks the artifact against the spec, not the prompt against a style guide.

Be precise about what exists. This oracle is an emerging pattern teams assemble today from the Power Apps Test Engine plus custom scripts and the Power Platform Build Tools tasks. It is not a packaged spec-to-test framework Microsoft ships. Build it as a gate; do not pretend it comes in the box.

Add a human approval gate on the PR. The reviewer checks the spec-to-artifact mapping (does this flow implement the scenarios in the item), not every code line. That is the review that catches an agent building the wrong right thing.

CI validation gate (assembled pattern, not a product). On PR to a feature branch, run a pipeline that (1) imports the generated unmanaged solution into a throwaway build environment, (2) executes the Given/When/Then scenarios via Test Engine and custom checks, and (3) fails the build if any scenario is unmet or the schema diverges from the committed YAML. Wire it with Power Platform Build Tools tasks. You own the wiring; Microsoft ships the parts, not the assembly.

Our walkthrough of Power Platform ALM pipelines covers the pipeline plumbing this gate sits inside.

Takeaway: governance is the spec checked automatically, not a doc nobody reads.

Walkthrough: one Feature, end to end

Take a generic case-routing requirement. Illustrative throughout; calibrate against your own data, actuals vary.

The work item body carries a fenced schema block and behavior block:

# mrd_ prefix per our solution naming convention
entity: mrd_supportcase
columns:
  - { name: mrd_priority, type: choice, options: [Low, Medium, High] }
  - { name: mrd_assignedteam, type: lookup, target: mrd_team }
relationships:
  - { type: N:1, from: mrd_supportcase, to: mrd_team }

Scenario: High-priority cases route to the escalation team
  Given a support case with mrd_priority = High
  When the case is created
  Then mrd_assignedteam is set to the escalation team
  And an approval flow notifies the team lead

The prompt is boring on purpose: "Read work item AB#4821. Generate the Dataverse table, the routing flow, and any plugin logic to satisfy every Given/When/Then scenario. Commit to the feature branch with AB#4821 in the message. Do not touch any environment other than dev." The same prompt drives Copilot Studio, Claude Code, or Codex with zero change to the work item. That is the point.

Out comes a component list: the mrd_supportcase table, a Power Automate routing flow, an approval flow, and a linked commit. It flows ADO item to generated solution to pipeline, where the CI gate runs the scenarios and the dev-scoped identity makes the red zone physically unreachable.

	Prompt-by-prompt	Spec-driven agentic build
Source of truth	The chat session	The ADO work item
Reproducibility	One maker, non-repeatable	Any agent, same output shape
Traceability	None after the session ends	`AB#` links commit to requirement
Where errors surface	UAT or production	CI gate on the PR
Governance	Prompt wording, hope	Scoped identity plus DLP

Takeaway: you leave with a template you can paste into your own ADO project today.

The one artifact to build first

Agentic development power platform work only pays off when the Azure DevOps work item is structured enough for any agent to build from and verify against, and when that agent physically cannot reach what it must not touch. The spec is the constant. The identity is the fence. The agent is a swappable detail.

Before your next sprint, convert a single Feature to the fenced spec template and commit it. One item, with the YAML schema and the Given/When/Then block, under standard headings. Everything else in this piece follows from that one artifact.

This article was originally published at az365.ai. I'm Alex Pechenizkiy, an Azure and Power Platform solutions architect writing honest, vendor-neutral analysis of the Microsoft AI stack. More at az365.ai.

Microsoft 365 Copilot ROI Calculator: The Honest Math

Alex Pechenizkiy — Sat, 06 Jun 2026 22:55:16 +0000

Every Microsoft 365 Copilot ROI calculator on the internet tells the same story. Plug in 1,000 users, accept the default 3-hour weekly time savings, multiply by a generous loaded hourly rate, divide by $30 per seat per month, and out comes a triple-digit ROI percentage. Take it to your CFO. Sign the order. Welcome to the productivity revolution.

That math is wrong. It misses three inputs that decide whether the program actually returns its investment. Most calculators assume 100% adoption when published Microsoft enterprise telemetry shows 35.8% market average. Most accept Microsoft's self-reported time savings at face value, while Microsoft's own randomized control trials show users overstate savings by three to seven times. Most ignore implementation services and the Purview governance prerequisites that turn a $360K license bill into a $700K Year 1 commitment.

This calculator is built differently. The defaults come from Microsoft Research randomized control trials, BLS Employment Cost Index data, and current Microsoft 365 Copilot list pricing. Every slider has anchor buttons showing the marketing-optimistic, market-average, and RCT-grounded values. The sensitivity panel makes it impossible to hide the one lever your business case depends on the most.

TL;DR

Microsoft 365 Copilot is $30 per user per month, annual commitment, no seat minimum. Forrester's commissioned TEI studies show 116% to 353% ROI. Microsoft's own RCTs (peer-published, telemetry-measured) show ~0.5 hours per week saved on email plus 12% document speed-up. Stackmatix 2026 data shows 35.8% of paid licenses are active in any month. Implementation services run $100K to $300K for 1,000 seats; Purview governance prerequisites add $50K to $500K depending on tenant maturity. The realistic Year 1 case is closer to break-even than to triple-digit ROI, but it is positive when adoption is managed and time savings are deflated honestly. The calculator below shows exactly which lever moves the answer.

The honest Copilot ROI math: a commissioned 353 percent against RCT-measured savings, with adoption rate the lever the business case actually turns on.

Why Most Copilot ROI Calculators Are Lies

They assume every paid license is active. Microsoft's official "active user" definition in the M365 admin center is "submitted at least one prompt in the period," and a single prompt counts. Even by that loose bar, Stackmatix's 2026 enterprise telemetry shows 35.8% of paid seats are active in any given month. North America runs higher (64% peak), best-in-class deployments hit 75%, but the modal enterprise sits between 35% and 55%. A calculator that defaults to 100% adoption is overstating benefit by 1.5x to 3x before any other input is touched.

They take Microsoft's self-reported time savings at face value. Microsoft's Work Trend Index cites "1.2 hours per week" saved from a 297-user early-adopter survey. The Vodafone customer story cites 4 hours per week in legal. Dentsu cites 7.5 hours per week. All self-reported. When Microsoft Research ran an actual randomized control trial across 6,000 workers in 56 firms, the telemetry-measured result was 30 minutes per week saved on email plus a 12% speed-up on document writing. When Microsoft's Security Copilot RCT compared self-report to control-group completion times, users said they saved 38 minutes; the control group only finished 5 minutes slower. That is a 7x overstatement, in Microsoft's own data, on Microsoft's own product.

They forget implementation cost and governance prerequisites. A 1,000-seat enterprise deployment is not just $360K of license. It is $100K to $300K of partner readiness, pilot, and rollout services. It is another five to six figures of Purview labels, DLP rules, and SharePoint oversharing remediation work (the exact number varies dramatically with starting tenant maturity), because Copilot grounds on whatever the user has access to and most enterprises discover they have a permissions mess before they have a Copilot deployment. It is often pressure to upgrade from M365 E3 to E5 (or to add Purview / Defender SKUs) to meet Copilot's compliance baseline. None of these costs sit on the Copilot invoice.

The calculator below builds those three corrections in by default. You can move every slider to the Microsoft-marketing optimistic value if you want. The point is that the defaults are not pulled from a vendor deck.

The Calculator

Try the interactive Microsoft 365 Copilot ROI calculator (with honest, skeptical defaults) on the original article: https://az365.ai/blog/copilot-roi-calculator-microsoft-enterprises/

How to Read the Result

Start with the worked example. The calculator opens with these defaults: 1,000 seats, $30/user/month list price, 55% active rate (the upper end of the 35-55% modal-enterprise range per Stackmatix), 1.0 hour saved per active user per week, 0.5 deflation factor (because Microsoft's Security Copilot RCT showed users overstate savings ~7x). The 1.0 × 0.5 deflation lands the effective benefit at 0.5 hours per week, matching the RCT-measured value the article cites. Plus $75/hour fully-loaded knowledge-worker cost (BLS ECEC December 2025), 40 productive weeks per year, and $175,000 one-time implementation amortized over three years.

The math: 1,000 × 0.55 × 1.0 × 40 × 0.5 = 11,000 hours saved per year. At $75 per hour that is $825,000 annual benefit. Annual cost is $360,000 license plus $58,333 amortized implementation = $418,333. Net annual value: +$406,667. ROI: +97%. Payback period: 4.5 months. Break-even active rate (the rate at which benefit equals cost, holding all else constant): 27.9%.

That number lives below Forrester's 116% three-year case, consistent with the article's claim that the realistic ROI sits below vendor-marketing benchmarks. Move the active-rate slider down to 35% (Stackmatix's global market average) and ROI drops to roughly +25%; below the 27.9% break-even rate, the program runs at a loss.

Three numbers in that output do real work.

The headline ROI percentage is annual benefit divided by annual cost expressed as a percentage. ROI of 0% means the program pays for itself but produces no surplus. The Forrester TEI commissioned for Microsoft puts enterprise Copilot at 116% over three years; that model uses Microsoft self-reported time savings without deflation and assumes high adoption. Move the deflation factor slider to 1.0 and the active rate slider to 75% to see the Forrester-style number. Move them the other way (35% active, 0.3 deflation) and the realistic case turns negative.

The break-even active rate is the percentage of licensed users who must be active for the program to pay for itself at the rest of your inputs. This is the most useful number on the page. If your scenario shows a break-even of 65%, and your enterprise is honestly going to land at 45% adoption, the program does not return its investment until you fix adoption. That is a different conversation than "is Copilot worth $30 per user per month."

The sensitivity chart on the right shows ROI at 25%, 50%, 75%, and 100% active rates, holding everything else constant. If the 25% bar is deeply negative and the 100% bar is strongly positive, your Copilot business case is an adoption problem dressed as a procurement question. The right move is to invest in adoption enablement before you scale the seat count, not after.

The Levers That Actually Move the Answer

In order of impact for typical enterprise inputs.

Active-user rate. Going from 35% (market average) to 75% (best-in-class) doubles the benefit at constant inputs. This is the single biggest lever and it is the one finance leaders ignore because it does not feel like their lever. It is. License procurement and adoption enablement cannot be split between two budgets without losing the program in the gap.

Hours saved per active user per week. Microsoft self-report sits at 1.2 to 3 hours. Telemetry-measured RCT sits at 0.5 hours. Use 1.5 hours as a midpoint with a 0.5 deflation factor and you land at the same effective benefit (0.75 hours per week). Choosing the optimistic number without deflation is the same mistake as choosing 100% adoption.

Hourly loaded cost. BLS Employment Cost Index for December 2025 shows civilian total compensation at $48.78 per hour. Knowledge worker personas typically run $50 to $150 per hour fully loaded. Use a weighted average of your role mix; do not default to "VP of Sales" rates if 80% of your Copilot users are individual contributors.

Implementation and governance cost. EPC Group benchmarks for 1,000-seat deployments: $15K readiness assessment, $25-50K pilot, $75-250K full deployment, $50-500K Purview prerequisite work depending on starting maturity. The governance work is the most underestimated line item because most procurement teams treat it as a sunk Microsoft 365 cost rather than a Copilot-driven cost. It is a Copilot-driven cost because nobody was going to remediate SharePoint oversharing without the Copilot business case forcing it.

License price. Mostly fixed at $30 per user per month annual commit. The adjustable case is role-based copilots (Sales, Service, Finance), which run $50 standalone or $20 incremental for licensed M365 Copilot users. If your scenario is M365 Copilot only, leave this slider alone.

What This Calculator Does Not Measure

A defensible ROI memo discloses what is not in the model. This calculator does not include:

Switching costs. Time lost reformatting prompts, fixing hallucinations, re-checking Copilot output against ground truth before pasting it into a customer email.
Training and onboarding time. Four to twenty hours per user lost to enablement workshops, prompt courses, and change management. Real cost on a real calendar.
Cognitive overhead. The "second monitor problem": context-switching between Copilot, the source document, and the validation step often eats the savings the tool produces. RCTs do not measure this directly; field experience says it is real for non-trivial work.
Integration debt. SharePoint permissions remediation, Purview labeling backfill, retention policy gaps. These are Copilot-driven costs that do not appear on a Copilot invoice.
License waste on inactive users. ~64% of paid seats are inactive in a given month at average. The active-rate slider models the ones who use it; the seats that do not are a pure cost line.
Output-quality regressions. Documents drafted by Copilot are written 12% faster but the experiment did not measure quality acceptance rate downstream. Some outputs go through more revision cycles, eating the speed gain.

The point is not to skip Copilot but to defend the business case with eyes open. Procurement teams that are surprised by item 4 in month nine often kill a working program for the wrong reason.

How to Use This With Your CFO

Present three scenarios, not one. Conservative (35% active, 0.5 hours per week, 0.3 deflation), realistic (55% active, 1.5 hours per week, 0.5 deflation), optimistic (75% active, 3 hours per week, 1.0 deflation). Show all three. Recommend the realistic. CFOs trust ranges with a recommendation; they distrust point estimates with marketing copy.

Include the break-even active rate prominently. "We need 47% of licensed users active each month for the program to pay back. Current adoption in the pilot is 38%. The first $200K of incremental investment should go to adoption enablement, not seat expansion." That sentence reframes the conversation from "should we buy Copilot" to "what does it take to make the seats we are about to buy actually work."

Separate license cost from program cost. Procurement will see the $30 per user per month and approve it. Do not let the $200K of partner services and the $300K of Purview governance work hide in operating budgets. Itemize them in the same memo. Cap the program before it caps you.

The calculator above does not solve the procurement decision. It gives you the math to defend whatever decision you make. Move the sliders, save the scenario, send the memo. The honest version is more persuasive than the optimistic one because the honest version is the one that survives quarterly review.

Claude on Azure: The Marketplace Billing Trap

Alex Pechenizkiy — Sat, 06 Jun 2026 00:09:19 +0000

In March 2026, Tominaga Takuya, founder and CEO of Tokyo-based startup Leach, published a cautionary tale. He had Microsoft for Startups Founders Hub credits. He deployed Claude Opus on Azure AI Foundry. He shipped a feature. The first invoice was ¥237,081 (about $1,600 USD), charged directly to his credit card. The startup credits had not covered a single Claude token.

He was not alone. A second Japanese founder racked up over ¥2,000,000 (about $13,000) in Claude charges in one month. German founder Bogdan Sevriukov hit €999.60. Riyaj Shaikh, a third founder, reported being billed several thousand dollars in a follow-up case. The Register also reported evidence of an approximately $3,000 charge against another startup whose credits stayed unused. A separate Microsoft Q&A thread opened by Nitika Garg on March 10, 2026 reports the same pattern on a Microsoft Azure Sponsorship account; in the comments, Spanish founder Iván de Blas (April 9, 2026) describes a €2,419.92 charge that landed on his credit card while the Azure billing portal showed €0.00. The largest case made public so far is a Microsoft Tech Community post by chrisbaker2000 on April 13, 2026: two consecutive invoices of $1,078.07 and $16,414.94 totalling $17,493.01, with the second invoice accumulating during the half of the month after the founder had already removed all Anthropic deployments.

Tominaga then drafted a Change.org petition demanding clearer warnings, visual differentiation between native and Marketplace models, refunds for affected founders, and a public acknowledgement. It launched March 11, 2026, and as of May 5, 2026 had collected 50 signatures. Within days of launch, The Register and InfoWorld covered the story. The petition itself notes a formal complaint was filed with Japan's Fair Trade Commission.

Sevriukov opened a Microsoft Q&A thread on January 20, 2026 reporting his charge. The thread was later locked by Microsoft. The page now displays the literal banner "Locked Question. You can vote on whether it's helpful, but you can't add comments or replies." Microsoft moderator Manas Mohanty did acknowledge the issue there on Feb 27 and Mar 6, 2026 before the thread was locked. A separate Q&A thread asking the eligibility question directly confirms the answer: Claude on Foundry is not covered by Founders Hub credits.

Microsoft's official statement to The Register: "We listen closely to customer feedback and are continuously working to provide clear guidance in our product documentation, including pricing details and credit eligibility." Anthropic's position, communicated to affected founders: it has no visibility into Azure billing and cannot process refunds independently.

This is not a UI bug. It is the Marketplace billing model working as designed, and it is the single most important thing to understand before you deploy any third-party model on Azure, including Claude, Llama, Mistral, Cohere, or anything else that did not originate inside Microsoft.

TL;DR

Claude on Azure is sold through Azure Marketplace, not as a first-party Azure service. Founders Hub credits, MSDN credits, sponsored credits, and free-trial credits do NOT cover Claude usage. If a sponsored subscription has a credit card on file, the credit card is charged instead of credits. Only paid Enterprise Agreement (EA) and MCA-E subscriptions can buy Claude on Azure today, with EA accounts in South Korea and CSP subscriptions excluded. Models deploy only in East US 2 and Sweden Central. Default quota is zero RPM and zero TPM, which means a manual support ticket is required to deploy at all. Plan for these realities before you commit a project to Claude on Azure.

Confirmed vs reported vs analyst commentary

This article mixes three categories of claim. Each is labeled inline so readers can apply their own evidence threshold.

Confirmed by Microsoft documentation. Marketplace billing bypasses Azure credits; CSP, sponsored, and credit-only subscriptions are excluded from Claude deployment; Claude on Foundry runs only in East US 2 and Sweden Central; default quota is 0 RPM / 0 TPM until a support ticket is filed; the AnthropicOrganizationCreationFailed error is observable in Sweden Central. All of these are linked to learn.microsoft.com pages further down.

Reported by primary journalism and named founders. Specific charges and named individuals are sourced to The Register, InfoWorld, the Microsoft Tech Community, and Microsoft Q&A threads where the founders themselves posted. The locked state of the original Sevriukov Q&A thread is verified at fetch time against Microsoft's own UI text. Citations are inline.

Analyst commentary (mine). The procurement-vs-architecture-gap framing, the multi-provider-by-design takeaway, the build-versus-direct-versus-Bedrock decision, and the pre-flight checklist are my own interpretation. They are reasonable inferences from the documented mechanics and the reported incidents, not Microsoft positions. Read them as such.

Same catalog UI, different billing reality: native models draw down credits, while Marketplace models (Claude, Llama, Mistral) bill the payment method on file.

What Actually Happened to the Founders

Three founders, three subscription types, three different invoice sizes. Same root cause.

Tominaga enrolled in Microsoft for Startups Founders Hub and received Azure credits through the program (which offers up to $150,000 in credits at the top tier). He used Foundry to deploy Claude Opus. From the Foundry catalog UI, Claude appeared next to GPT-5 and Phi with the same "Deploy" button, the same Endpoint and Key ceremony, the same dashboard. Behind the scenes, two completely different billing pipelines were running: GPT through Azure first-party billing where Founders Hub credits applied, and Claude through Azure Marketplace where they did not. He did not know this until the invoice arrived. His direct quote, captured in The Register's coverage:

The UI makes no distinction between credit-covered and Marketplace-billed models.

This trap is documented openly in Microsoft's own subscription rules but easy to miss. From the official Foundry Claude deployment documentation:

If you have an account with a credit card on file, the credit card will be charged instead of Azure Credits.

So even on a sponsored subscription with substantial unspent credits, the credit card on file gets charged the moment a Marketplace product runs. The credits sit untouched.

Founders report a support loop that became its own story. Across The Register's coverage, the Microsoft Q&A threads, and the Microsoft Tech Community post, the same description recurs: Microsoft support directed them to Anthropic; Anthropic, which says it has no visibility into Azure billing, directed them back to Microsoft. Microsoft's official statement is that it is "continuously working to provide clear guidance" on credit eligibility, but the named founders' invoices stood at the time of writing.

This is not a one-off UX bug. It is the fundamental architecture of how Azure resells third-party AI on its cloud. Microsoft has acknowledged the documentation gap and stated it is improving guidance, but the underlying Marketplace billing model itself is unlikely to change.

Why Founders Hub Credits Do Not Cover Claude

Microsoft's credit balance documentation is direct on this point:

Azure credits don't apply to certain products and services. Any usage of these offerings is billed separately and charged regardless of your available Azure credit balance. In general, Azure credits don't cover: Partner-provided products or services, along with non-Microsoft products on Microsoft Marketplace.

The Azure for Startups credit terms are even more explicit:

Startup credits cannot be used for Microsoft Azure support plans, third-party branded products, products sold through Microsoft Azure Marketplace, or products otherwise sold separately from Microsoft Azure.

And separately, the Foundry Claude deployment requirements list four unsupported subscription types:

Enterprise Accounts located in South Korea

Cloud Solution Provider subscriptions

Azure subscriptions that don't have an active pay-as-you-go billing method (for example, student, free trial, or startup credit-based accounts)

Sponsored subscriptions that only use Azure credits.

Three of those four exclusions hit Claude directly. Claude is third-party branded (it is an Anthropic product). It is sold through Azure Marketplace. Sponsored credit-only subscriptions are explicitly excluded. So Founders Hub credits cannot cover Claude usage by three independent rules at once.

This is not a Claude-specific issue. The same applies to:

Llama models from Meta
Mistral models on the Mistral Marketplace listing
Cohere models
Stability AI image models
Any other Models-as-a-Service offering that ships with a partner brand

If you are running on credits, the only AI models you can use without surprise charges are first-party Microsoft services: Azure OpenAI (GPT family, o-series), Phi from Microsoft Research, and other Microsoft-published models in Foundry. Everything else is Marketplace, regardless of how seamless the deployment UI feels.

The 1P vs 3P Decision Tree on Foundry

Foundry's model catalog mixes first-party (1P) and third-party (3P) models in the same UI without much warning. The architectural decision tree before picking a model:

Question	1P (Azure OpenAI, Phi)	3P / Marketplace (Claude, Llama, Mistral)
Billing pipeline	Azure first-party billing	Azure Marketplace
Founders Hub / startup credits cover it	Yes	No
Sponsored / MSDN / Visual Studio credits cover it	Yes	No
Free trial credits cover it	Yes (subject to limits)	No
Enterprise Agreement (EA) coverage	Yes (any geo)	Yes, EXCEPT EA accounts in South Korea
MCA-E coverage	Yes	Yes
CSP subscription support	Yes	Not supported
Pay-as-you-go subscription	Yes, no friction	Not currently - quota is zero by default
Default quota for new subscriptions	Usually allocated for OpenAI	Zero RPM, zero TPM until ticketed
Sponsored sub with credit card on file	Credits used first	Credit card charged immediately
Available regions	Many, varies by model	East US 2 and Sweden Central for Claude
Procurement category	Azure spend (cloud committed spend)	Marketplace spend (separate budget line)

The last row catches most enterprises. In a large company, "Azure spend" and "Azure Marketplace spend" are tracked separately, may sit in different budgets, are governed by different procurement teams, and have different approval thresholds. A team with full Azure budget authority may have zero authority to approve Marketplace purchases. The UI does not enforce the distinction. Finance does.

Where Claude Actually Deploys

As of April 2026, Microsoft Foundry supports a substantial Claude lineup. From Microsoft's own deployment documentation:

Model	Status	Context window	Notes
claude-opus-4-7	Preview (released April 16, 2026)	1M tokens, 128K max output	Most capable Opus, adaptive thinking only
claude-opus-4-6	Preview	1M tokens, 128K max output	Production-stable Opus generation
claude-opus-4-5	Preview	200K tokens, 64K max output	Older Opus, smaller context
claude-opus-4-1	Preview	200K tokens	Legacy, prefer 4.6 or 4.7
claude-sonnet-4-6	Preview	1M tokens, 128K max output	Frontier intelligence at scale, 1M GA
claude-sonnet-4-5	Preview	200K standard	1M context beta retires April 30, 2026, migrate to 4.6
claude-haiku-4-5	Preview	200K tokens	Speed and cost optimization
claude-mythos-preview	Gated research preview	1M tokens, 128K max output	Cybersecurity, autonomous coding, long-running agents

All Claude models on Foundry are deployment-type "Global Standard" only. There is no PTU, no provisioned throughput, no DataZone yet (US DataZone is on the roadmap). Two regions support deployment, period:

East US 2 (the primary region, most stable)
Sweden Central (added later, currently flakier in practice)

If your data residency requirements pin you to West Europe, UK South, Australia East, Germany West Central, or any other region, Claude on Azure is not an option. You either deploy via the Anthropic API directly (different data flow, different DPA), via AWS Bedrock (broader region coverage), or pick a different model.

There is one more wrinkle. Anthropic enforces its own "Supported Regions Policy" on top of Azure's regional deployment. Even if your Azure tenant is in a supported deployment region, Anthropic may block the model based on the geography of the user invoking it. Verify both layers.

The Sweden Central availability also comes with an active failure mode. Multiple practitioners report deployment failing with this error on Claude Sonnet 4.6 and Claude Opus 4.6:

{
  "status": "Failed",
  "error": {
    "code": "ResourceOperationFailure",
    "message": "The resource operation completed with terminal provisioning state 'Failed'.",
    "details": [{
      "code": "AnthropicOrganizationCreationFailed",
      "message": "Internal Server Error."
    }]
  }
}

Microsoft Q&A threads tracking this failure have remained open without a published root cause. The only known workaround is to retry the deployment in East US 2 instead. If you are designing architecture today, treat Sweden Central as best-effort and assume East US 2 is your real production region. Plan data residency and latency math accordingly.

Default Quota Is Zero. Yes, Zero.

This is the second pitfall, and it costs more days of engineering time than the billing surprise costs dollars.

Even on a fully eligible Enterprise Agreement subscription, in East US 2, with the Microsoft.CognitiveServices provider registered and the right RBAC, the default Claude quota is zero. Zero RPM. Zero TPM. From the Microsoft Foundry quota table:

Model	Enterprise + MCA-E RPM	Enterprise + MCA-E TPM
claude-opus-4-7	2,000	2,000,000
claude-opus-4-6	2,000	2,000,000
claude-sonnet-4-6	2,000	2,000,000
claude-haiku-4-5	4,000	4,000,000

The "Default" column is what you get from Microsoft Foundry the moment the subscription becomes eligible. Nothing. The "Enterprise and MCA-E" column is what you get after a manual quota request through the quota increase request form is approved. This means every Claude project on Azure starts with a support ticket as a hard prerequisite, not as an escalation step.

The design intent is confirmed in Microsoft Q&A responses: Claude models are Marketplace-based offerings, so quota is not auto-assigned to every subscription. Even on subscriptions with valid billing and accepted Marketplace terms, the quota can show 0/0 until backend enablement is processed by Microsoft engineering.

The blast radius of this is bigger than it looks. If your dev tenant has Claude working and your prod tenant does not, your CI/CD pipeline will fail silently in production with what looks like a permissions issue. The error message gives no hint that the actual problem is "your prod subscription has not been backend-enabled by a Microsoft engineer yet."

Plan to file the quota request as the first action, on day one of the project, before any code is written.

Real Cost Math: Claude Opus 4.7 vs GPT on Azure 1P

Claude Opus 4.7 is the current production-aimed Anthropic model on Foundry, released April 16, 2026. Pricing per million tokens:

Input: $5 per million
Output: $25 per million
Cache reads: roughly 10% of input rate (about 90% savings)
Cache writes: roughly 25% premium over input
Batch: 50% discount on async workloads

The headline rates are unchanged from Opus 4.6, but the real cost is not, because Opus 4.7 ships with a new tokenizer that can produce up to 35% more tokens for the same input text. The multiplier is 1.0x to 1.35x in practice, with the higher end most often on code, structured data, and non-English text. So a request that cost $0.10 on Opus 4.6 can cost $0.10 to $0.135 on Opus 4.7 for identical work. A team running ~$10/day on 4.6 should expect ~$10 to $13.50/day on 4.7. Across a year that is up to a $1,200 swing on a small workload, before factoring scale-out.

Compare to GPT family on Azure 1P (first-party):

Use case (rough)	Claude Opus 4.7 on Azure (Marketplace)	GPT family on Azure OpenAI (1P)
10K req/day, 8K input, 1K output	~$190/day on Opus 4.7 (after tokenizer multiplier)	Substantially cheaper, varies by GPT tier
Founders Hub / startup credits cover it	No	Yes
Subscription required	EA or MCA-E + non-South-Korea + zero-quota ticket	Most subs work, no ticket
Tokenizer surprise	Up to 35% more tokens vs the same content on 4.6	Stable across versions
Available regions	East US 2, Sweden Central	Many
Reasoning quality on hard tasks	Strongest available 4.x family for long-context coding and agentic work	Strong; Opus 4.7 typically wins on long-context and multi-hour agent runs

The math says: pick Claude Opus 4.7 when its reasoning ceiling and 1M context actually win for the workload, and you have a paid budget that can absorb both Marketplace billing and the tokenizer multiplier. Pick GPT on Azure 1P when good-enough reasoning meets the bar, you want credits to apply, and you do not need 1M context. There is no neutral default.

For high-volume classification or routing, Claude Sonnet 4.6 ($3/$15 per million tokens) or Haiku 4.5 is usually the right call. Sonnet 4.6 has 1M context generally available. Sonnet 4.5's 1M-context beta retires April 30, 2026, so any code still using the context-1m-2025-08-07 beta header on Sonnet 4.5 must migrate before then.

The Pre-Flight Checklist Before You Deploy Claude

Most of this article's pain is avoidable with a 30-minute pre-flight check. Run it before you commit any project to Claude on Azure.

Confirm subscription eligibility. Run az account show. Verify the subscription is EA (and NOT a Korean EA) or MCA-E with a billing method. CSP, sponsored, free-trial, MSDN, and credit-only subscriptions cannot deploy Claude.
Confirm credit applicability. If you are on Founders Hub, MSDN, sponsorship, or any credit pool, assume credits do NOT apply to Claude. If a credit card sits on the same subscription, that card is charged the moment Claude runs. Either commit to paid spend or pick a 1P model.
Pick a region. East US 2 if at all possible. Sweden Central only if data residency demands it, with a documented fallback for the AnthropicOrganizationCreationFailed error.
File the quota ticket BEFORE writing code. Default quota is zero. Request the Enterprise/MCA-E allocation for the specific Anthropic models on the specific subscription. Day one, not when CI/CD is failing.
Set up Azure Monitor budget alerts on Marketplace category specifically. Marketplace charges roll up under a separate billing dimension. Filter on MeterCategory containing the Anthropic publisher, not just total Azure spend.
Document the procurement category to finance. Tell finance that AI workload spend will land partly in Azure billing and partly in Marketplace billing. Confirm the budget structure supports both.
Decide the fallback model. If Anthropic gets pulled, your subscription gets reclassified, or pricing shifts, what is your path? GPT-5 on Azure 1P? Claude direct via Anthropic API? AWS Bedrock? Have an answer documented before you start.
Plan for the 35% tokenizer multiplier. If you are migrating from Opus 4.6 to 4.7, expect costs up to 35% higher for the same inputs. Decide whether the quality gain justifies it or whether 4.6 is the better cost ceiling for your use case.

Should You Deploy Claude on Azure At All?

This is the architecture question hiding under the cost question. There are three real choices for running Claude in production right now:

Option A: Claude on Azure AI Foundry (Marketplace).
Wins when Microsoft is your dominant procurement vehicle, you need Foundry orchestration, you want Claude to sit alongside GPT-5 behind the same APIM gateway, and you have EA or MCA-E billing in a supported geography. Loses on credits, regions, CSP support, and the zero-default quota ceremony.

Option B: Claude direct via Anthropic API.
Wins on speed (instant access, no quota tickets), region flexibility (Anthropic has more regions than Azure does for Claude), latest model availability (Anthropic ships new Claude versions to their direct API first by days to weeks), and credits if you negotiate Anthropic startup credits separately. Loses on Microsoft procurement consolidation, Foundry-native tracing, and any compliance posture that requires "everything goes through Azure."

Option C: Claude via AWS Bedrock or GCP Vertex.
Wins for shops already on AWS or GCP, where Claude integrates with the cloud-native observability stack and Marketplace billing is a single bill from a single vendor. Loses on Microsoft integration entirely, but for organizations where Microsoft is not the primary cloud, this is often the cleanest path.

The honest answer is that most enterprises end up with Option A for production and Option B for development. Architects who pretend "Azure has Claude now, problem solved" without understanding the Marketplace mechanics will hit the same trap thirty-five founders documented in the petition.

What This Tells You About Multi-Provider AI Architecture

Take a step back. Why does this billing model exist?

Because Azure is not a model factory. Azure is a procurement and compute layer that resells AI models from many parties, including Anthropic, Meta, Mistral, Cohere, Stability, and its own OpenAI partnership. The Marketplace billing model exists because each of those vendors has its own DPA, its own pricing, its own region availability, its own quota system, and its own subscription rules. Microsoft cannot absorb all of that into one billing pipeline. They can hide it behind a unified UI, which they do. They cannot make the underlying complexity disappear, no matter how seamless the catalog feels.

For architects, the practical takeaway is provider-neutral by design. The model layer of your AI architecture will always be heterogeneous. Build for that. Use APIM or your own gateway as a routing layer that can shift workloads between Claude (Azure or direct), GPT-5, Llama, and whatever ships next. Treat the question "where does this model run, on what billing pipeline, in what region, with what subscription" as a first-class architecture concern, not a procurement concern that gets handed off.

The founders who got burned were not technically wrong. Their architecture worked. Their procurement assumptions did not match procurement reality. That gap, between architecture and procurement, is exactly where senior AI architects earn their seat at the table.