Adaptive Custom Instructions — A User-Facing Maintenance Loop for Personalization

[shouheishouhei50]

Adaptive Custom Instructions — A User-Facing Maintenance Loop for Personalization

Feature Request

Summary

Custom Instructions become increasingly difficult to maintain during long-term ChatGPT use.

Users may repeatedly correct the same behavior, add more instructions over time, create overlapping rules, or introduce conflicts without realizing it. They may also have no reliable way to know whether a change actually improved responses.

I propose a user-facing Adaptive Custom Instructions system that helps maintain personalization over time.

The core idea is not simply to edit or version Custom Instructions.

It is to create a complete maintenance loop:

conversation → improvement candidate → conflict check → A/B evaluation → user approval → apply → version / rollback

ChatGPT would help detect when personalization needs maintenance, but the user would remain in control of every change.

---

Current Problem

As users spend more time with ChatGPT, they naturally say things such as:

• “Do not ask me that again.”

• “Give me the conclusion first.”

• “Do not assume missing facts.”

• “Only suggest additional work when it clearly saves me time.”

• “When I correct you, verify the previous context before agreeing.”

Some of these are temporary instructions.

Others become persistent preferences.

Today, users have to decide manually which corrections should become Custom Instructions.

Over time, this can create several problems:

• Custom Instructions become too long.

• Similar instructions are duplicated.

• Old and new instructions conflict.

• Users do not know which instructions still matter.

• A new rule may unintentionally make other responses worse.

• Users cannot easily determine whether a configuration change actually improved response quality.

• Maintaining personalization becomes work in itself.

Advanced users effectively end up managing their own prompt-engineering system.

That should not be necessary.

---

Proposed Feature

1. Detect Recurring Corrections and Preferences

ChatGPT could identify repeated patterns such as:

• recurring corrections,

• repeatedly requested response styles,

• instructions the user explicitly adopts,

• repeated failures that existing Custom Instructions did not prevent.

When a pattern becomes strong enough, ChatGPT could say:

“This preference has appeared repeatedly. Would you like me to propose an update to your Custom Instructions?”

The system should not automatically modify personalization.

It should only generate a candidate.

---

2. Audit the Existing Instructions Before Adding Anything

Before proposing a new rule, ChatGPT should inspect the current instruction set for:

• duplicate instructions,

• similar rules,

• conflicts,

• obsolete instructions,

• unnecessary specificity,

• character-limit pressure.

Instead of simply adding another sentence, ChatGPT might say:

“This new instruction overlaps with two existing rules. I can merge them into one shorter rule instead.”

This would prevent Custom Instructions from continuously growing.

---

3. Show a Clear Diff

The user should be able to review exactly what would change.

Example:

Current

Important decisions should include counterarguments.

Proposed

For important decisions, consider only strong counterarguments that could materially change the decision. Do not generate weak objections simply for balance.

Users could then choose:

• Accept

• Edit

• Reject

• Keep for later

---

4. Test the Change Before Applying It

Before changing the user’s personalization, ChatGPT could compare the current and proposed instruction sets using representative tasks.

For example:

Configuration A
Current Custom Instructions

Configuration B
Proposed Custom Instructions

The system could evaluate differences in:

• instruction adherence,

• factual accuracy,

• unnecessary assumptions,

• unnecessary clarification questions,

• response length,

• usefulness,

• quality of counterarguments,

• user effort required,

• task completion quality.

The purpose would not be to claim that one configuration is objectively perfect.

It would be to detect obvious regressions before the user adopts a change.

---

5. Show Likely Personalization Influence

For a response, ChatGPT could optionally show which personalization elements likely influenced it.

For example:

Personalization influence

• Custom Instruction: “Give the conclusion first”

• Custom Instruction: “Do not fill missing facts with assumptions”

• Project Instruction: “Prefer primary internal documents”

• Current conversation: “Keep the answer brief”

This should not expose private chain-of-thought reasoning.

It would simply show which user-controlled context or settings were likely applied.

---

6. Detect Conflicting Instructions

If two personalization rules push the model in different directions, ChatGPT could flag them.

Example:

• “Always answer briefly.”

• “For important decisions, provide detailed analysis.”

Instead of silently choosing one, ChatGPT could propose:

“Answer briefly by default. Use detailed analysis only for high-impact decisions.”

This would make personalization behavior more predictable.

---

7. Version History and Rollback

Each approved change could create a new Custom Instructions version.

Example:

• V1

• V2

• V3

The user could inspect:

• what changed,

• why it changed,

• when it changed,

• and optionally restore an earlier version.

Rollback is especially important because a personalization change that improves one task may unexpectedly degrade another.

