Give ChatGPT a user-controlled, persistent project memory (rules + structured state) so it can behave like a consistent long-term collaborator instead of a stateless chat

ChatGPT Feature requests
1

Persistent Project State & Rule Tracking for ChatGPT (Agent-Like Continuity Across Sessions)

Summary

ChatGPT would become significantly more effective for complex, long-running tasks if users could define persistent rules and structured state that the model maintains and updates across sessions—without requiring repeated manual context injection.

This would allow ChatGPT to function as a stateful working partner, not just a stateless conversational tool.

My use case Problem

ChatGPT currently relies on a generous, but ultimately limited context window, which leads to:

Loss of important rules as conversations grow

Repeated manual re-entry of constraints and project context

Inconsistent handling of long-term structured information

Users working on serious projects end up building manual systems (control blocks, notebooks, summaries) to compensate.

While effective, this introduces:

friction

time overhead

risk of inconsistency

Proposed Solution

Introduce a lightweight system with:

1. Persistent Rule Layer (“Agent Rules”)

Users define rules such as:

“Respect system architecture boundaries”

“Track all timeline events and ensure consistency”

“Maintain a decision log and avoid reintroducing rejected approaches”

These rules:

persist across sessions

are always visible and editable

are automatically applied when relevant

2. Model-Maintained Structured State

Allow the model to create and maintain simple structured artifacts such as:

timeline.log

decisions.md

system_definition.md

constraints.json

The model:

updates these during conversation

references them when generating responses

keeps them compact and relevant

3. Selective Context Loading

Rules are always active

State is loaded only when relevant

Avoids unnecessary context bloat

Real-World Use Cases

1. Computer Vision System Design (Camera Monitoring Project)

In a real-world project designing a CPU-efficient intrusion detection system:

The system is built around strict architectural layers:

Layer 0: input trust (health, illumination, tamper)

Shadow: illumination refinement

Layer 1: nuisance suppression

Layer 2: motion classification

User requirement:

“Never violate layer responsibilities and maintain system consistency.”

Current workaround:

Maintain a control block and system notebook manually

Re-paste context when needed

Periodically correct drift

With persistent rules and state:

The architecture definition is stored once

The model references it automatically

Decisions (e.g., “no heavy ML,” “shadow is refinement only”) are preserved

New suggestions are validated against system rules

Result:

higher consistency

less repetition

reduced design errors

2. Long-Form Novel Writing (Timeline & Continuity)

In a science fiction writing project with complex causality:

User requirement:

“Track all events, character actions, and timelines. Prevent continuity errors.”

Current workaround:

Maintain external notes

Re-explain context to the model

manually check consistency

With persistent state:

The model maintains a timeline.log

Each new scene updates the timeline

The model cross-checks events automatically

Flags inconsistencies in causality or sequence

Result:

dramatically improved continuity

reduced cognitive load on the writer

enables deeper, more complex storytelling

3. Real-Life Constraint-Based Planning

User requirement:

“Ensure all advice respects specific constraints (budget, rules, policies).”

With persistent rules:

constraints are defined once

applied consistently over time

no need to repeat them

Why This Matters

Users are already attempting to simulate this behaviour manually or by using tools like OpenAI Codex for non-coding workflows.

This demonstrates:

strong demand for persistent structured context

applicability beyond coding

a natural evolution toward agent-like systems

Design Principles

User-controlled (no hidden or opaque memory)

Transparent (rules and state are visible and editable)

Efficient (no full context reload each turn)

Optional (does not affect casual usage)

Expected Impact

Reduced need for repeated context injection

Improved long-term and consistency across long sessions

Better support for complex, multi-step multi-session workflows

Expansion of ChatGPT into a true “working partner” for serious tasks

Closing

This feature would unify existing capabilities into a coherent system and enable ChatGPT to lean into becoming a true long-term collaborator.

2

Hey @S.Lee! Really interesting idea. Having a simple way to keep persistent rules and lightweight project state across sessions would make a big difference for longer-term work, especially when you’re trying to preserve decisions, constraints, and continuity without having to re-explain everything each time.

Appreciate you for laying it out so clearly. I don’t have a timeline to share, but I’ll make sure this gets passed along internally.

-Sunny

3

Thanks Sunny, I appreciate that. The big thing for me is keeping it user-visible and editable, even if the edits happen through ChatGPT itself, almost like a lightweight project notebook plus standing rules, rather than hidden memory. I think that would make it much easier to trust and manage for serious long-running projects. Keep well.

4

Feature Request Update: Connect Chat, Work/Codex, Project Instructions and Files into One Persistent Project System

