Project Management

What You Can Do

• Create projects
• Edit project info (name, description, mode)
• Delete projects
• Filter projects by keyword
• View project status and role
• Enter project workspace
• Manage project members (manager or owner)
• Manage skills installed into the project
• Manage globally enabled skills in the project
• Manage agents, actions, and runtimes installed into the project
• Manage globally enabled agents in the project
• Control Agent auto-execution behavior
• Manage project environment variables (manager or owner can edit)
• Control project-level retrieval memory toggle
• Delete all conversations in a project
• Publish to Showcase (admin-controlled public demo)

Recommended Flow

1. Create project name/domain/description in Workspace
2. Filter to locate the target project quickly
3. Click Enter Project to start working

Project Operations

Edit Project

From the project list or project workspace header, you can modify:

• Project name
• Project description
• Project mode (standard / dev)

Project Mode

Projects support two modes:

• Standard mode: For regular research work
• Dev mode: For developing custom agents

Dev mode features:

• The built-in agent-authoring and visualizer-authoring skills are auto-enabled from the global read-only skill mount under /global/skills/
• Supports online creation and modification of Agents, Actions, and Runtimes
• Switching back to standard mode removes access to those managed skills

Notes:

• agent-authoring and visualizer-authoring are system-managed skills that cannot be manually installed or deleted
• Mode toggle is available in project settings

Agent Auto-Run Toggle

Project-level Agent Auto-Run controls how Agent tools behave in chat:

• Enabled (default): When the model decides to call an Agent, it executes immediately
• Disabled: After the model proposes an Agent call, a confirmation UI appears; the user must fill in parameters and confirm execution

Use cases:

• Disable for scenarios requiring precise control over Agent execution
• Enable for more automated workflows

Settings location: Settings panel in the project workspace header

Project Memory

Each project can have persistent memory stored in .agent/memory.md within the project workspace, with related notes in .agent/memory/. This memory is automatically appended to the system prompt for all conversations in that project.

Features:

• Content is automatically injected into the system prompt for each conversation
• Supports defining durable project context, preferences, terminology standards, decisions, and known gotchas
• Managers and owners can edit; viewers and editors can only view

How to use:

1. In the project list, click the menu button (three-dot icon) on the project row
2. Select Project settings
3. Edit the project memory in the dialog
4. Click Save memory to save

Example content:

# Project Memory

## Overview
- This project studies cancer biomarkers and internal research workflows.

## Durable Facts
- Prefer concise bullet-point answers.
- Mention file paths when referencing files.

## Active Decisions
- Use standard terminology from this project's domain.

## Recent Important Index
- [Container rules](.agent/memory/container-rules.md) - persistent containers must not run as root.

Notes:

• Project memory is stored in .agent/memory.md in the project workspace
• New projects start with project memory off; turning it on creates .agent/memory.md from the default template if the file is missing
• Supporting notes can live under .agent/memory/
• You can edit these files directly through file management or via the Project settings UI
• Clearing the content disables memory injection into the system prompt

Project-Level Retrieval Memory Toggle

When the admin has globally enabled retrieval memory, each project can independently control whether it is active:

• Toggle the Project Memory switch in the project settings
• Defaults to disabled for new projects
• When disabled, both memory search and writes are paused for that project
• See Retrieval Memory for full details

Project Environment Variables

Each project can configure dedicated environment variables stored in the .agent/.env file within the project workspace. These variables are automatically injected into Agent Bash execution and process-based Actions.

Features:

• Environment variables are automatically available in Bash command execution within project chats
• Process-based Actions also carry these environment variables during execution
• Supports configuring API keys, dataset IDs, and other sensitive or project-specific settings
• Managers and owners can edit; viewers and editors can only view

How to use:

1. In the project list, click the menu button (three-dot icon) on the project row
2. Select Project settings
3. Add or edit variables in the environment variables section (one KEY=value per row)
4. Click Save environment to save

Typical use cases:

• Configure third-party service API keys (e.g., OPENAI_API_KEY)
• Set dataset identifiers (e.g., DATASET_ID=atlas-01)
• Store project-specific configuration parameters

Notes:

• Environment variables are stored in .agent/.env in the project workspace
• You can edit this file directly through file management or via the Project settings UI
• Variable names must be unique; empty values are allowed
• Project environment variables take precedence over system environment variables, but are overridden by Action runtime-specified variables

