Azure AI Foundry is Microsoft's strongest enterprise governance play, and a poor first purchase. It is the platform that unifies Azure OpenAI Service, Azure AI Search and Azure Machine Learning under one control plane, one identity model, and one place to watch what your agents are actually doing.
Think of it as a control tower. Superb when forty aircraft are circling. Very expensive when you own one plane. Which is why Azure AI Foundry earns its keep at your second and third use case rather than your first. (Microsoft renamed it Microsoft Foundry at Ignite in November 2025. Most contracts and job specs still say Azure AI Foundry, so that is the term we will use here. Same platform.)
Now the part the product pages leave out. Most Azure AI Foundry projects do not fail in the model. They fail in the fortnight after the demo, when someone asks who signs off on what the agent just did, and nobody has an answer. The platform was never the bottleneck. The data lived in three systems with three different permission models, and the business owner who was meant to accept or reject the output had never been named.
Azure AI Foundry unifies the AI services you were probably already paying for: Azure OpenAI Service, Azure AI Search, Azure Machine Learning, Microsoft Fabric. One control plane. One identity model. One observability layer.
The rebrand to Microsoft Foundry was not cosmetic, and the substance changes what you are buying.
So what does this actually buy you? Not innovation. It buys the ability to run more than one AI workload without each one becoming its own governance project. That is the entire case for a platform over a point solution, and it only pays off if you intend to build more than one thing.
Related IC reading: Azure Machine Learning deployment and MLOps guide
Every engagement we start begins with the same four questions. They are boring questions. They also predict whether an AI transformation programme reaches production better than anything technical does.
Score each dimension 0 to 3, where 0 means not true at all and 3 means fully true today.
Can the agent reach the data it needs, legally, technically, and cleanly enough to be useful? Not "do we have the data". The real questions are whether it sits in a system with an API, whether its permission model survives an agent reading it on a user's behalf, and whether a human would recognise the answer it produces.
The failure we see: the knowledge base exists, but it is 40% out of date and nobody owns it. The agent then repeats, with total confidence, a policy that was retired in 2023.
Is there a named individual, not a committee and not "the business", who will accept or reject what the agent produces? Someone whose job gets better if it works?
The failure we see: the AI project belongs to the innovation team. The process it automates belongs to operations. Operations was never asked. The pilot works beautifully and is never adopted.
Do you know what happens when the agent is wrong? Who is accountable, what the audit trail looks like, where a human is required in the loop?
The failure we see: this gets deferred to "before go-live", and then it blocks go-live for four months. In regulated sectors it is the single most common reason a working prototype never ships.
Will the team receiving the output change how they work? Have they been told? Is anyone's target changing?
The failure we see: the agent drafts the response, and the draft is ignored, because nobody's workload actually shrank. They now review AI output and do the original task. More work. Not less.
More often than not, the enterprises who arrive convinced they are at Deploying score somewhere in Piloting. That is not a criticism. It is the normal state of an organisation that has run AI experiments for eighteen months without a platform decision behind them.
This is the section most vendor content skips, so let's be direct about it.
Azure AI Foundry carries no licence fee. Microsoft charges for the underlying services it orchestrates, so your invoice will show Azure OpenAI Service, Azure AI Search, Azure Machine Learning and storage. It will not show a line called "Foundry". This confuses finance teams with impressive reliability.
Take a claims-triage agent handling 20,000 cases a month. Each case consumes roughly 6,000 input tokens (the case plus the retrieved context) and 800 output tokens.
Then comes the part that actually decides the business case: the engineering to ingest and maintain the document estate, and the reviewer time to build and maintain the evaluation set. Those are measured in person-weeks rather than dollars per token, and in year one they will typically dwarf the platform bill.
Model your own case against the Azure pricing calculator, and treat every published range, ours included, as an order of magnitude rather than a budget. The variance between two nominally similar deployments is enormous, and it is driven almost entirely by document volume and query patterns.
Use Microsoft Copilot if what you need is AI inside Microsoft 365, Dynamics or GitHub, and you can live with how it behaves out of the box. It is cheaper, it is faster, and it needs no engineering team.
Use Azure AI Foundry when at least two of these are true:
None of those true? Buy Copilot licences and stop reading. We would rather tell you now than after a discovery phase.
.webp)
Governance is the reason enterprises choose Azure AI Foundry over cheaper alternatives. It is also where most prototypes go to die. Four questions decide whether yours ships.
Can the agent see something the user cannot?This is the failure mode that ends projects. An agent that indexes a document estate and answers questions from it can leak content the asking user has no right to see. The fix is that retrieval must respect your existing permissions, so the agent inherits the user's access rather than holding blanket access of its own. Foundry supports this through RBAC (role-based access control: permissions granted to a role such as "claims handler" rather than to individuals, so access follows the job rather than the person) and identity-aware retrieval. It does not do it by accident. You have to design it in.
Who is accountable when it is wrong?Entra Agent ID gives the agent a directory identity, which makes its actions attributable and revocable. Without one, "the AI did it" becomes an audit finding you cannot answer.
Where does the data physically go, and who sees it?Model choice affects data residency. Foundry hosts many models directly, but third-party models reached through the catalogue carry their own terms. If you operate under EU data residency requirements, this is a procurement question rather than a technical one, and it belongs before you pick a model rather than after you have built on it.
What stops the agent doing something harmful?Content filtering, guardrails, and intervention points on prompts, outputs and tool calls. The intervention point that matters most in an enterprise is the tool call: the moment an agent stops answering and starts acting on a system. A human approval step there is usually the difference between a risk committee approving and refusing.
And the risk nobody puts on a slide? Silent degradation. A model version updates, the agent gets quietly worse, and nobody notices for six weeks because there is no evaluation set. Which is precisely why we build one before we build anything else.
Two things have shifted enough since 2025 that older guides now mislead.
Agent orchestration. Microsoft folded its two agent frameworks, AutoGen (the multi-agent research project) and Semantic Kernel (the enterprise SDK), into the Microsoft Agent Framework, built by the same teams. It supports two orchestration modes, and choosing between them is a business decision dressed as a technical one.
Microsoft's own documentation carries a line worth reading aloud to any team that is over-reaching: if you can write a function to handle the task, write the function instead of using an agent.
Multimodal capability. Foundry Tools cover text, documents, images, speech and video in one platform. In practice that means a claims agent can read the adjuster's notes, the PDF policy, and the photograph of the crumpled bonnet in a single workflow, rather than across three integrations and a hand-off. For document-heavy industries, this is usually where the real time saving hides. It is also chronically under-explored, because teams anchor on chatbots and stop looking.
Most implementation roadmaps are the same five phases wearing different nouns. Assess, design, pilot, scale, optimise. They are not wrong, exactly. They are just not information. Here is what we do differently.
Before any architecture, we pull 200 real cases from the process in question and sit with the business owner while they label what a correct answer looks like. It is tedious. It is also the most valuable week of the engagement, because it produces an evaluation harness: a fixed set of real cases with known-correct answers, run automatically against the agent every time anything changes, so you can prove the system improved rather than argue about it.
Skip this, and six months later you will be debating whether the agent has got worse. Based on vibes.
Here is the shape of the harness we leave behind. It is deliberately not the sample from Microsoft's docs, which scores a single quality metric and prints a number. Three things differ, and each one comes from a project where the missing check cost us. We gate on three dimensions rather than one. We refuse to let a model judge escalation behaviour, because "should this have gone to a human?" is a question you must be able to defend to a regulator without saying "another model thought so". And it fails the build, rather than logging a warning nobody reads.
# eval_harness.py — IC pattern for Azure AI Foundry agents
# Runs on every model change, prompt change and index rebuild. Blocks the deploy.
import json, sys
from dataclasses import dataclass
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
# The golden set comes out of ground-truth week: real cases, labelled by the
# business owner who has to live with the output. Each record carries WHO
# labelled it and WHEN, because in 14 months someone will dispute a label,
# and "the business agreed" is not an answer.
GOLDEN_SET = "eval/golden_set.jsonl" # ~200 cases, versioned in git
BASELINE = "eval/baseline.json" # scores from the last shipped build
@dataclass
class Case:
id: str
payload: dict
expected_outcome: str # the label
must_escalate: bool # ground truth: does this REQUIRE a human?
visible_to: str # the requesting user's identity
@dataclass
class Result:
correct: bool
escalation_ok: bool # deterministic, not model-judged
permission_ok: bool # did it cite anything this user cannot see?
def evaluate(agent, case: Case) -> Result:
run = agent.run(case.payload, on_behalf_of=case.visible_to)
# Gate 1. Correctness. Model-judged is acceptable here, with a rubric.
correct = judge_outcome(run.outcome, case.expected_outcome)
# Gate 2. Escalation. NOT model-judged. The agent either handed off or it
# did not. Silent over-confidence on a must-escalate case is the failure
# that ends projects, and a fuzzy scorer will not catch it.
escalation_ok = (run.escalated == case.must_escalate)
# Gate 3. Permission integrity. Every citation the agent returned must be
# readable by the user who asked. This catches the leak BEFORE a user does.
permission_ok = all(
can_read(case.visible_to, source.id) for source in run.citations
)
return Result(correct, escalation_ok, permission_ok)
def main() -> int:
client = AIProjectClient(endpoint=FOUNDRY_ENDPOINT,
credential=DefaultAzureCredential())
agent = client.agents.get(AGENT_ID)
cases = [Case(**json.loads(line)) for line in open(GOLDEN_SET)]
results = [evaluate(agent, c) for c in cases]
scores = {
"accuracy": mean(r.correct for r in results),
"escalation": mean(r.escalation_ok for r in results),
"permission": mean(r.permission_ok for r in results),
}
baseline = json.load(open(BASELINE))
# Permission is absolute. One leak fails the build. There is no tolerance
# band here, and every client who argued for one later agreed.
if scores["permission"] < 1.0:
fail(f"PERMISSION LEAK on {count_failures(results)} case(s). Blocked.")
# Accuracy and escalation are graded against the LAST SHIPPED BUILD, not an
# absolute bar. Absolute bars get negotiated downward. Regressions do not.
for gate in ("accuracy", "escalation"):
drift = scores[gate] - baseline[gate]
if drift < -0.02: # 2pp regression tolerance
fail(f"{gate} regressed {drift:.1%} vs shipped build. Blocked.")
print(f"PASS {scores} (baseline {baseline})")
return 0
if __name__ == "__main__":
sys.exit(main())
A PoC proves the technology works. Everybody already knows the technology works. So instead we build one narrow path all the way to production: one workflow, one data source, real users, real permissions, a real audit trail. Deliberately unimpressive in scope. Deliberately complete in depth.
The point is that it surfaces the integration and governance problems in week three, when they are cheap, rather than in month five, when they are not.
Entra Agent ID, RBAC, content filters and the human-in-the-loop escalation path all get configured during the slice. In regulated clients this is non-negotiable. In unregulated ones, it is what stops the second and third use case each costing as much as the first.
The harness from stage 1 gates every release. No agent expands its scope until it clears the bar on cases it has never seen. This is the difference between a fleet and a mess.
We leave your team owning the evaluation harness and the runbook, not just the code. A partner who has to be re-engaged for every model update has not finished the job.
For a single well-scoped workflow, the engineering to reach a production thin slice takes weeks. But the honest constraint is almost never engineering. A realistic elapsed timeline looks like this.
That security-review row is where two identical projects diverge by a quarter. So ask any prospective partner what their timeline assumes about your organisation, and be sceptical of anyone who answers before they have looked at your data estate.
The feature comparison matters far less than the vendors would like it to. In practice, the decision was made for you years ago by two things: where your data lives, and where your identity model runs. Let's compare them anyway, because you will be asked to.
| Feature | Azure AI Foundry | AWS Bedrock | Google Vertex AI |
|---|---|---|---|
| Strongest when | Your organisation runs on Microsoft: Entra, M365, Fabric, Dynamics | Your data and workloads already live in AWS | Your data engineering already lives in BigQuery |
| Governance model | Directory-native (Entra Agent ID, RBAC). The strongest of the three for regulated enterprises | Solid IAM, thinner agent-governance layer | Strong ML tooling, governance less agent-centric |
| Best at | Agent fleets under shared governance | Model access and breadth | Genuine ML experimentation rather than agent assembly |
| Watch out for | Rebrand churn and migration deadlines | Enterprise governance needs more assembly | Weakest fit if your workforce sits on M365 |
Here is the strategic point rather than the technical one. Choosing the platform your data is not on, because it scored better on a feature grid, is a decision you will pay for in integration work every quarter for the next five years. Integration tax compounds. Feature gaps close.
Which leads somewhere slightly uncomfortable. If you are a Microsoft shop, the platform question is largely answered already, and the real work is the readiness question above. Three months of vendor bake-off is often three months of not having the harder conversation.
Microsoft's unified platform for building, deploying and governing AI applications and agents. It sits above Azure OpenAI Service, Azure AI Search and Azure Machine Learning, and gives them one control plane, one identity model and one place to monitor what your agents are doing.
The platform itself carries no licence fee, and you can create a project and explore at no cost. You pay for the services underneath: model inference (tokens), Azure AI Search, storage, compute and monitoring. So it is free to start and not free to run. The costs land on your Azure bill under the individual service names rather than under "Foundry".
Azure OpenAI Service is one component. Azure AI Foundry is the platform around it. OpenAI Service gives you model endpoints; Foundry adds the model catalogue (including non-OpenAI models such as Anthropic's Claude), agent tooling, retrieval, evaluation, observability and governance. If all you need is a model endpoint, you do not need Foundry. If you need to run agents in production and evidence what they did, you do.
Copilot if you want AI inside Microsoft 365, Dynamics or GitHub and can accept how it behaves out of the box, because Copilot is a product. Azure AI Foundry if you need to build something specific to your business, reach your own data under your own permissions, or satisfy a regulator. Foundry is a platform for building products, and you should not buy a platform to solve a problem a product already solves.
Yes. Microsoft renamed it at Ignite in November 2025, and the January 2026 Product Terms formalised it. Your contracts and internal documentation may say either.
Model endpoints are REST APIs, so any language can call them. For agent development, the Microsoft Agent Framework currently targets Python and C#/.NET, with Microsoft committing to parity between the two at general availability. If your engineering team is mainly Java, Go or TypeScript, the agent tooling is thinner and you should validate that before committing. It is a real constraint, and it is not prominent in the marketing.
Your existing inference workloads keep running, so the rename is not a migration event. The deadlines, though, are real. Azure ML SDK v1 support ends on 30 June 2026, and CLI v1 support already ended in September 2025, per Microsoft's own migration guidance. Anything built on azureml-sdk needs a plan now. The Assistants API is also being retired, so confirm the current date against Microsoft Learn before you plan around it.
Four, in the order they tend to bite. Permission leakage, where an agent surfaces content the asking user should never see. Silent degradation, where the agent quietly gets worse after a model update and no evaluation set catches it. Platform churn, because two rebrands in twelve months and real deprecation deadlines mean documentation and training go stale fast. And cost drift, because token spend scales with usage, and without model routing it scales faster than the value does. All four are manageable. None are managed by default.
A production thin slice, meaning one workflow with real users and real governance, takes weeks of engineering. Elapsed time is usually longer, and the variable is internal: security review and data access approval routinely take two to six weeks and are the single biggest driver of schedule. Be wary of any timeline quoted before someone has looked at your data estate.
A platform engineer who owns the Azure subscription and its identity model, a named business owner per use case, and compliance engaged before build rather than at sign-off. If you cannot name the person who will accept or reject the agent's output, you are not ready. That is a four-week problem, though, not a four-month one.
It works. But the economics favour organisations running more than one AI workload, because the platform's value is governing many agents once instead of many times. With a single use case, that advantage does not exist yet.
Azure AI Foundry's advantage is governance rather than capability, because every major platform can call a good model. What Foundry gives you is a fleet of agents running under one set of rules. Which is why it earns its cost at your second and third use case, not your first.
The bill is not the licence, because there is no licence. It is tokens, retrieval, ingestion and people, and ingestion is the line nobody budgets for. Everything else gets decided before a line of code is written, by four unglamorous conditions: reachable data, a named decision owner, a governance answer, and a team willing to change how they work.
Is the platform the hard part? No, of course not. You are the hard part.
Score yourself against the Foundry Readiness Model. If you land in Exploring, the most useful thing we can do for you is say so out loud. And if you want a second opinion on where you actually sit, or you have a prototype that will not cross into production and you cannot work out why, talk to us.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
Inês Silva is a Project Manager with over four years of experience writing about software delivery, agile methodologies, and tech leadership. Because she started her career as a developer, Inês brings a real, deeply technical understanding to the management side of things. She loves bridging the gap between big-picture business strategy and day-to-day engineering execution, and she's passionate about sharing practical tips that help teams collaborate better and ship great products.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
