AI and Machine Learning AI platform

Azure AI Foundry project

An Azure AI Foundry project is the working area where a team builds and organizes an AI application inside Microsoft Foundry. It keeps related agents, evaluations, files, indexes, tools, connections, and model usage together instead of scattering them across a shared portal. Think of it as the project boundary for one AI product, prototype, or team. It is useful because AI work quickly becomes messy: prompts, test data, model deployments, safety checks, and access decisions all need a home with ownership and repeatable operations.

Source: Microsoft Learn - Create a project - Microsoft Foundry Reviewed 2026-06-02T07:49:29Z

Exam trap: Putting production agents and throwaway prompt experiments in the same project, then losing track of which files influenced behavior.
Production check: List projects under the Foundry resource and confirm the target project name matches the product or lifecycle standard.

Practice this topic Microsoft Learn

Article details and learning context

Aliases: AI Foundry project, AI project, Foundry project, Microsoft Foundry project
Difficulty: advanced
CLI mappings: 4
Last verified: 2026-06-02T07:49:29Z
Review level: template-spec-upgraded
Article depth: field-manual-template-specs

Learning paths Learn AI Foundry and Model Operations Azure AI Foundry project

Related context Learning path: AI Foundry and Model Operations

Compare related concepts Search related resources Browse the glossary

Understand the concept

Why it matters

An Azure AI Foundry project matters because AI delivery fails when prototypes, test files, production agents, and evaluation results all live in one undifferentiated workspace. Projects give teams a cleaner boundary for ownership, access, asset cleanup, and release review. They also help separate experimental prompts from production assistants, control who can manage connections, and make evaluation evidence easier to find. For regulated or customer-facing AI, this boundary supports governance: teams can show which project owns a model integration, which files were used, which evaluation ran, and who had access. Without that structure, AI sprawl becomes security, cost, and reliability debt.

Official wording and source

An Azure AI Foundry project is a scoped workspace inside Microsoft Foundry for organizing AI application work such as agents, evaluations, files, connections, and model integrations. Microsoft Learn describes projects as the place teams work after creating or selecting the Foundry resource.

Open Microsoft Learn

Technical context

The project sits in the AI application platform layer under a Foundry resource or hub-style organization, depending on the environment. It connects model deployments, agents, data files, evaluations, tools, connections, and role assignments used by builders. It is not just a folder; it is the scope where teams manage AI assets, collaborate, and apply access boundaries for a specific application effort. Architects map projects to product teams, lifecycle stages, data sensitivity, and deployment paths so experiments, evaluations, and production agents do not blend together.

Exam context

AI-102 Microsoft Certified: Azure AI Engineer Associate AI-103 Microsoft Certified: Azure AI Apps and Agents Developer Associate

Compare with

Azure AI Foundry hub Azure AI services Foundry resource

Where it is used

Where you see it

In the Foundry portal, projects appear in the project selector with agents, files, evaluations, connections, tools, and model-related work scoped to that workspace boundary today.
In Azure CLI output, project names and resource IDs appear under cognitiveservices account project commands used for inventory, creation, review, and access automation during reviews.
In governance reviews, the project appears beside role assignments, connected data sources, model deployment usage, evaluation results, safety settings, ownership notes, cleanup decisions, and evidence.

Common situations

Separate production AI assistant assets from prototype prompts, temporary files, and experimental evaluations.
Assign a product team access to one AI project without granting broad control over every Foundry resource.
Organize agents, files, tool connections, and evaluations for a single business application before release review.
Create repeatable project scopes through CLI or automation so new AI teams start with consistent governance.
Inventory abandoned AI experiments and delete only project assets that have no production owner or dependency.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Legal research assistant separated from prototype chaos Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A legal technology firm built several research assistants in one shared Foundry workspace. Attorneys could not tell which files and evaluations belonged to the production contract-review agent.

Goals

Separate production and prototype AI assets.
Restrict confidential client files to approved builders.
Preserve evaluation evidence for customer audits.
Reduce time spent tracing agent configuration.

Approach using Azure AI Foundry project

The platform team created a dedicated Foundry project for the production contract-review assistant and separate projects for experimentation. Production files, agent instructions, evaluation datasets, and approved tool connections were moved into the production project. Azure CLI listed the projects and captured resource IDs for role assignments, while security granted builder access only to the legal AI owner group. The team documented model deployments, connected search indexes, and evaluation runs in the release checklist. Prototype projects received cleanup tags and shorter retention rules. During audits, reviewers could open one project and see the specific assets supporting the shipped assistant.

