AI and automation
Azure AI Foundry
Microsoft Foundry
Azure AI Foundry, rebranded from Azure AI Studio and now increasingly referred to simply as Microsoft Foundry, is Microsoft's unified platform for building, testing, deploying, and governing custom AI applications and agents on Azure.
Why Azure AI Foundry matters in a Microsoft estate
Azure AI Foundry matters when teams want AI support without losing control of identity, data, approvals, and audit evidence. In the EfficientEther portfolio, AI terms usually connect to governed workflows, Copilot readiness, or agentic packaging where humans still review important outputs.
How Azure AI Foundry shows up in practice
It gives organisations and developers a single environment to select a foundation model, from OpenAI's GPT family, Microsoft's own Phi models, or a wide catalogue of third-party and open-source models through the Foundry Model Catalog, and build an application or agent around it, rather than consuming AI only through a pre-built product like Microsoft 365 Copilot. Where Copilot is a fixed, largely pre-built assistant experience embedded in Office apps and constrained to the scenarios Microsoft has designed for it, Foundry is the platform organisations use when they need something genuinely custom: an application grounded in a specific proprietary dataset, an agent that calls internal line-of-business APIs, a customer-facing chatbot with tightly controlled scope and tone, or a workflow that a pre-built Copilot simply wasn't designed to handle.
It's aimed at a developer and platform-engineering audience rather than end users directly. Foundry's core practical capabilities centre on model selection and comparison, allowing teams to evaluate different foundation models against the same task on cost, latency, and quality before committing; grounding, most commonly through retrieval-augmented generation connecting a model to an organisation's own documents or data via Azure AI Search, so responses are based on the organisation's actual content rather than the model's general training data alone; fine-tuning for organisations that need a model adapted more deeply than prompting and grounding alone can achieve; and an agent service for building the kind of multi-step, tool-using agentic AI applications that go beyond single-turn question and answer.
Cost and governance both look meaningfully different here than in a licensed Microsoft 365 product: Foundry usage is billed on consumption, primarily tokens processed by whichever underlying models an application calls, plus any associated Azure services like AI Search or storage. Cost scales directly with usage volume and model choice rather than being a predictable per-seat monthly figure, and a custom application built on an expensive frontier model without cost-conscious model selection, prompt design, or caching can accumulate spend far faster than the equivalent Copilot seat licence would.
Data handling and residency are also a genuinely separate consideration from Copilot: because Foundry applications are custom-built, responsibility for what data gets sent to which model, where that model is hosted, and what content filtering and responsible AI policies are applied sits much more directly with the building organisation's own architecture choices, through Foundry's content safety and governance tooling, rather than being handled implicitly the way Copilot's tenant-boundary data handling is. That makes a clear internal AI governance policy a genuine prerequisite for safe Foundry adoption rather than a nice-to-have.