100,000 Orgs on Microsoft Foundry: 71% Are Raising AI Budgets

Microsoft published its agent cost playbook on August 12, 2026 and put the most useful admission inside a capability table rather than the headline: native budgets and enforcement inside Foundry are still coming, not shipping. The same post says more than 100,000 organizations already build on Microsoft Foundry, and a Microsoft-commissioned IDC survey of more than 4,000 business leaders found 71% plan to increase AI budgets.

Read those two facts together and the problem is obvious: spend is scaling now, while the hard stop that keeps one misbehaving agent from eating a quarter of your inference budget lives in a different product. If you run Foundry agents in production, closing that gap is this quarter's work. Here is the cost model, the controls that hold today, and the honest split between shipped and roadmap.

What Foundry Agent FinOps Means

Foundry agent FinOps is the practice of treating every agent call as a metered purchase with a named owner, a bounded budget, and a measurable return. Microsoft, in a post authored by Foundry corporate vice president Tina Schuchman, splits the discipline into three decisions that run at three different speeds: optimize the request while it runs, optimize the agent workflow over days and weeks, and govern the spend continuously.

That split is a good mental model even if your agents run on Bedrock or a self-hosted stack. Runtime optimization is code. Workflow optimization is experiments with evaluators attached. Governance is policy that has to hold at 3am during a traffic spike, when nobody is watching a dashboard. Most teams do the first, sometimes the second, and skip the third until an invoice forces the conversation. That was the failure pattern behind the $500M enterprise Claude bill: the engineering worked fine, the accounting did not exist.

Why Agent Costs Grow While Your Prompts Stay the Same

Agent costs grow because models are stateless, so the full context is resent with every single call. A user typing "and the second one?" can trigger a request that carries a 3,000-token system prompt, every tool definition, the whole conversation history, and freshly retrieved documents. Microsoft states this plainly, and it explains surprise invoices better than any argument about model choice.

Agents then add a second multiplier. Instead of one prompt and one completion, an agent evaluates options, retries actions that fail, and calls several tools before it answers. One user request becomes six or twelve model calls, which is why workflow design sets your bill more than model selection does.

Three drivers compound:

• Static overhead per call. System prompt plus tool schemas, paid again on every hop.
• History growth. Each turn appends the previous turn to the next input.
• Fan-out and retries. A failed tool call is billed exactly like a successful one.

The Agent Cost Model You Can Compute Today

The working formula is cost per resolved task, not cost per token: calls per task, times average input tokens at your input rate, plus calls per task times average output tokens at your output rate, all multiplied by a retry factor. Four variables, all of which you can pull from traces today.

This is the table I would put on the wall before touching a single model setting. It maps each driver to the Foundry lever that reduces it and to the team that owns the fix, because a cost driver with no owner never gets fixed.

Worked example: 200,000 support tickets a month

Take a triage agent averaging six model calls per resolved ticket, a 3,200-token static prefix, 4,000 tokens of retrieved context, roughly 1,200 tokens of history added per hop, and 400 output tokens per call. At illustrative frontier rates of $5 per million input and $30 per million output, that is about 61,200 input tokens and 2,400 output tokens per ticket, or $0.38. Apply a 1.4 retry factor and you land near $0.53 per ticket, which is $106,000 a month at 200,000 tickets.

Now apply the levers. Toolboxes cut the prefix to 900 tokens and caching stops you paying to recompute it. Agentic retrieval trims context from 4,000 to 1,500 tokens. Session memory drops history growth from 1,200 to 400 tokens per hop. The agent optimizer promotes a configuration that resolves in four calls instead of six, and the router sends 70% of calls to a small model at $0.50 and $1.50 per million. Per ticket lands near $0.042 including retries, or roughly $8,400 a month.

Do not take the absolute numbers to your CFO, because your rates and token mix differ. Take the ratio. The gap between a naive agent and a tuned one is an order of magnitude, and none of it came from a discount negotiation. Verify current rates against the LLM API pricing tracker before you model anything.

What Foundry Enforces Today vs What Is Roadmap

The honest answer: Foundry can optimize spend today and report on it at model and deployment level, but it cannot yet stop an agent at a budget line by itself. Enforcement currently sits in Azure API Management and Azure Cost Management. Microsoft says native budgets are coming soon and richer per-agent attribution is on the roadmap, which is worth planning around rather than waiting on.

Token Runaway Controls That Hold During a Spike

The only control that reliably holds during a runaway loop is a token rate limit enforced at the gateway, in front of the model endpoint. Everything else is detection, and detection arrives after the money is gone. If you standardize on Azure API Management, put the AI Gateway in front of your Foundry endpoints and set token quotas per subscription key, per team, and per environment.

Then add the controls Microsoft does not give you yet. Cap iterations inside the agent loop, so a planner that cannot converge stops at eight steps instead of eighty. Set a per-task token ceiling in code and fail loudly when a task crosses it. Tag every request with an agent ID and session ID you can group by in your own telemetry, since per-agent attribution is still a roadmap item. Separate dev and production keys so a bad prompt loop in a notebook cannot spend production budget.