Potential outcomes

Configuration trace time fell from roughly three hours to 28 minutes per release review.
Unauthorized prototype users lost access to production client files.
Audit evidence packages were produced in under one hour instead of two days.
Seven abandoned prototype projects were retired, reducing evaluation and storage clutter.

What to learn

A Foundry project gives AI work a defensible boundary when prompts, files, evaluations, and tool access must be reviewed together.

Scenario 02 Energy maintenance agent governed by field region Scenario, objectives, solution, measured impact, and takeaway.

Scenario

An energy utility piloted maintenance agents for wind farms in three regions. Shared project access let contractors view files from regions they did not support.

Goals

Create region-specific AI workspaces for field teams.
Keep contractor access limited to assigned assets.
Track model and tool dependencies for each agent.
Shorten incident triage for bad maintenance recommendations.

Approach using Azure AI Foundry project

Architects created one Foundry project per operating region under the approved Foundry resource. Each project held region-specific equipment manuals, inspection files, agent definitions, and evaluation sets. Azure CLI was used to list projects, confirm project resource IDs, and assign contractor groups at project scope rather than parent scope. Connections to storage and search were reviewed so each agent reached only its regional grounding data. Operations dashboards linked incidents to the project name, agent, evaluation version, and connected data source. When one agent returned an outdated turbine procedure, the team found the stale file in the correct region project instead of searching the whole estate.

Potential outcomes

Cross-region file exposure findings dropped to zero after project-scoped access.
Maintenance recommendation triage time fell from 95 minutes to 24 minutes.
Each regional agent had a documented model deployment and grounding source.
Contractor onboarding became repeatable with one CLI-based access checklist.

What to learn

Project scope is practical governance: it limits who can touch the AI assets that shape answers in a specific operational domain.

Scenario 03 Media studio cleaned up generative AI pilots Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A media studio allowed creative teams to test AI assistants for script analysis, dubbing, and metadata tagging. After six months, nobody knew which projects still mattered or who owned the costs.

Goals

Inventory all AI projects under the shared Foundry resource.
Separate active production candidates from expired experiments.
Assign owners and cleanup dates to every remaining project.
Reduce unused evaluation and file storage spend.

Approach using Azure AI Foundry project

The cloud operations team used Azure CLI to list Foundry projects and export names, resource IDs, owners, and role assignments. They interviewed creative leads, then classified projects as production candidate, active experiment, or retire. The script-generated inventory was matched with model usage, evaluation runs, and uploaded file age. Active projects received owner groups, tags, and documented connected resources. Expired projects were backed up only where policy required and then removed after dependency checks. New project creation moved into an intake process that required purpose, data classification, expected model deployments, and retirement date.

Potential outcomes

Twenty-one inactive projects were retired without affecting active pilots.
Monthly AI experimentation spend fell 18% after duplicate evaluations and files were removed.
Every remaining project had an owner group and documented review date.
Creative teams received new projects in one business day through the standard intake flow.

What to learn

A Foundry project becomes a manageable unit for AI portfolio hygiene when every experiment needs an owner, purpose, and exit path.

Azure CLI

With ten years of Azure engineering experience, I use Azure CLI for Foundry projects when repeatability matters more than portal convenience. Portal creation is fine for exploration, but CLI gives platform teams a way to list projects, create consistent project scopes, capture resource IDs, assign roles, and validate that environments match naming and access standards. It also helps during reviews: a security engineer can see which projects exist under a Foundry resource and which scopes received role assignments. For production AI, that evidence matters because a missing project, wrong region, or broad role assignment can delay release or expose sensitive files. CLI also fits deployment pipelines and cleanup automation.

Useful for

List projects under a Foundry resource during ownership, cleanup, or access review.
Create a project with a standard name, region, and parent resource during platform onboarding.
Show project properties and resource IDs before assigning Azure AI User or contributor roles.
Export project inventory evidence for governance boards reviewing production AI applications.

Before you run a command

Confirm the target subscription, resource group, Foundry resource name, region, and project naming standard before creating anything.
Verify the Azure CLI extension or command group version because Foundry project commands can evolve as the platform changes.
Check role-assignment authority; granting broad access at the parent resource can expose more projects than intended.

What the output tells you

