To OpenAI Team,
Problem
Projects work well for isolated efforts, but become difficult to manage when users have many related initiatives.
Examples:
Project Group A
- Project 1
- Project 2
- Project 3
Project Group B
- Project 4
- Project 5
Project Group C
- Project 6
- Project 7
Currently, each Project is independent, requiring duplication of instructions, uploaded files, and context.
Proposal 1 – Hierarchical Projects
Allow Projects to contain subprojects.
Example:
Project Group A
├── Project 1
├── Project 2
├── Project 3
└── Project 4
Context inheritance
Each project may contain:
- Instructions
- Uploaded files
- Memories (optional)
Subprojects inherit resources from their parent.
Default behavior:
Child → Parent visibility: Allowed
Parent → Child visibility: Not allowed
Sibling → Sibling visibility: Not allowed
Optional permissions:
☐ Can access parent context
☐ Can access sibling projects
☐ Can expose context to parent
☐ Can expose context to siblings
Example
Parent Project
Instructions:
“General instructions applicable to all related projects.”
Files:
SharedDocument1.pdf
SharedDocument2.pdf
Subproject: Project 1
Additional instructions:
“Instructions specific to this subproject.”
Files:
ProjectSpecificDocument.pdf
Project 1 automatically sees the parent project’s context, while Project 2 cannot access Project 1 unless explicitly permitted.
Benefits
- Eliminates duplication of instructions and uploaded files
- Improves organization for users with many long-running initiatives
- Reduces context maintenance effort
- Makes Projects more useful as a lightweight knowledge management system
- Supports researchers, consultants, founders, students, nonprofits, and software teams
Even a simple two-level grouping system would significantly improve usability.
Possible Alternative
If hierarchical projects are considered too complex, another approach could be introducing reusable resources:
- Shared Knowledge Packs (files attachable to multiple projects)
- Shared Instruction Sets (instruction templates reusable across projects)
- Project Groups for organization only
Proposal 2 – Project Groups (simpler implementation)
If hierarchical projects are too complex, introduce a lightweight grouping mechanism.
Examples
Project Group A
- Project 1
- Project 2
- Project 3
Project Group B
- Project 4
- Project 5
Characteristics:
- Organizational only
- No data sharing
- No inheritance
- Unlimited nesting not required
- Two levels are sufficient
This combination would provide most of the benefits while requiring less implementation complexity.