One control that gets skipped: a per-agent kill switch wired to a feature flag rather than a deploy. When an agent starts spending five times its normal rate, you want it off in seconds without shipping code. Developer teams reacted the same way to Copilot usage-based billing: metered AI without a visible cap changes behavior only once somebody sees the number.

Unit Economics: Cost Per Resolved Task, Not Cost Per Token

The only agent metric worth reporting upward is cost per successfully resolved task, because token dashboards reward the wrong behavior. A cheaper model that fails 30% of the time and triggers a retry is more expensive than the frontier model that resolves on the first pass, and a token chart will tell you the opposite.

Three numbers make the case in a budget review: cost per resolved task, which finance can compare against the manual process; resolution rate, which stops anyone shipping a cheap model that quietly degrades quality; and the trend of that unit cost, which is what Microsoft means by running agents as a managed investment. Sam Altman made the same point from the supplier side when he called enterprise token budgets a huge issue at 100 billion tokens a month.

If you already run tool-heavy agents, the request-level math in our GPT-5.6 tool calling FinOps guide pairs directly with this post: that one covers tokens per model turn, this one covers tokens per business outcome.

Our Analysis: The Engineer-vs-Token Line Finance Will Draw

Here is what the four-part series framing tells you about the market. Microsoft is not selling cheaper tokens, it is selling the accounting layer around them, because the buying committee changed. Agent spend moved from an engineering line to a budget review, and the person asking questions now compares your inference bill against headcount.

That comparison is where teams lose. An engineer costs a bounded, forecastable amount and brings review judgment, on-call coverage, and domain knowledge no context window holds. An agent costs an unbounded amount that scales with usage you do not control, and it feels free to the employee triggering it while finance pays. Without a features-shipped or tickets-resolved line next to the token line, the agent looks expensive and unpredictable while the manual engineer looks cheap. The IDC number cuts both ways: 71% intend to raise budgets, and intent survives exactly one bad quarterly review.

My read on the roadmap gap is that it is a design constraint, not a footnote. Assuming native Foundry budgets land next quarter is how you end up with no enforcement at all. Build the gateway limits, loop caps, and correlation IDs now, and treat native budgets as code you get to delete later. Teams that instrument attribution themselves can prove ROI the day finance asks instead of starting a two-week trace archaeology project.

The forecast: through the rest of 2026, the difference between agent programs that scale and ones that get frozen will be attribution, not model quality. Frontier models are close enough on most enterprise tasks that the winning team is the one who can say what a resolved ticket costs. If you are weighing agents against roles, run the numbers through the Will AI Replace Me tool first, because engineers plus agents usually beat agents alone on cost per outcome.

The Foundry Agent Budget Checklist

Work this top to bottom. The first five are cheap and pay back within a sprint.

1. Instrument first. Log agent ID, session ID, model, input tokens, output tokens, and resolution outcome per call.
2. Compute cost per resolved task for your three highest-volume agents before changing anything.
3. Trim tool definitions with toolboxes so each request carries only the tools it needs.
4. Freeze static prefixes byte-for-byte so caching actually hits.
5. Cap the agent loop at a fixed maximum number of steps and a per-task token ceiling.
6. Deploy token rate limits at the Azure API Management AI Gateway per key, team, and environment.
7. Route by request class. Small model for classification and triage, frontier model only on escalation.
8. Replace history resend with memory for anything longer than three turns.
9. Cut retrieval size with agentic retrieval and measure resolution rate before and after.
10. Attach evaluators, then let the agent optimizer promote configurations against them.
11. Move latency-tolerant work to Batch and predictable high volume to Provisioned Throughput.
12. Set Azure Cost Management alerts at 80% per subscription, and add a per-agent feature-flag kill switch.

Sources

• Microsoft Azure Blog, "The Economics of Agent Optimization: From pilots to measurable returns", August 12, 2026, by Tina Schuchman, corporate vice president, Microsoft Foundry: azure.microsoft.com
• IDC survey of more than 4,000 business leaders, commissioned by Microsoft, cited in the post above for the 71% figure
• Cost math, tables, checklist, and analysis here are our own, built from the capability list in the source

Key Takeaways

• 100,000+ organizations build on Microsoft Foundry, per Microsoft, making agent cost discipline a platform-scale problem.
• 71% of more than 4,000 business leaders in a Microsoft-commissioned IDC survey plan to raise AI budgets, so the constraint is governance, not funding.
• Native Foundry budgets and enforcement are roadmap, not shipped: token rate limits live in the Azure API Management AI Gateway and budgets live in Azure Cost Management today.
• Per-agent and per-session attribution is also roadmap, so instrument your own correlation IDs now.
• Stateless models resend full context every call, which is why an agent averaging six calls per task can cost 10x a tuned one on identical work.
• For developers: cap the agent loop, freeze static prefixes for cache hits, trim tool schemas with toolboxes, and report cost per resolved task instead of tokens.
• What to watch: the remaining three posts in the Microsoft series, and whether in-platform Foundry budgets plus Agent 365 chargeback ship before enterprise 2027 budget cycles close.