Foundry project is a project space in Microsoft Foundry that groups the AI assets a team uses to build, evaluate, and operate a specific application or use case. Teams use it to separate team work, access, agents, evaluations, files, model deployments, and operational evidence so AI work does not become an unmanaged shared sandbox. In Azure reviews, it matters when someone must approve access, troubleshoot behavior, estimate cost, or explain why the configuration exists. Treat it as a design choice tied to owners, users, evidence, and rollback.
Microsoft Foundry project, AI Foundry project, Foundry workspace project
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-14
Microsoft Learn
A Foundry project organizes agents, model deployments, evaluations, files, and team access inside a Microsoft Foundry resource for building AI applications.
Technically, Foundry project is understood through Foundry resource project APIs, project resource IDs, Azure RBAC, model deployments, agents, files, evaluations, connections, managed identities, and portal or SDK workflows. Important settings include project name, parent Foundry resource, location, team role assignments, model deployments, connections, diagnostic settings, tags, and environment boundaries. Operators inspect it with project show output, portal project settings, resource ID, team role assignments, deployment inventory, evaluation results, activity logs, and application traces. Validate it against the live subscription and environment.
Why it matters
Foundry project matters because it changes how teams design, approve, troubleshoot, and explain an Azure workload. If the concept is misunderstood, teams may grant the wrong access, hide an unhealthy dependency, overbuild capacity, miss audit evidence, or create a user-facing failure that looks like an application bug. It affects security, reliability, operations, cost, and performance because one setting can influence who reaches the workload, how traffic behaves, what gets logged, how much capacity is consumed, and how quickly support can recover. A strong definition helps architects and operators ask the practical questions before the change reaches production. Always tie the review to one subscription, environment, owner, and measurable business outcome.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
The Foundry portal displays a project with agents, files, evaluations, model deployments, connections, team access, and resource details under one use case during review for production evidence.
Signal 02
CLI or SDK output shows the project name, resource ID, parent Foundry resource, location, provisioning state, and access assignments for operators during review for production evidence.
Signal 03
Change records refer to a Foundry project when approving model deployments, adding team members, connecting data sources, or promoting an agent workflow during review for production evidence.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Design and review Foundry project for a production Azure workload before traffic, data, or model behavior depends on it.
Troubleshoot Foundry project by comparing live configuration, logs, metrics, ownership, and downstream service health.
Document Foundry project in architecture, security, cost, and support runbooks so teams share the same operating language.
Use Foundry project during release planning to confirm prerequisites, access, rollback, monitoring, and customer-impact assumptions.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Foundry project in action for insurance
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Summit Mutual, a insurance organization, needed to solve a concrete production challenge: separate AI prototypes for claims, underwriting, and customer support were mixed in one workspace, making ownership and access reviews painful. Leaders wanted a practical Azure design that support, security, and business owners could understand.
🎯Business/Technical Objectives
Separate use cases
Clarify project ownership
Control team access
Keep evaluation evidence
✅Solution Using Foundry project
The team used Foundry project as the control point for the change. The cloud team created a distinct Foundry project for the claims assistant under the approved Foundry resource. The project contained its model deployments, files, evaluations, agent configuration, and team role assignments. Engineers used CLI project show output and role assignment evidence in the change record. Access reviews mapped each user to a claims business owner, and release gates required evaluation results before agent updates could reach production. Before release, engineers captured read-only evidence, confirmed owners and access, checked diagnostics or local logs, and documented rollback steps. Operations monitored the first production window with metrics that matched the stated objectives, not just generic resource health. The change record linked configuration evidence to measurable outcomes so later audits and incident reviews could reconstruct the decision quickly.
📈Results & Business Impact
Access review time fell 41 percent
Claims assets stopped mixing with other prototypes
Evaluation evidence was retained per release
Incident owners were clear
💡Key Takeaway for Glossary Readers
A Foundry project gives AI teams a practical boundary for ownership, access, and operational evidence.
Case study 02
Foundry project in action for higher education
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
WestRiver University, a higher education organization, needed to solve a concrete production challenge: faculty teams wanted student-facing AI labs but needed a controlled project boundary for experiments, files, and model deployments. Leaders wanted a practical Azure design that support, security, and business owners could understand.
🎯Business/Technical Objectives
Isolate course experiments
Limit student access
Track model deployments
Simplify semester cleanup
✅Solution Using Foundry project
The team used Foundry project as the control point for the change. Administrators created one Foundry project per course cohort under a shared Foundry resource. Each project held approved files, lab agents, model deployments, and evaluation notes. Instructors received project-level access, while students used an application front end rather than direct portal permissions. Operations exported project IDs, role assignments, and deployment lists at semester close, then removed stale assets using a documented cleanup runbook. Before release, engineers captured read-only evidence, confirmed owners and access, checked diagnostics or local logs, and documented rollback steps. Operations monitored the first production window with metrics that matched the stated objectives, not just generic resource health. The change record linked configuration evidence to measurable outcomes so later audits and incident reviews could reconstruct the decision quickly.
📈Results & Business Impact
Semester cleanup took hours not days
Student access stayed constrained
Deployment inventory was visible
Lab outages were easier to triage
💡Key Takeaway for Glossary Readers
Foundry projects make experimentation safer when every course, team, or use case has a defined operating boundary.
Case study 03
Foundry project in action for government technology
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
CivicAssist Digital, a government technology organization, needed to solve a concrete production challenge: a citizen-service chatbot needed agents, evaluations, and files grouped separately from unrelated innovation pilots. Leaders wanted a practical Azure design that support, security, and business owners could understand.
🎯Business/Technical Objectives
Group production assets
Enable controlled team access
Retain evaluation history
Support incident response
✅Solution Using Foundry project
The team used Foundry project as the control point for the change. The delivery team created a Foundry project dedicated to the citizen-service assistant. It linked approved model deployments, uploaded policy files, evaluation runs, and the agent used by the public web app. Change records referenced the project resource ID, owner, diagnostic settings, and rollback path. During incidents, operators could compare project configuration, model deployment state, and application traces without searching unrelated AI experiments. Before release, engineers captured read-only evidence, confirmed owners and access, checked diagnostics or local logs, and documented rollback steps. Operations monitored the first production window with metrics that matched the stated objectives, not just generic resource health. The change record linked configuration evidence to measurable outcomes so later audits and incident reviews could reconstruct the decision quickly.
📈Results & Business Impact
Incident triage time fell 33 percent
Evaluation history matched release versions
Access reviews had a single scope
Unrelated pilots no longer created noise
💡Key Takeaway for Glossary Readers
A Foundry project helps production AI applications stay organized enough for support, audit, and safe change control.
Why use Azure CLI for this?
CLI checks make Foundry project review repeatable because they capture scoped evidence for configuration, ownership, dependencies, health, and change impact before operators modify production.
CLI use cases
List or show the Azure or local resources related to Foundry project before selecting a target for deeper review.
Capture read-only evidence for Foundry project during release approval, incident response, access review, or cost investigation.
Compare configuration, metrics, logs, and dependent resources for Foundry project across environments before approving a mutating command.
Before you run CLI
Confirm tenant, subscription, resource group, profile, endpoint, project, device, or local model scope before trusting command output.
Run list and show commands first, then save evidence before create, update, purge, restart, delete, scale, or access changes.
Check whether the command affects customer traffic, local user devices, cached content, model behavior, cost, or compliance evidence.
What output tells you
Names, resource IDs, locations, SKUs, enabled states, and parent relationships show whether you are inspecting the intended target.
Settings, identities, routes, deployments, endpoints, origins, cache paths, or model metadata explain how requests or workloads behave today.
Timestamps, metrics, usage, health state, and logs help separate Azure configuration issues from application, device, or downstream failures.
Mapped Azure CLI commands
Foundry project operational checks
direct
az cognitiveservices account project list --name <foundry-resource> --resource-group <resource-group>
az cognitiveservices account projectdiscoverAI and Machine Learning
az cognitiveservices account project show --name <foundry-resource> --resource-group <resource-group> --project-name <project-name>
az cognitiveservices account projectdiscoverAI and Machine Learning
az cognitiveservices account projectprovisionAI and Machine Learning
az role assignment list --scope <project-resource-id> --output table
az role assignmentdiscoverAI and Machine Learning
az monitor diagnostic-settings list --resource <project-resource-id>
az monitor diagnostic-settingsdiscoverAI and Machine Learning
Architecture context
Technically, Foundry project is understood through Foundry resource project APIs, project resource IDs, Azure RBAC, model deployments, agents, files, evaluations, connections, managed identities, and portal or SDK workflows. Important settings include project name, parent Foundry resource, location, team role assignments, model deployments, connections, diagnostic settings, tags, and environment boundaries. Operators inspect it with project show output, portal project settings, resource ID, team role assignments, deployment inventory, evaluation results, activity logs, and application traces. Validate it against the live subscription and environment.
Security
Security for Foundry project starts with team membership, project-scoped roles, managed identity permissions, model access, file uploads, connection secrets, and diagnostic visibility. Review who can create it, change it, delete it, read diagnostics, approve connected resources, and use any credentials or identities involved. Prefer managed identity and Microsoft Entra ID where supported, keep secrets out of code, and scope roles to the smallest useful boundary. Capture Activity Log entries, role assignments, network settings, policy exemptions, and owner approvals before production changes. The goal is to prove that access, exposure, and data handling were intentional rather than accidental side effects of a quick deployment.
Cost
Cost for Foundry project is driven by shared Foundry resource usage, model deployments, agent runs, evaluations, storage, diagnostics, duplicate projects, and inactive experiments that remain billable. The expensive mistake is not only Azure consumption; it can also be duplicate experiments, broad changes, support time, overprovisioned capacity, or emergency cleanup after weak design evidence. Review whether the workload truly needs the selected tier, retention, diagnostics, network path, cache behavior, or automation pattern. Use tags, budgets, alerts, and recurring cleanup reviews so teams can explain why the current design exists and remove stale resources without breaking dependencies. Always tie the review to one subscription, environment, owner, and measurable business outcome.
Reliability
Reliability for Foundry project depends on project ownership, deployment lifecycle, agent dependencies, evaluation gates, quota, region choice, connection health, and change isolation between use cases. A resource can appear healthy while the business workflow fails because a route, dependency, identity, cache, quota, or downstream service is wrong. Test common failure modes, disabled states, retries, rollback paths, and maintenance behavior before relying on the design. Keep runbooks for first-response checks, owner escalation, and safe rollback. During incidents, compare platform metrics, deployment history, configuration changes, and application traces from the same time window before changing production settings. Always tie the review to one subscription, environment, owner, and measurable business outcome.
Performance
Performance for Foundry project depends on model region, deployment selection, endpoint latency, project connection paths, evaluation workload, concurrent agent runs, and application-side retry behavior. Measure platform-side metrics and application-side completion metrics because a fast control-plane response does not always mean users received the right result. Test with realistic data sizes, regions, concurrency, authentication paths, route choices, cache state, and downstream limits. When performance regresses, compare configuration changes, resource limits, client logs, diagnostic data, and workload timing before adding capacity or blaming one service. The best tuning decisions come from evidence tied to the exact environment. Always tie the review to one subscription, environment, owner, and measurable business outcome.
Operations
Operations for Foundry project require project inventory, naming standards, access reviews, deployment approvals, evaluation records, incident owners, diagnostic settings, and cleanup of abandoned experiments. Before a change, capture read-only CLI output, portal evidence when useful, owner tags, expected behavior, and a rollback path. During incidents, avoid changing several settings at once; compare metrics, logs, deployment operations, identity evidence, network state, and downstream health first. Keep release notes clear enough for support teams to verify current behavior quickly. Good operational practice turns the term into something observable, reviewable, and recoverable instead of tribal knowledge. Always tie the review to one subscription, environment, owner, and measurable business outcome.
Common mistakes
Treating Foundry project as a simple label instead of checking the live scope, owner, dependencies, and current configuration.
Running a mutating command in the wrong subscription, profile, resource group, project, endpoint, origin group, or local device context.
Assuming a successful command means users saw the correct result without checking logs, metrics, application behavior, and rollback evidence.