> Source: https://wexa.ai/docs/concepts/projects

# Projects

A **project** is the unit of work and the unit of isolation. Of Wexa's three nested boundaries it
is the one that is enforced on every request, so it is worth understanding as more than a label on
a workspace.

## What a project scopes

A project owns, exclusively:

- its four stores — the context graph, the knowledge base, the data catalog and the project
  ontology (which of them you want is the subject of
  [where your data goes](/docs/concepts/where-your-data-goes));
- its agents and process flows, their versions, and every execution of them;
- its connectors and the skills they mint, and its repository connections and the code graph that
  code sync keeps in step with them;
- its own **project mode**, which decides how context is written and how much approval that takes.

None of these are visible from another project. A query cannot traverse out of the project it was
issued in, and an agent defined in one project cannot be run from another.

## Why a credential belongs to one project

A credential is not a key to Wexa; it is a key to one project inside one organization. When a
credential is issued — an API key, or the token minted at the end of the Wexa MCP server's
consent screen — an organization, a department and a project are chosen at that moment and fixed
into it. That trio, together with who the caller is, is the caller's **scope**.

Because the project is in the credential, it is not in the call. The platform fills it in from the
scope, every time, on all four surfaces. That is the single mechanism behind almost every isolation
claim on this page: a call has no way to name a project, so it has no way to name someone else's.

## Why writes are bound to the project too

The same binding applies in the other direction. Nodes and relationships saved through
`save-context` land in the calling project's context graph and nowhere else; the project is pinned
server-side before the write is attempted, not chosen by the payload.

This is what makes the rest of the governance meaningful. A **policy decision** is a ruling about
one project's rules, an **approval** is given by someone who can see that project, and the **audit**
record names the scope the action ran under. If the project on a call could be supplied by the
caller, each of those would be a statement about a project the caller picked — which is to say,
about nothing.

## Choosing how many projects to have

There is no single right answer, but the boundary suggests one. Use a separate project when you
want the isolation: different customers' data, a production context graph and an experimental one,
or two teams whose agents should never read each other's work. Use the same project when the agents
genuinely need to see the same context, because there is no supported way to join across two.

Splitting later is real work — context, knowledge, catalog and vocabulary all belong to the project
they were created in — so it is worth a few minutes of thought before the first write.

## Next

[Project mode](/docs/concepts/project-mode) is the next decision a new project needs, and
[scope and server-bound arguments](/docs/get-started/scope-and-server-bound-arguments) is the
mechanism this page kept referring to, written out in full.