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);
• 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 is the next decision a new project needs, and scope and server-bound arguments is the mechanism this page kept referring to, written out in full.