Persistent Container Environment

Project settings also provide a persistent container environment for the project. When enabled:

• All conversations in the project share the same container environment
• Agent Read / Bash / Edit / Write operations prefer to run inside that container
• Installed Python / pip / npm dependencies can be reused in later conversations in the same project
• Files in the local working directory persist with the container

How to enable:

1. Open the target project workspace
2. Click Settings in the top bar
3. In the Persistent data environment card, click Enable
4. Confirm in the dialog

Notes:

• Only owner can enable or disable the container
• manager, editor, and viewer can see the container status
• When container support is enabled, manager can start or stop the project container from the settings page

For full details on image selection, resource settings, permission boundaries, and project image builds, see Container Management.

Showcase (Public Demo)

ResearchX supports publishing projects for public viewing by unauthenticated visitors, useful for case demos, research showcases, or onboarding examples.

How to enable:

1. Admin navigates to /workspace/admin/projects
2. Find the target project in the list
3. Toggle Showcase via the showcase column or action menu
4. Once enabled, visitors can see the project at /showcase and browse its public content

What visitors can see:

• Project name, description, icon, and publication date
• Published conversation lists and message content (including Agent task cards and tool results)
• Public workspace file lists and online preview (including visualizer plugin rendering)
• Workspace file tree (.agent/ directory is automatically hidden)

Limitations:

• This toggle is currently admin-controlled and not in the regular project settings panel
• Showcase pages are read-only — visitors cannot edit messages, modify files, or enter the project workspace
• Disabling removes the project from the /showcase listing

Delete Project

Deleting a project also removes:

• All conversations under the project
• All local workspace files
• Project member associations

This action is irreversible. Proceed with caution.

Bulk Delete Conversations

In the conversation sidebar within a project workspace:

• Click the delete button at the top to clear all conversations
• Useful when you want to start fresh or clean up history

Member Management

• Invite members by email
• Change member role (viewer / editor / manager / owner)
• Remove members

Notes:

• The member management entry is Member in the project workspace header
• manager and owner can add, update, and remove non-owner members
• Only owner can grant or revoke the owner role
• At least one owner must remain on the project

Skills Management

• The project workspace header provides a Skills button
• Clicking it opens a management modal instead of using the right-side file tree
• The left side is grouped by Installed and by skill repository
• The right side shows skills for the selected group and supports search filtering

Typical flow:

1. Switch to a repository on the left
2. Search for the target skill
3. Click Install to install it into the current project
4. Switch to Installed to review project-installed skills
5. Remove installed skills directly from the same modal when needed

Notes:

• Installed skills are copied into .agent/skills/<namespace>/<skill-name> in the project workspace
• Existing legacy installs under .agent/skills/<skill-name> remain compatible
• The right-side Local Workspace tree hides .agent by default to keep regular file work cleaner
• /skill:<name> continues to work for invoking project skills

Agent / Action / Runtime Assets

• Projects can install agent, action, and runtime assets
• Installed assets are copied into .agent/agents, .agent/actions, and .agent/runtimes inside the project workspace
• Asset directories support both root-level and namespaced layouts, for example .agent/actions/<action-name> and .agent/actions/<namespace>/<action-name>
• Chat-based agent execution only considers agents installed in the current project

Current meaning:

• agent
  • user-facing task semantics such as "addition analysis" or "uppercase file"
• action
  • the executable unit used by agent steps, such as add_numbers or uppercase_project_file
• runtime
  • the reusable runtime definition referenced by process actions, mainly for protocol, timeout, environment, and resource defaults

Additional notes:

• The same runtime can be reused by multiple actions
• Project-local runtimes under .agent/runtimes override global runtimes with the same name
• If multiple installed actions or agents declare the same name, the conflict is shown in diagnostics and that name is not exposed for execution until only one definition uses it
• For container actions, image, workdir, command, and args should be configured on the action itself, not treated as runtime-owned business config
• Exporting installed actions or agents includes referenced project-local runtimes. Global-only runtimes remain global dependencies and are resolved from the target environment's global catalog.
• If an agent is missing required actions or runtimes, it is not exposed to the chat model as an available agent tool