---

Example Workflow

A user repeatedly tells ChatGPT:

“Do not add extra suggestions after the task is already complete.”

ChatGPT detects the recurring correction.

It checks the existing Custom Instructions and finds a related rule:

“Avoid unnecessary additional work.”

Instead of adding a second rule, ChatGPT proposes a merged version.

It then compares representative responses using:

• the current instructions,

• the proposed instructions.

The user sees the differences.

ChatGPT reports:

“The proposed version reduced unnecessary follow-up suggestions in the test set without materially shortening required safety or compliance warnings.”

The user selects Accept.

The new version becomes active.

The previous version remains available for rollback.

---

Important Design Principle

ChatGPT should never silently rewrite its own governing instructions.

The system may:

detect → propose → audit → test → explain

But the user should make the final decision to:

apply → edit → reject

This avoids a dangerous feedback loop where the model gradually rewrites its own personalization without clear user oversight.

---

What Already Exists

Individual pieces of this concept already exist or have been proposed in related forms.

For example:

• Custom Instructions already allow persistent user guidance.

• Memory and personalization systems already affect responses.

• Some interfaces can surface sources of personalization.

• Versioning and rollback for Custom Instructions have been requested before.

• Developer-side prompt evaluation and optimization tools already exist.

• Community proposals have requested better visibility into which context influenced a response.

This proposal is not claiming that each individual component is new.

The proposed difference is to integrate those ideas into a single user-facing personalization maintenance loop.

The key workflow is:

real conversations → detect recurring corrections → propose instruction changes → check conflicts → test current vs. proposed settings → explain likely effects → user approval → apply → version / rollback

---

Minimum Viable Version

A first implementation could be much smaller.

MVP

1. Detect a recurring preference or correction.

2. Generate a proposed Custom Instructions update.

3. Check for duplicates, conflicts, and character limits.

4. Show the change as a diff.

5. Let the user approve or reject it.

6. Save the previous version so the user can undo the change.

A/B testing, influence visualization, and regression evaluation could be added later.

---

Why This Matters

Personalization should reduce user effort.

It should not require users to become prompt engineers.

The ideal interaction is simple:

The user says:

“This is not how I want you to answer.”

ChatGPT learns that the issue may be recurring, proposes a precise configuration change, checks whether it conflicts with existing preferences, tests the likely effect, and asks the user whether to apply it.

The user keeps control.

ChatGPT handles the maintenance work.

---

One-Sentence Proposal

Let ChatGPT detect recurring corrections and preferences from real conversations, propose improvements to Custom Instructions, test those changes against the current configuration, explain their likely effects, and apply them only after user approval.

[promptsvsevil]

I like the loop: propose → conflict check → evaluate → user approval → version/rollback. The key for me is not turning every temporary correction into permanent personalization. Persistence should be deliberate.

[shouheishouhei50]

Thank you for your thoughtful feedback!

I completely agree that temporary corrections should not automatically become permanent personalization rules.

One of the main goals of this proposal is to reduce the burden of maintaining custom instructions without taking control away from the user.

ChatGPT could identify recurring patterns and suggest improvements, but the user should always decide whether a change becomes permanent.

I also think the ability to reject or roll back changes is just as important as the ability to apply them.

Thank you again for highlighting this important distinction!

[barbara.gattobigio]

I can relate to the problem you describe. In my work with my assistant, reviewing and agreeing on changes to instructions is already part of our process. We keep a record of our agreements in notes and Markdown files and update them together. Over time, though, it becomes important to easily find what still applies, what we have changed, and what we have yet to decide.

That is why I would add a way to keep the status of each agreement visible after the initial decision. The options to accept, edit, reject, or keep something for later could leave a record we can revisit, linked to the exchange where the proposal came from.

I imagine a few simple statuses:

• Proposed: an open proposal we have not yet decided on.
• Agreed: a choice approved by the user, with its scope clearly stated.
• Declined: a proposal we considered and chose not to adopt, with the reason kept on record.
• Needs review: an agreement we want to revisit, with a clear indication of whether it still applies in the meantime.
• Superseded: a choice replaced by a later agreement, still available to read and linked to the new decision.

I would also keep the application status separate: a change can be agreed on and still be waiting to be applied. each card could show where it applies — to a single task, a project, or in general — and let us return to the original message and the note where we recorded it. The assistant could suggest a status update, leaving confirmation to the user.

I would find this approach useful in ChatGPT, Work, and Codex, adapted to their different interfaces. In the way I work, for example, an agreement discussed in Work can guide a task later carried out with Codex. Being able to follow the same reference would help keep the connection between the decision and the work that follows.

