Workspace Isolation

AutoResearch supports running multiple research projects simultaneously. Each project lives in its own directory with its own state, agents, and monitoring — completely isolated from other projects.

Per-Project Directory Structure

~/research/
├── project-alpha/
│   ├── .omc/research/          # Project Alpha state
│   ├── src/                    # Project Alpha code
│   ├── data/                   # Project Alpha data
│   └── infrastructure.yaml     # Project Alpha resources
├── project-beta/
│   ├── .omc/research/          # Project Beta state
│   ├── src/                    # Project Beta code
│   ├── data/                   # Project Beta data
│   └── infrastructure.yaml     # Project Beta resources
└── shared/
    ├── datasets/               # Shared datasets (symlinked)
    └── pretrained/             # Shared pretrained models

Each project is fully self-contained

The .omc/research/ directory contains everything the system needs to operate on a project. You can zip a project directory, move it to another machine, and resume work.

infrastructure.yaml

Each project declares its compute resources in infrastructure.yaml. This tells the Orchestrator what's available and prevents resource conflicts between projects.

# project-alpha/infrastructure.yaml
project: alpha
gpu:
  count: 4
  type: A100
  memory_gb: 80
  ids: [0, 1, 2, 3]          # CUDA_VISIBLE_DEVICES

storage:
  data_dir: ./data
  checkpoint_dir: ./checkpoints
  shared_data: ~/research/shared/datasets  # Symlink target

compute:
  max_concurrent_experiments: 2
  max_training_hours: 48
  priority: normal              # normal | high | low

tmux:
  session_prefix: alpha         # alpha-coder, alpha-scout
  
monitoring:
  phase1_active: true
  phase2_cron: true
  patrol_interval: 30           # minutes

GPU ID conflicts

If you run two projects on the same machine, ensure their gpu.ids don't overlap. The Orchestrator respects CUDA_VISIBLE_DEVICES but doesn't coordinate across projects.

Cross-Project Shared Resources

Some resources are shared across projects to save disk space and download time.

What Can Be Shared

Resource	How	Managed By
Pretrained model weights	Symlink to shared directory	User
Common datasets (ImageNet, etc.)	Symlink to shared directory	User
BibTeX databases	Symlink or copy	Scout
Conda environments	Named envs, one per project	Coder

What Must NOT Be Shared

Resource	Why
.omc/research/ state	Project-specific state must stay isolated
Training checkpoints	Different model architectures
Experiment logs	Must stay with their experiment
Paper drafts	Different papers, different venues

Symlinks for data

Use symlinks to point project-local data/ to shared datasets:

ln -s ~/research/shared/datasets/imagenet ./data/imagenet

This keeps the project directory self-contained (the symlink is part of the project) while avoiding data duplication.

Parallel Work with Multiple Tmux Sessions

Each project gets its own set of named tmux sessions, prefixed by the project name.

# Project Alpha sessions
alpha-orchestrator     # Main Claude Code session
alpha-coder            # Codex persistent session
alpha-scout            # Gemini worker

# Project Beta sessions
beta-orchestrator      # Main Claude Code session
beta-coder             # Codex persistent session
beta-scout             # Gemini worker

Listing All Sessions

tmux list-sessions
# alpha-orchestrator: 1 windows (created ...)
# alpha-coder: 1 windows (created ...)
# alpha-scout: 1 windows (created ...)
# beta-orchestrator: 1 windows (created ...)
# beta-coder: 1 windows (created ...)

Switching Between Projects

# Attach to Project Alpha orchestrator
tmux attach -t alpha-orchestrator

# Detach (Ctrl-b d), then attach to Project Beta
tmux attach -t beta-orchestrator

Session naming convention

The OMCC harness uses the tmux.session_prefix from infrastructure.yaml to name sessions. All agent sessions for a project share the same prefix, making them easy to identify and manage.

Resource Monitoring Across Projects

# Quick GPU usage check across all projects
nvidia-smi

# Check which tmux sessions are active
tmux list-sessions | grep -E "(alpha|beta)"

# Check project status individually
cd ~/research/project-alpha && cat .omc/research/pipeline.yaml
cd ~/research/project-beta && cat .omc/research/pipeline.yaml

Workspace Lifecycle

graph TD
    A["/research init 'topic'"] --> B[Create .omc/research/]
    B --> C[Create infrastructure.yaml]
    C --> D[Start tmux sessions]
    D --> E[Research in Progress]
    E --> F{Project Complete?}
    F -->|No| E
    F -->|Yes| G[Archive or Delete]
    G --> H[Kill tmux sessions]
    H --> I[Free GPU allocation]

    style A fill:#dbeafe,stroke:#2563eb
    style E fill:#fef3c7,stroke:#d97706
    style G fill:#dcfce7,stroke:#16a34a

Archiving a completed project

When a project is done, you can archive it:

cd ~/research
tar czf project-alpha-archive.tar.gz project-alpha/
# Optionally remove the working directory
rm -rf project-alpha/

The archive contains everything — state, code, data symlinks, paper drafts — needed to understand or reproduce the work later.

Next

• Research State — what's inside .omc/research/
• Monitoring — per-project monitoring configuration
• Quick Start — setting up your first project