# Project

A Project is the primary container for your agents in WSO2 Agent Manager. You create agents inside a project, and a project is where a **[Deployment Pipeline](/agent-manager/docs/v1.0.0/concepts/deployment-pipeline/.md)** is attached to govern how those agents promote across environments.

## Built on OpenChoreo's Project Abstraction[​](#built-on-openchoreos-project-abstraction "Direct link to Built on OpenChoreo's Project Abstraction")

An Agent Manager Project is an [OpenChoreo Project](https://openchoreo.dev/docs/concepts/developer-abstractions/#project). A project groups everything that makes up one application or business capability. So you'd put the agents that work together in the same project, rather than putting every agent in your organization into one.

The grouping is more than a label. Each project's workloads run in their own Kubernetes namespace, provisioned for each project and environment pair, so agents in different projects do not share a runtime namespace.

That separation is a runtime one rather than an access-control one. Permissions are granted organization-wide and not per project, so a role that can read or create agents in one project carries the same permission across every project in the organization. See [Authorization](/agent-manager/docs/v1.0.0/reference/authorization/.md) for the scopes that are actually evaluated. Use projects to organize related agents and to govern how they promote through environments, rather than to control which users can reach which agents.

### How Agents Map to OpenChoreo Components[​](#how-agents-map-to-openchoreo-components "Direct link to How Agents Map to OpenChoreo Components")

OpenChoreo itself does not have a native concept of an "agent." In OpenChoreo's domain model, the fundamental deployable unit is a [Component](https://openchoreo.dev/docs/concepts/developer-abstractions/#component) which is a software workload that can be built, provisioned, and executed.

Because of this model, whether an agent becomes an OpenChoreo Component at all depends on where it runs.

When you create a [Platform-Hosted Agent](/agent-manager/docs/v1.0.0/concepts/internal-and-external-agent/.md), it initially exists only as a record inside the Agent Manager database. It is transformed into an OpenChoreo Component (specifically of type `agent-api`) inside the project's namespace only when you trigger its first build and deployment.

Since Agent Manager neither builds nor deploys the workload of an [Externally-Hosted Agent](/agent-manager/docs/v1.0.0/concepts/internal-and-external-agent/.md), it never becomes an OpenChoreo Component. Registering an external agent creates only an Agent Manager record for governance, tracking, and observability.

## What a Project Holds[​](#what-a-project-holds "Direct link to What a Project Holds")

* Every **agent** you create or register belongs to one project.
* A project is bound to exactly one **[Deployment Pipeline](/agent-manager/docs/v1.0.0/concepts/deployment-pipeline/.md)**, which determines which environments agents in this project can promote through, and in what order.

## Relationship to Organization[​](#relationship-to-organization "Direct link to Relationship to Organization")

A Project belongs to exactly one **[Organization](/agent-manager/docs/v1.0.0/concepts/organization/.md)**. Resources shared across every project in an organization (**[LLM Service Providers](/agent-manager/docs/v1.0.0/concepts/llm-service-provider/.md)**, **[MCP Proxies](/agent-manager/docs/v1.0.0/concepts/mcp-proxy/.md)**, **[Gateways](/agent-manager/docs/v1.0.0/concepts/gateway/.md)**) are registered at the organization level, not the project level, so any project in that organization can reference them.