In the first mockup, for example, we use ChatGPT to prepare articles for a general audience and agree to use plain language and explain technical terms. The choice appears as “Agreed”, limited to that project, while the card shows that the update is still waiting to be applied. From there, we can reopen the original exchange or the linked note. A proposal such as “always answer in under one hundred words” could instead remain among the declined proposals, with the reason for that choice, so its status stays clear when we return to the conversation.

In Codex, I would take this a step further. Imagine a small application: we agree to keep all data local and change how it is stored. The new solution may have been approved, implemented, and passed the technical checks, while I still need to try it and confirm that I am happy with the result. I would find it useful to see those stages separately. The previous solution, now superseded, would also remain linked to the reason for the change.

The type of agreement would help clarify how to use it: “keep all data local” could be an instruction that applies throughout that project, while the choice of a storage system remains an implementation decision within the project.

This connects to another contribution with bookmarks for decisions and open questions. Here, I would apply the same principle to the history of agreements and instructions: being able to see what was decided and easily return to the context in which we agreed on it.

I have prepared two mockups with fictional projects and content: the first shows agreement statuses in a conversation; the second develops the Codex example, keeping agreement, implementation, technical checks, and user review separate.

ChatGPT / Work conversation — concept mockup

Codex conversation — concept mockup

[shouheishouhei50]

Thank you for sharing your experience and for creating the two mockups.

The distinction between agreement status and application status is particularly helpful. An “Agreed” change can still be waiting to be applied. And, as your Codex example shows, passing technical checks is separate from the user reviewing and accepting the result.

The original proposal included approval, version history, and rollback. Your approach makes the individual agreements within that process easier to follow: where each one applies, whether it is still in effect, and how it connects to the original discussion or a later replacement. Making it clear whether a “Needs review” agreement still applies in the meantime is especially useful.

I also appreciate the distinction between an ongoing instruction and an implementation decision. A choice made for one project should not automatically become a general personalization rule.

For me, the shared goal would be to make this information easy to find without creating another system that users have to maintain manually. The assistant could help keep the records connected and suggest status updates, while the user retains control over changes.

I see this as a practical extension of the maintenance loop: not just improving instructions, but keeping track of what we agreed on, where it applies, and whether it has actually taken effect. Thank you for making that part of the idea more concrete.

[barbara.gattobigio]

Thank you for your reply. I especially agree with your point about maintenance: keeping agreements up to date should be part of working with the assistant, with information that is easy to find and the user’s confirmations clearly identifiable.

To show how we are approaching this, I can share a concrete example from our editorial project, Radar. I’m Italian and work mainly in Italian, so I’m keeping the original names in our project structure alongside an English explanation.

We have one main project folder, organized like this:

Original item	Meaning in English
AGENTS.md — istruzioni del progetto	Project instructions
Archivio	Archive
Banner — banner e copertine	Banners and covers
Fonti	Sources
Grafici	Charts and figures
LOG — attività e verifiche	Work logs and verification records
Output Approfondimenti — Speciali	In-depth articles and special-issue outputs
Output Weekly — numeri settimanali	Weekly-issue outputs
Regia — coordinamento e indicazioni editoriali	Project coordination and editorial guidance
Watermark Radar	Approved Radar watermarks
Weekly Master — master storici	Historical Weekly master files

Our regia connects these materials to the choices we make: which instructions apply to the project, what we are preparing, which changes we have agreed on, and which steps still need checking. The logs record what has been carried out and verified. The assistant updates these records as we work, so we can pick things up again without reconstructing the whole process each time.

For example, choosing to use primary sources is an editorial guideline that applies to Radar. Deciding to revise a passage after comparing it with a new source concerns a specific piece of content. We can link that revision to the source, the text, and any charts that need checking, while keeping what has been changed separate from what I have already approved.

The relevant parts can also be made accessible in Obsidian, through notes and links to the reference documents. It’s our way of building a “second brain”: finding connections, decisions, open questions, and progress along the way. The notes point back to the project’s current guidelines, helping us keep the different points of access consistent.

This method supports both the design and development of the applications we are currently working on and the editorial work for my website, effettoantropico.life. In the editorial process, the full document, the web article, and the related images each have their own requirements and status: a cover may be approved while the web text is still under review. Being able to find those connections helps us understand which materials we can use and which still need attention.

In the workspace, I’d like to have that continuity right alongside the materials. The assistant could keep verifiable results up to date and propose updates to the agreements, while my approval would remain tied to an actual confirmation. When I reopen a project, I’d like to find what we have decided, the work completed, and the next point for us to discuss together.

Radar workflow — illustrative layout of separate tools, with sample article and states