Projects and applications
A project stands for one agent system you work on. It belongs to a workspace and is visible to every member of that workspace. It holds the project’s context (its repository or uploaded files), its plans, its scenario cases, its traces and its runs.
You meet projects in two forms:
| Form | What it is | Where you see it |
|---|---|---|
| A session’s project | Every session has its own project. Its repository and branch are the session’s. | The session and its work panel |
| An application | A project no session owns: a name and, optionally, a GitHub repository. Tracing, Monitoring, Evaluations, Lessons and Code search work per application, without opening a chat. | Build in the sidebar. See Tracing. |
A coding tool connected over MCP can create a project with project_create. When it proposes a plan or the commands that check the repository, WeHarness opens a session where you follow and approve them. See MCP overview.
What a project records
Section titled “What a project records”| Field | Limits | Purpose |
|---|---|---|
| Name | 1–80 characters | How the project appears in lists and in MCP results |
| Intent | Up to 4,000 characters | What the agent should accomplish and the rules it must follow, in plain language |
Write the intent as you would brief a colleague. Name the users, the outcome, and the limits that matter:
Answer customers’ order questions from the order system. Offer a refund only for orders under 30 days old, and only after a support lead approves it. Never change an address.
Repositories and projects
Section titled “Repositories and projects”- Several applications, and several sessions, can work on one repository.
- Scenario cases and lessons belong to the repository, so every session and application on it shares them.
- An application reads the traces of its own ingest keys, and of the sessions an owner or admin linked to it. A matching repository never links traces by itself.
Deleting a session deletes its project; see Deleting a project.