Project name, ID, location, and parent resource identify the scope where agents, files, evaluations, and connections should be governed.
Role assignment output shows whether access was granted to the project scope or accidentally inherited from a broader parent.
Project lists reveal abandoned prototypes, duplicate workspaces, or production projects missing expected naming and ownership patterns.

Mapped commands

Operational CLI checks

direct

az cognitiveservices account project create --name <foundry-resource> --resource-group <resource-group> --project-name <project-name> --location <region>

az cognitiveservices account projectprovisionAI 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 project list --name <foundry-resource> --resource-group <resource-group>

az cognitiveservices account projectdiscoverAI and Machine Learning

az role assignment create --role "Azure AI User" --assignee <user-or-group> --scope <project-resource-id>

az role assignmentsecureAI and Machine Learning

Architecture context

Architecturally, I map a Foundry project to a product boundary, not a random experiment folder. One project might own a claims assistant, another a developer support agent, and another an evaluation lab. The project should align with data classification, user group, model deployment access, monitoring, and release path. Connections to storage, search, or other tools need clear ownership because they decide what the AI application can reach. Production projects should avoid sharing unmanaged test files or broad access with prototypes. In larger estates, projects become the unit that architects inventory during AI governance reviews, quota planning, safety evaluation, and decommissioning.

Security: Security impact is direct because projects collect AI assets, files, connections, agents, and evaluations that may expose sensitive data or powerful tools. Role assignments should be scoped carefully so builders can work without granting broad control over the parent Foundry resource. Connections to storage, search, model deployments, or external tools must be reviewed for data exposure. Do not mix public demo files with confidential production grounding data. Use managed identities where appropriate, restrict project access to owner groups, monitor changes, and keep evaluation artifacts protected. A project boundary is not a substitute for data classification or prompt safety, but it gives governance a practical place to enforce them.
Cost: Cost impact is indirect but real. A project can accumulate model calls, uploaded files, vector indexes, evaluation runs, agent experiments, and connected resources that continue consuming quota or storage. Without project ownership, teams struggle to separate valuable production assets from forgotten prototypes. Projects also help FinOps allocate AI spend by product team or initiative when tags and resource scopes are used consistently. Cost reviews should inspect model deployment usage, evaluation frequency, file storage, connected search indexes, and idle agents. A clean project boundary makes it easier to retire experiments, prevent duplicated grounding stores, and avoid broad shared resources that hide which team created the bill.
Reliability: Reliability impact comes from keeping AI assets organized enough to reproduce, evaluate, and recover an application. If agents, files, prompts, and evaluations are scattered across projects, teams cannot quickly identify what changed before a bad answer, failed deployment, or tool outage. Reliable projects keep production assets separate from experiments, document dependent model deployments and connections, and preserve evaluation runs used for release decisions. Operators need to know whether a failure comes from project access, missing files, a changed connection, model quota, or agent configuration. Project-level ownership also makes cleanup safer because retired prototypes can be removed without deleting production evidence.
Performance: Runtime performance is mostly indirect, but project organization affects how quickly teams diagnose AI application behavior. A well-scoped project keeps relevant files, agents, evaluations, and connections close together, reducing time spent hunting for the configuration behind a slow or inaccurate assistant. Performance can also be affected by connected model deployments, search indexes, grounding stores, and tool endpoints selected inside the project. If a prototype uses a different region or deployment than production, latency and quota results can mislead reviewers. Operators should compare project assets with the production architecture, test evaluation latency, and monitor tool calls rather than assuming the project name guarantees performance.
Operations: Operators use Foundry projects to inventory AI work, assign access, review files and agents, validate connections, run evaluations, and clean up abandoned prototypes. Common tasks include listing projects under a Foundry resource, confirming owners, checking role assignments, reviewing connected resources, and documenting which project backs a production application. During incidents, operators inspect the project for recently changed agents, missing files, failed evaluations, or connection problems before blaming the model. Good runbooks name the project, parent resource, region, owner group, model deployments, data sources, monitoring path, and rollback project or previous configuration snapshot. Record owner, environment, and retirement date so cleanup decisions do not depend on memory.

Common mistakes

Putting production agents and throwaway prompt experiments in the same project, then losing track of which files influenced behavior.
Granting users broad parent-resource permissions when they only need builder access to one project.
Creating projects manually with inconsistent names, regions, or owner notes that later break inventory and chargeback.
Deleting a project without checking whether evaluations, files, or connections are still referenced by a release process.