Motivation
Eigent currently uses project_id as the main runtime boundary, but Project is also carrying folder binding, chat/session state, queued work, history grouping, generated files, and runtime metadata. This makes Project too overloaded.
We want to support a clearer model where one folder-backed context can contain multiple independent projects and runs. To do that, we need a new layer above Project.
Solution
Introduce Space as a new layer above Project.
A Space represents the folder-backed working context. It owns the selected source folder, shared file index, and future Space-level memory/instructions. A Project becomes an execution/session container inside a Space, with its own mode, chats, queued runs, history, and runtime state.
The target relationship is:
User
-> Space
source folder / shared context
-> Project
single-agent or workforce execution
-> Run
long-running task execution
The first implementation should focus on the model boundary, migration path, and compatibility with existing projects.
Alternatives
One alternative is to keep folder binding directly on Project. This is simpler short-term, but it makes it hard to support multiple projects inside the same folder-backed context.
Another alternative is to rename or expand the existing Workspace concept. This is risky because Workspace is already used in the codebase for lower-level runtime and UI concepts, such as physical working directory, workspace APIs, and active workspace state.
A third alternative is to only add more metadata to Project. That would avoid a larger migration, but it would keep the same overloaded model and make future concurrency, memory, and apply/discard flows harder to reason about.
Additional context
Related ideas from the design:
- Space owns folder binding.
- Project belongs to a Space.
- Project mode should become immutable after the first run.
run_id should become the clearer execution identifier, while task_id remains a compatibility alias during migration.
- Existing projects should migrate into a Legacy Space when needed.
- Folder-bound legacy projects should preserve their existing root path.
- Projects without a folder can become artifact-only projects.
Motivation
Eigent currently uses
project_idas the main runtime boundary, but Project is also carrying folder binding, chat/session state, queued work, history grouping, generated files, and runtime metadata. This makes Project too overloaded.We want to support a clearer model where one folder-backed context can contain multiple independent projects and runs. To do that, we need a new layer above Project.
Solution
Introduce
Spaceas a new layer aboveProject.A Space represents the folder-backed working context. It owns the selected source folder, shared file index, and future Space-level memory/instructions. A Project becomes an execution/session container inside a Space, with its own mode, chats, queued runs, history, and runtime state.
The target relationship is:
The first implementation should focus on the model boundary, migration path, and compatibility with existing projects.
Alternatives
One alternative is to keep folder binding directly on Project. This is simpler short-term, but it makes it hard to support multiple projects inside the same folder-backed context.
Another alternative is to rename or expand the existing Workspace concept. This is risky because Workspace is already used in the codebase for lower-level runtime and UI concepts, such as physical working directory, workspace APIs, and active workspace state.
A third alternative is to only add more metadata to Project. That would avoid a larger migration, but it would keep the same overloaded model and make future concurrency, memory, and apply/discard flows harder to reason about.
Additional context
Related ideas from the design:
run_idshould become the clearer execution identifier, whiletask_idremains a compatibility alias during migration.