Nested Sub-Projects with Inherited Context

Feature Request: Nested Sub-Projects with Inherited Context

I would like to suggest adding Sub-Projects inside ChatGPT Projects, with the ability for Sub-Projects to inherit context, files, instructions, and knowledge from their parent Project.

Current Problem

Projects are extremely useful for long-running areas of work because they allow related conversations, files, instructions, and context to stay together.

However, as a Project grows, organization becomes difficult.

For example, a user might have a Project called:

Home / DIY

Over time, that Project may contain conversations about:

- Plumbing

- Electrical work

- Bathroom renovation

- Roofing

- Tools

- Appliance repair

- Carpentry

Creating completely separate Projects helps organization, but it can also fragment context and knowledge that logically belong together.

Keeping everything in one Project preserves context, but eventually creates a very large flat collection of conversations.

Proposed Solution

Allow Projects to contain Sub-Projects:

Project β†’ Sub-Project β†’ Conversation

For example:

Home / DIY

β”œβ”€β”€ Plumbing

β”œβ”€β”€ Electrical

β”œβ”€β”€ Bathroom Renovation

β”œβ”€β”€ Roofing

β”œβ”€β”€ Tools

└── Appliances

Or:

Spiritual

β”œβ”€β”€ Personal Study

β”œβ”€β”€ Family Worship

β”œβ”€β”€ Congregation

β”œβ”€β”€ Meeting Preparation

└── Talks

Parent Context Inheritance

The most important feature would be context inheritance.

A Sub-Project should be able to inherit the parent Project’s:

- Files and sources

- Project instructions

- Relevant context

- Knowledge

- Preferences

Then the Sub-Project could optionally contain its own:

- Additional instructions

- Additional files

- Conversations

- Specialized context

Conceptually:

Parent Project Context

↓

Inherited by Sub-Project

Sub-Project-Specific Context

↓

Conversation

There could be a simple setting:

Use parent Project context: ON / OFF

This would allow users to decide whether a Sub-Project acts as an organizational subdivision of the parent or as a more isolated workspace.

Why This Would Be Valuable

For users who use ChatGPT occasionally, the existing Project structure may be sufficient.

But for users who use ChatGPT as a persistent workspace across many areas of their personal and professional lives, Projects can eventually become extremely large.

The current choice is often:

Better organization but fragmented context

or

Shared context but poor organization

Nested Sub-Projects with inherited context would eliminate that tradeoff.

Suggested Hierarchy

ChatGPT

└── Project

β”œβ”€β”€ Parent instructions

β”œβ”€β”€ Parent files / sources

β”‚

β”œβ”€β”€ Sub-Project A

β”‚ β”œβ”€β”€ Additional instructions

β”‚ β”œβ”€β”€ Additional files

β”‚ β”œβ”€β”€ Conversation

β”‚ └── Conversation

β”‚

β”œβ”€β”€ Sub-Project B

β”‚ β”œβ”€β”€ Conversation

β”‚ └── Conversation

β”‚

└── Ungrouped Conversations

Potential features could include:

- Create, rename, move, and delete Sub-Projects

- Drag conversations between Sub-Projects

- Collapse and expand Sub-Projects

- Search the entire parent Project

- Search only within a Sub-Project

- Inherit parent sources and instructions

- Override or extend parent instructions

- Turn parent-context inheritance on or off

- Allow conversations to be moved without losing their history

- Keep an Ungrouped section for conversations not assigned to a Sub-Project

Relationship to Existing β€œGroups” Proposals

I have seen proposals for conversation groups or folders inside Projects. I think those would already be useful.

However, Sub-Projects could go one step further.

A Group could simply organize conversations visually.

A Sub-Project could organize conversations while also having its own files, instructions, and context β€” while still optionally inheriting those resources from its parent.

This would make ChatGPT Projects much more scalable for long-term and power users.

The goal is simple:

Keep related knowledge together without forcing every related conversation into one enormous flat Project.

I strongly support this proposal. The problem you described between separating Projects and losing related context versus keeping everything together in one large flat Project is exactly the issue that led me to think about this as well.

One additional use case I would add is business and team collaboration.

If Projects could contain true Sub-Projects, it would be extremely useful if individual Sub-Projects could also be shared independently.

For example:

Main Business Project

β”œβ”€β”€ Management

β”œβ”€β”€ Marketing

β”œβ”€β”€ Maintenance / Operations

β”œβ”€β”€ Finance

└── Other team workstreams

A business could keep all of those areas organized under one larger Project while giving an employee, contractor, or collaborator access only to the Sub-Project relevant to their work.

That would avoid having to create completely separate top-level Projects simply to control who participates in each area, while still preserving the larger organizational relationship between them.

Ideally, access would follow the Sub-Project boundary as well, so someone working inside one shared Sub-Project would only be able to access the chats, files, instructions, and context made available to that area rather than automatically gaining access to the entire parent Project.

For me, that is another reason Sub-Projects could become more than an organizational feature. They could allow the same hierarchy to support both the structure of the work and how different people collaborate within it.

The hierarchy itself would become part of managing the project.