Microsoft Foundry · Azure AI
Add engineering where the requirement demands it.
Use custom AI capabilities when a clear need exceeds the simpler Microsoft or low-code route.
Who should be involved: Technology leaders, engineering teams, platform and product owners
When is custom AI engineering with Microsoft Foundry justified?
Custom AI engineering with Microsoft Foundry is justified when an important requirement cannot be met adequately by simpler options and its value supports the added operating responsibility. That requirement may concern integration, retrieval or application behaviour. Amplified Pi evaluates the complete task, including sources, tools and human review. A stronger model or an impressive prototype is not, by itself, an investment case.
- When this is a good fit
- A valuable use case has an evidenced capability gap, domain reviewers and a platform owner who can support the resulting application.
- Before you invest
- Describe the unmet requirement and compare it with existing or low-code options. Agree quality, support and cost expectations before treating custom development as the default next step.
More engineering only for a concrete requirement.
Which requirement remains unmet by simpler options?
A simpler solution meets the requirement
Stay with existing capabilities or low-code.
A material gap remains
Assess custom development with Microsoft Foundry.
The decision depends on the gap, expected value and a sustainable operating model. Custom development is not an end in itself.
What we work on
- Document the capability gap: for example a specific model, retrieval pattern, integration or evaluation requirement.
- Design identity, network, data and model boundaries; validate a bounded technical approach.
- Build the agreed increment with evaluation, observability, cost controls and an operational handover.
What you take away
- An architecture decision comparing custom and simpler options.
- A bounded implementation with test data, evaluation results and dependency register.
- An operating model covering incidents, model changes, cost and retirement.
How we approach the work
Custom AI should resolve a specific limitation of the simpler route. We make that limitation measurable, then build the smallest useful increment with the evaluation and operating arrangements needed to support it.
-
Prove the capability gap
We compare a representative task against the existing or low-code approach. The gap might concern integration, retrieval, model behaviour or evaluation. We agree what improved result would justify custom development and which requirements remain outside the first increment.
What you receive
An architecture decision and a bounded technical hypothesis.
-
Design the data and action boundary
We identify where data is stored, retrieved and sent, which identities perform each operation and which actions need approval. We review network exposure, permissions, regional options and service dependencies with the platform owner. Unresolved contractual or data-processing assumptions remain explicit.
What you receive
A reviewed architecture and dependency register.
-
Build an evaluation set before optimising
Domain reviewers provide ordinary tasks, difficult cases and unacceptable outcomes. We assess the complete application, including retrieval and tools, rather than choosing a model from a public benchmark alone. Changes are compared against the same baseline, with human review where automated scoring is insufficient.
What you receive
Representative test data and a documented quality decision.
-
Make the service supportable
We define meaningful alerts, ownership of failures, a fallback and a release or rollback procedure. The operating view includes latency, failed tasks, quality samples and cost per useful result. Logs and traces receive a purpose, access rules and retention limits because they can contain sensitive material.
What you receive
An operating runbook and evidence for a controlled release.
The guidance behind the approach
Engineering with explicit controls
Microsoft Foundry brings model and agent development together with identity, access and governance capabilities. The availability of a platform control is a starting point for design, not evidence that a particular application has been secured.
Reference: Microsoft: Foundry overview
Evaluation continues after release
Microsoft’s observability guidance connects evaluation, monitoring and tracing across the AI lifecycle. We use this distinction to separate a release test, an operational alert and an investigation of an individual failed task.
Reference: Microsoft: Foundry observability and evaluation
Illustrative example
Example: answers across several governed sources
A service team needs an answer that combines approved product guidance with a record from another system. We first test whether simpler tools can meet the requirement. If custom retrieval is justified, the experiment tests source relevance, permissions and contradictory information together. A fluent answer that cites the wrong source is a failure.
What we need to get started
- A product owner and domain reviewers
- Approved evaluation examples and integration access
- A platform owner for operation, budget and data-processing decisions
Questions before you begin
Do we need to train our own model?
Not necessarily. We first test whether the issue is task design, source quality, retrieval or integration. A model change or training step should address an evidenced gap and justify its additional cost.
Is a successful prototype ready for production?
A prototype can establish technical feasibility. Production also needs accepted quality, access controls, support, monitoring, recovery and a cost envelope. We make that remaining work visible before a release decision.
Related modules
The decision at the end
The engineering and business owners accept the quality evidence, operational burden and cost envelope.
How progress is judged
Measure relevant task quality, latency, reliability and unit cost against agreed targets.
Scope boundary
Microsoft Foundry is the current product name used here for the Azure AI path. Model, region, feature status and data-processing terms need case-specific confirmation.
Choose the next step from the evidence.
The next module depends on the constraint revealed by the work. You do not need to complete every module.
Explore the other modulesProduct and policy references
- Microsoft Foundry overview
- Microsoft: Foundry overview
- Microsoft: Foundry observability and evaluation
Next step