I previously requested Persistent Project State and Rule Tracking for ChatGPT. Since then, I have realised that Project instructions already provide part of what I was asking for: a place for static rules that persist across conversations within a project.

However, the larger problem remains. The necessary pieces increasingly exist, but they do not yet operate as one coherent system.

At present:

  • Chat provides the strongest conversational experience for exploring ideas, challenging assumptions and developing an understanding with the user.

  • Work and Codex can act on files and produce or edit persistent outputs.

  • Project instructions can hold static working rules.

  • Projects organise conversations, files and instructions, while Library provides persistent file storage.

But these still feel like separate systems placed inside one interface.

The user must often choose between having a rich exploratory conversation and having an agent that can actively maintain the project’s files. Information discovered in conversation does not naturally flow into authoritative project records, and those records do not consistently talk back into later conversations.

What I am requesting

A shared, persistent project-intelligence layer connecting Chat, Work and Codex.

1. Shared project rules

Project instructions should govern all relevant modes working inside that project, with clear visibility into which instructions are active.

2. User-designated authoritative files

Users should be able to mark files such as these as the project’s sources of truth:

  • CHARACTERS.md

  • TIMELINE.md

  • DECISIONS.md

  • CONSTRAINTS.md

  • PROJECT_STATE.md

The system should understand the purpose of each file and use the appropriate ones when relevant. From my limited experience, the previous Codex app handled file-backed sources of truth reasonably well once they were defined.

3. Opt-in automatic file maintenance

A project instruction should be able to say:

When a character fact is established, propose an update to the character notebook.

or:

When an architectural decision is accepted, update the decision log and project state.

ChatGPT should then identify the affected files, propose the changes, show them to the user and update the approved versions. This should not depend on the user remembering to request a notebook update after every discussion.

4. Files that can “talk back”

Persistent files should not merely be passive storage or retrieved quotations. ChatGPT should reason against them and say things such as:

  • “This new idea conflicts with an earlier character decision.”

  • “The notebook says this, but our recent discussion may have superseded it.”

  • “Accepting this change will require updates to three project records.”

  • “This rule is being violated by the proposed solution.”

  • “We considered this previously and rejected it for the following reason.”

The files should ground the conversation without preventing the user from questioning or changing what they contain.

5. Visible retrieval and validation

The user should be able to see:

  • Which project instructions were active.

  • Which files were consulted.

  • Which existing decisions affected the answer.

  • Which files may now require updating.

  • Whether the proposed result was checked against the project’s rules and constraints.

This would make persistent context inspectable rather than opaque.

6. Cross-mode continuity

Moving between Chat, Work and Codex inside the same project should not feel like handing the project to a different assistant with a partial understanding.

The modes may remain specialised, but they should share the same project rules, authoritative state and relevant history. A decision reached through Chat should be available to Work or Codex, and file changes made by Work or Codex should inform later Chat conversations.

Example

During a novel discussion, the user and ChatGPT establish something important about a character.

ChatGPT recognises that the decision affects the character notebook and story architecture. It proposes the relevant updates, the user approves them, and the files are revised.

Weeks later, another conversation proposes a scene that contradicts that decision. ChatGPT retrieves the relevant character note, explains the conflict and discusses whether the new idea should be rejected or whether the old decision should be revised.

The same principle applies to software architecture, research projects, business planning, education and any other long-running work.

How this differs from current features

  • Project instructions provide static rules, but not maintained project state.

  • Library provides persistent storage, but storage alone does not create a working project memory.

  • Work and Codex can edit files, but file action is not yet seamlessly joined to Chat’s conversational continuity.

  • Projects collect chats, files and instructions, but do not yet turn them into one visible, actively maintained source of truth.

I am not necessarily asking for Chat, Work and Codex to lose their specialisations. I am asking for them to stop behaving like separate assistants when they are working inside the same project.

The new application brings the interfaces together. The next step should be to connect the underlying conversation, rules, files and project state into one continuous working relationship.

5

Hey @S.Lee! Appreciate you coming back with such a detailed update.

You’ve explained the gap really clearly. The individual pieces are there today through Projects, project instructions, files, Chat, Work, and Codex, but they can still feel disconnected when you’re trying to manage one long-running project.

A shared project layer that carries the same rules, source-of-truth files, decisions, and project state across each mode would make the experience feel much more continuous. I can also see the value in having ChatGPT propose file updates when a decision is made, flag conflicts with earlier choices, and show which instructions or files were used to reach an answer.

The visibility piece is especially useful. Knowing what was consulted, what changed, and which project records may need updating would give users much more confidence and control.

I can’t promise a timeline, but I’ll pass this updated feedback along internally. Thanks again for taking the time to break down how this could work in practice.

- Sunny